Symantec Messaging Gateway for Service Providers Implementation Guide

Transcription

1 Symantec Messaging Gateway for Service Providers 10.5 Implementation Guide

2 The software described in this book is furnished under a license agreement and may be used only in accordance with the terms of the agreement. Documentation version: Legal Notice Copyright 2013 Symantec Corporation. All rights reserved. Symantec, the Symantec Logo, the Checkmark Logo and are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. This Symantec product may contain third party software for which Symantec is required to provide attribution to the third party ( Third Party Programs ). Some of the Third Party Programs are available under open source or free software licenses. The License Agreement accompanying the Software does not alter any rights or obligations you may have under those open source or free software licenses. Please see the Third Party Legal Notice Appendix to this Documentation or TPIP ReadMe File accompanying this Symantec product for more information on the Third Party Programs. The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation/reverse engineering. No part of this document may be reproduced in any form by any means without prior written authorization of Symantec Corporation and its licensors, if any. THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE. The Licensed Software and Documentation are deemed to be commercial computer software as defined in FAR and subject to restricted rights as defined in FAR Section "Commercial Computer Software - Restricted Rights" and DFARS , "Rights in Commercial Computer Software or Commercial Computer Software Documentation", as applicable, and any successor regulations. Any use, modification, reproduction release, performance, display or disclosure of the Licensed Software and Documentation by the U.S. Government shall be solely in accordance with the terms of this Agreement.

3 Symantec Corporation 350 Ellis Street Mountain View, CA

4 Technical Support Contacting Technical Support Symantec Technical Support maintains support centers globally. Technical Support s primary role is to respond to specific queries about product features and functionality. The Technical Support group also creates content for our online Knowledge Base. The Technical Support group works collaboratively with the other functional areas within Symantec to answer your questions in a timely fashion. For example, the Technical Support group works with Product Engineering and Symantec Security Response to provide alerting services and virus definition updates. Symantec s support offerings include the following: A range of support options that give you the flexibility to select the right amount of service for any size organization Telephone and/or Web-based support that provides rapid response and up-to-the-minute information Upgrade assurance that delivers software upgrades Global support purchased on a regional business hours or 24 hours a day, 7 days a week basis Premium service offerings that include Account Management Services For information about Symantec s support offerings, you can visit our website at the following URL: All support services will be delivered in accordance with your support agreement and the then-current enterprise technical support policy. Customers with a current support agreement may access Technical Support information at the following URL: Before contacting Technical Support, make sure you have satisfied the system requirements that are listed in your product documentation. Also, you should be at the computer on which the problem occurred, in case it is necessary to replicate the problem. When you contact Technical Support, please have the following information available: Product release level Hardware information

5 Available memory, disk space, and NIC information Operating system Version and patch level Network topology Router, gateway, and IP address information Problem description: Error messages and log files Troubleshooting that was performed before contacting Symantec Recent software configuration changes and network changes Licensing and registration Customer service If your Symantec product requires registration or a license key, access our technical support Web page at the following URL: Customer service information is available at the following URL: Customer Service is available to assist with non-technical questions, such as the following types of issues: Questions regarding product licensing or serialization Product registration updates, such as address or name changes General product information (features, language availability, local dealers) Latest information about product updates and upgrades Information about upgrade assurance and support contracts Information about the Symantec Buying Programs Advice about Symantec's technical support options Nontechnical presales questions Issues that are related to CD-ROMs, DVDs, or manuals

6 Support agreement resources If you want to contact Symantec regarding an existing support agreement, please contact the support agreement administration team for your region as follows: Asia-Pacific and Japan Europe, Middle-East, and Africa North America and Latin America

7 Contents Technical Support... 4 Chapter 1 Introducing Messaging Gateway for Service Providers About Symantec Messaging Gateway for Service Providers What's new in Messaging Gateway for Service Providers Components of Messaging Gateway for Service Providers How Messaging Gateway for Service Providers works What you can do with Messaging Gateway for Service Providers Where to get more information about Messaging Gateway for Service Providers Chapter 2 Planning for installation About Messaging Gateway for Service Providers deployment About Messaging Gateway for Service Providers deployment at the gateway layer About Messaging Gateway for Service Providers deployment at the post gateway layer About Messaging Gateway for Service Providers deployment at the mail server About Messaging Gateway for Service Providers deployment on the Client and the Server About plan for disk space storage About firewall configuration Configuring firewall port connections for a standard deployment model Ports required for Messaging Gateway for Service Providers About using Messaging Gateway for Service Providers with other filtering products About adjusting MX records for Messaging Gateway for Service Providers software About access by the Server to perimeter information About preserving quarantined mail for access after update... 38

8 Contents 8 Chapter 3 Chapter 4 Installing Messaging Gateway for Service Providers Before you install System requirements New installation Installing Messaging Gateway for Service Providers on Linux and Solaris Configuring Messaging Gateway for Service Providers on Linux and Solaris Installing Messaging Gateway for Service Providers on Windows Update installation Updating one or more Solaris or Linux systems Updating one or more Windows systems Uninstalling Messaging Gateway for Service Providers Backing out of an update Optimizing Messaging Gateway for Service Providers Managing your system for service providers About IPv6 address in Messaging Gateway for Service Providers About the Sender Reputation Service About DNS-based IP reputation About selecting the optimal rule set to optimize performance Implementing custom rule sets Using Keep Alive Optimizing performance on Solaris SPARC Optimizing performance with Java Message Service Optimizing performance on Linux Optimizing performance on Windows About enhancing performance for outbound Configuration tips to reduce outbound spam About the factors that affect performance Hardware components that affect performance Environmental factors that affect performance About the Messaging Gateway for Service Providers settings that affect performance... 70

9 Contents 9 Chapter 5 Configuring Messaging Gateway for Service Providers About configuring settings for a large number of users Setting up Scanner services on Linux and Solaris Setting up Scanner services on Windows About configuration file elements About the Installation section About the Services section About the Spam Service Type libbh libintsig libstatsig libspamsig libregexfilter libspamhunter About the Virus Services Type libantivirus About the Consent Service Type libfastpass libpermit About the Language Service Type liblanguageid About the Reinsert Service Type libreinsert About the Programs section About the Filter program About the Client program About the Server program About the Conduit program About the LiveUpdate program About the AntiVirus Cleaner program About the Engine section About bmicheckreputation About the Policies section Adding a new disposition through the command line Updating an existing disposition Changing the destination string of an existing disposition Changing the order of message scanning Managing logs for stand-alone Scanners About the log level element About the log period element About the periodunits element

10 Contents 10 About the numberretained element About managing statistics for stand-alone Scanners About conduit rule updates About LiveUpdate rule updates Chapter 6 Chapter 7 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers About integrating the Sun Java Messaging Server MTA with Messaging Gateway for Service Providers Installation overview Configuring Messaging Server for Messaging Gateway for Service Providers Configuring a multi-node deployment About enabling the tracker for Messaging Server Troubleshooting issues with Messaging Server integration Configuring Sendmail to integrate with Messaging Gateway for Service Providers About integrating Sendmail Understanding the filter address and optional settings About configuring Sendmail Switch to work with Messaging Gateway for Service Providers Configuring Sendmail for Messaging Gateway for Service Providers with sendmail.cf About configuring Sendmail for Messaging Gateway for Service Providers with M About using the runner and cron Understanding automatic library paths About managing Scanner components with the runner Starting the runner About stopping the runner (and all Scanner jobs) Testing the runner About monitoring job statuses About stopping and starting jobs About the runner configuration file Chapter 8 Using group policies About group policies Creating group policies Working with group policies

11 Contents 11 Chapter 9 Filtering spam About unwanted messages Enabling or disabling Messaging Gateway for Service Providers to filter unwanted messages About submitting messages for customer-specific spam rules About the process that Symantec follows to create customer-specific spam rules Setting up customer-specific spam submissions Enabling or disabling customer-specific spam submissions Provisioning the submitter ID for customer-specific spam submissions Checking and setting the customer-specific spam submission aggressiveness level Specifying and viewing who can submit messages for customer-specific rules Submitting spam messages through the command line for customer-specific rules Submitting messages that are incorrectly marked as spam through the command line for customer-specific rules Deleting customer-specific spam data Generating customer-specific spam submission report Chapter 10 Using filters to protect your environment and block unwanted mail About Messaging Gateway for Service Providers filters About specifying senders to permit or block How Messaging Gateway for Service Providers identifies senders and connections About the Allowed Senders List and the Blocked Senders List Use case scenarios to allow or block senders Adding senders to the Blocked Senders List Adding senders to the Allowed Senders List Deleting senders from the senders list Editing senders in the senders list Enabling or disabling senders from the senders list Importing sender information into a senders list Selecting reputation services to use About filtering for spam Adjusting spam scoring Rejecting spam at the gateway Scanning text attachments Increasing the speed for processing messages

12 Contents 12 About filtering for viruses Configuring antivirus filter settings Chapter 11 Keeping your product up-to-date About updating virus definitions About LiveUpdate About Rapid Release virus definitions Obtaining the virus definition updates Obtaining definitions when a new or emerging threat is discovered Setting a local mirror of the LiveUpdate server Chapter 12 Chapter 13 Managing Messaging Gateway for Service Providers Scanners, hosts, and components Specifying internal mail hosts About registering your Scanner license Monitoring the Messaging Gateway for Service Providers status and events About Logs Modifying Log settings Viewing and saving logs About tracking messages with the SMTP message ID Appendix A Command line reference policyconfig subm-config subm-config allowedlist subm-config blockedlist subm-config configuration subm-config displaylist subm-config msg subm-config msginfo subm-config provisioning subm-config rawmsg subm-config report subm-config rule subm-config ruleinfo subm-config servicestatus subm-config submitspam

13 Contents 13 subm-config submitnotspam subm-config submissionpolicy Appendix B Input XML file to generate customer-specific submission report Spam submission XML inputs and description Sample XML file to provide inputs for customer-specific spam report generation Index

14 Chapter 1 Introducing Messaging Gateway for Service Providers This chapter includes the following topics: About Symantec Messaging Gateway for Service Providers What's new in Messaging Gateway for Service Providers Components of Messaging Gateway for Service Providers How Messaging Gateway for Service Providers works What you can do with Messaging Gateway for Service Providers Where to get more information about Messaging Gateway for Service Providers About Symantec Messaging Gateway for Service Providers Symantec Messaging Gateway for Service Providers (formerly branded as Symantec Message Filter) provides an easy-to-deploy, comprehensive security solution that protects your customers and your network. It detects and repairs viruses. It also identifies and blocks unwanted before it can inconvenience your users and overwhelm your network. The product is centralized and automated. It is scalable and can be customized to fit your organization's specific needs. Messaging Gateway for Service Providers runs with your existing mail server or groupware server. Messaging Gateway for Service Providers includes the following filters that you can customize:

15 Introducing Messaging Gateway for Service Providers What's new in Messaging Gateway for Service Providers 15 Antispam filters Antivirus definitions Allowed senders and blocked senders filters You can deploy Messaging Gateway for Service Providers in different configurations to best suit the size of your needs. See Components of Messaging Gateway for Service Providers on page 17. See How Messaging Gateway for Service Providers works on page 18. See What you can do with Messaging Gateway for Service Providers on page 20. See Where to get more information about Messaging Gateway for Service Providers on page 22. What's new in Messaging Gateway for Service Providers Table 1-1 describes the new features in this release of Messaging Gateway for Service Providers Table 1-1 Feature Creation of custom spam rules New features Description You can obtain custom spam rules specifically for your organization based on the missed spam messages and false positive messages that administrators and end users submit. This feature provides the following benefits: It improves Messaging Gateway for Service Providers's ability to detect spam and helps administrators control false positive incidents. It makes it easier to submit missed spam messages or false positive messages to Symantec for analysis and rule creation. It provides visibility into the submission status and rule creation. When you configure this feature, administrators and end users can submit messages to Symantec as missed spam or false positives. Within minutes, Symantec creates custom rules. The conduit obtains these rules which are then applied to each configured Scanner. IPv6 addresses are supported Messaging Gateway for Service Providers now accepts messages with IPv6 addresses. IPv6 addresses are also supported in the allowedblockedlist.txt.

16 Introducing Messaging Gateway for Service Providers What's new in Messaging Gateway for Service Providers 16 Table 1-1 Feature Handling unwanted category Enhanced IP reputation is now integrated with Messaging Gateway for Service Providers Antivirus New features (continued) Description Messaging Gateway for Service Providers now has new configurable verdicts for unwanted category. You can configure policies for s pertaining to marketing, which are newsletters, bulk s, and s with suspicious URLs. You can choose whether or not to enable this functionality. Messaging Gateway for Service Providers now contains the enhanced IP reputation data. Support for granular unscannable dispositions. The antivirus module now returns unscannable verdicts at more granular levels: Unscannable due to malformed MIME Unscannable due to limits exceeded (size, depth or time) Unscannable due to mismatched file type Unscannable due to other reasons These new dispositions allow users to configure policies that can take different actions based on why an attachment cannot be scanned. Table 1-2 lists the features that are discontinued in Messaging Gateway for Service Providers Table 1-2 Feature Discontinued features Description Brightmail Control Center Harvester program Sieve language The Brightmail Control Center is no longer available. All Brightmail Control Center operations can now be performed with commands supplied through the command-line interface. The harvester program is no longer available. Creating filters by coding in Sieve language is no longer supported.

17 Introducing Messaging Gateway for Service Providers Components of Messaging Gateway for Service Providers 17 Table 1-2 Feature IIS support Discontinued features (continued) Description IIS support is no longer available. To allow backward compatibility for existing customers, Symantec recommends the following deployment configuration: IIS with bmisink from Symantec Message Filter 6.3 on one system Symantec Messaging Gateway for Service Providers 10.5 on a separate system Point the bmisink configuration file to the Symantec Messaging Gateway for Service Providers 10.5 server Client-only installation Client-only installation is no longer supported on the Windows platform. Accordingly, update from a client-only installation of Symantec Message Filter 6.3 to Symantec Messaging Gateway for Service Providers 10.5 is also not supported. You must manually uninstall the 6.3 client. Message quarantine Quarantine is no longer supported. See About preserving quarantined mail for access after update on page 38. for information about backing up your quarantined messages before update if you want to retain them. Components of Messaging Gateway for Service Providers Table 1-3 lists the components of Messaging Gateway for Service Providers. Table 1-3 Component Messaging Gateway for Service Providers Scanner Components of Messaging Gateway for Service Providers Description The Messaging Gateway for Service Providers Scanner processes the that is based on the configuration options that you specify. The Messaging Gateway for Service Providers Scanner contains the following subcomponents: Client Server Conduit LiveUpdate

18 Introducing Messaging Gateway for Service Providers How Messaging Gateway for Service Providers works 18 Table 1-3 Component Client Server Conduit LiveUpdate Cleaner Components of Messaging Gateway for Service Providers (continued) Description The Client is a communication channel between the MTA and the Server. You can use multiple clients, and each client can communicate with multiple Servers. The Client balances the load between Servers. The Server filters messages for classification with a variety of scanning technologies. The classification or verdict is then returned to the Client for subsequent delivery action. The Conduit obtains updated antispam filters from Symantec and notifies each Server to use the updated filters. LiveUpdate automatically downloads virus definitions from Symantec Security Response to the Scanner. The Scanner's Brightmail Engine uses these definitions to identify known security threats. The Cleaner process is responsible for cleaning virus-infected mail. See About Symantec Messaging Gateway for Service Providers on page 14. See How Messaging Gateway for Service Providers works on page 18. See What you can do with Messaging Gateway for Service Providers on page 20. See Where to get more information about Messaging Gateway for Service Providers on page 22. How Messaging Gateway for Service Providers works The Mail Transfer Agent, which is integrated with the Messaging Gateway for Service Providers Client, receives inbound . The Client sends the message to the Server for evaluation and scanning. The Messaging Gateway for Service Providers Server filters messages for classification with a variety of scanning technologies. The Server scans the message to determine the following conditions: If the sender of the message is in the allowed senders list or the blocked senders list If the message is scannable If the message is spam or suspected spam If the message contains viruses The Server returns its verdict to the Client. The Client processes the message according to the settings that you configure.

19 Introducing Messaging Gateway for Service Providers How Messaging Gateway for Service Providers works 19 Messaging Gateway for Service Providers Conduit connects to Symantec Brightmail Logistics and Operations Center (BLOC) to determine whether updated antispam filters are available. If the filters are available, the Conduit retrieves the updated antispam filters through a secure HTTP file transfer. LiveUpdate connects to Symantec LiveUpdate server to determine whether updated antivirus definitions are available. If the definitions are available, the LiveUpdate retrieves the updated antivirus definitions through a secure HTTP file transfer. After the Conduit and LiveUpdate authenticate the antispam filters and antivirus definitions, they distribute the updated filters and definitions to your servers and notify your servers to begin using the updated filters and definitions. Figure 1-1 shows how Messaging Gateway for Service Providers integrates with your system. Figure 1-1 How Messaging Gateway for Service Providers works See About Symantec Messaging Gateway for Service Providers on page 14. See Components of Messaging Gateway for Service Providers on page 17.

20 Introducing Messaging Gateway for Service Providers What you can do with Messaging Gateway for Service Providers 20 See What you can do with Messaging Gateway for Service Providers on page 20. See Where to get more information about Messaging Gateway for Service Providers on page 22. What you can do with Messaging Gateway for Service Providers Table 1-4 describes what you can do with Messaging Gateway for Service Providers. Table 1-4 Task Create group policies Messaging Gateway for Service Providers tasks Description You can specify the groups of users that are based on addresses or domain names. You can configure group policies to set identical options for all users or to specify different actions for different groups of users. For each group, you can specify filtering actions for different categories of . And for each category, you can specify different filtering options. See About group policies on page 164. Detect spam Spam is unsolicited bulk , most often advertising messages for a product or service. It wastes productivity, time, and network bandwidth. You can define which messages are spam, suspected spam, or not spam based on the scores that Messaging Gateway for Service Providers assigns to messages. You can also configure how to dispose of spam and suspected spam messages. See About filtering for spam on page 195. Detect viruses Messaging Gateway for Service Providers detects viruses with Symantec antivirus definitions and engines. You can configure Messaging Gateway for Service Providers to repair infected messages, if possible. You can also specify how you want Messaging Gateway for Service Providers to dispose of the messages that contain viruses. See About filtering for viruses on page 199.

21 Introducing Messaging Gateway for Service Providers What you can do with Messaging Gateway for Service Providers 21 Table 1-4 Task Stop mass-mailer worm attacks Messaging Gateway for Service Providers tasks (continued) Description A mass-mailer worm or virus can exploit security vulnerabilities and spread by sending copies of itself by through the Internet or a network. For example, a single mass-mailer worm can infect one computer in an organization. Then it can spread by sending copies of itself through to everyone in the company's global address book. You can specify how you want Messaging Gateway for Service Providers to dispose of the mass-mailer messages. See About group policies on page 164. Dispose of unwanted encrypted A file that cannot be scanned can put your network at risk if it contains a virus. Infected files can be intentionally encrypted so that they cannot be scanned. You can configure how you want Messaging Gateway for Service Providers to process encrypted container files to protect your network from threats. See About group policies on page 164. Establish file processing limits Messaging Gateway for Service Providers must be able to decompose and scan a container file to detect viruses. An unscannable container file that contains a virus can pose a risk to your network. An unscannable container file is one that exceeds a scanning limit, is a partial container file, or generates a scanning error. You can specify how you want Messaging Gateway for Service Providers to process the container files that cannot be scanned. See Configuring antivirus filter settings on page 199. Block unwanted When you block from unwanted senders, you reduce the volume of that is scanned and reduce spam and potential malicious attacks. You can specify a list of senders that you want Messaging Gateway for Service Providers to automatically block. You can also use third party blocked senders lists. See About specifying senders to permit or block on page 185.

22 Introducing Messaging Gateway for Service Providers Where to get more information about Messaging Gateway for Service Providers 22 Table 1-4 Task Let trusted bypass scanning Messaging Gateway for Service Providers tasks (continued) Description Another method that you can use to reduce scanning resources is to permit trusted senders to bypass scanning for spam and content filtering. Update antispam filters and antivirus definitions You can specify trusted senders in an Allowed Senders List. You can also use third party allowed senders lists. Messages from allowed senders automatically bypass scanning for spam and content filtering. Note: Messaging Gateway for Service Providers scans all messages for viruses when virus detection is enabled, including messages from trusted senders. See About specifying senders to permit or block on page 185. Messaging Gateway for Service Providers relies on continually updated filters to effectively filter messages. Messaging Gateway for Service Providers receives filter updates through the Conduit and LiveUpdate. Conduit downloads antispam filters and LiveUpdate downloads antivirus definitions. These are the components that run on each scanner that contains a Messaging Gateway for Service Providers server. Conduit and LiveUpdate poll the secure Web sites to check for updated filters. If new filters and definitions are available, they retrieve the updated filters and definitions through a secure HTTP file transfer. After they authenticate the filters and definitions, they notify the Symantec Messaging Gateway for Service Providers servers to begin using the updated filters and definitions. See About conduit rule updates on page 134. See About LiveUpdate rule updates on page 135. See About Symantec Messaging Gateway for Service Providers on page 14. See Components of Messaging Gateway for Service Providers on page 17. See How Messaging Gateway for Service Providers works on page 18. See Where to get more information about Messaging Gateway for Service Providers on page 22. Where to get more information about Messaging Gateway for Service Providers The documentation set for this release of Messaging Gateway for Service Providers includes the following:

23 Introducing Messaging Gateway for Service Providers Where to get more information about Messaging Gateway for Service Providers 23 Symantec Messaging Gateway for Service Providers Implementation Guide Symantec Messaging Gateway for Service Providers Software Development Kit Development Guide Symantec Messaging Gateway for Service Providers Getting Started Guide Symantec Messaging Gateway for Service Providers Release Notes Symantec Brightmail Engine Integration Kit Integration Guide To find documentation about Messaging Gateway for Service Providers, on the Internet, go to the following URL: &channel=documentation&sort=recent The following online resources are also available on the Symantec Web site for more information about your product: Provides access to the technical support knowledge base, newsgroups, contact information, downloads, and mailing list subscriptions Provides information about registration, frequently asked questions, how to respond to error messages, and how to contact Symantec License Administration Provides product news and updates Provides access to a virus encyclopedia that contains information about all known threats and hoaxes, and access to white papers about threats index.jsp See About Symantec Messaging Gateway for Service Providers on page 14. See Components of Messaging Gateway for Service Providers on page 17. See How Messaging Gateway for Service Providers works on page 18. See What you can do with Messaging Gateway for Service Providers on page 20.

24 Chapter 2 Planning for installation This chapter includes the following topics: About Messaging Gateway for Service Providers deployment About plan for disk space storage About firewall configuration Ports required for Messaging Gateway for Service Providers About using Messaging Gateway for Service Providers with other filtering products About adjusting MX records for Messaging Gateway for Service Providers software About access by the Server to perimeter information About preserving quarantined mail for access after update About Messaging Gateway for Service Providers deployment You can deploy Messaging Gateway for Service Providers in any of the following configurations: At the gateway At the post-gateway See About Messaging Gateway for Service Providers deployment at the gateway layer on page 25. See About Messaging Gateway for Service Providers deployment at the post gateway layer on page 29.

25 Planning for installation About Messaging Gateway for Service Providers deployment 25 At the mail server See About Messaging Gateway for Service Providers deployment at the mail server on page 31. The type of deployment configuration that you choose depends on the following conditions: The size of your environment The number of servers that you plan to use Your environment configuration See About Messaging Gateway for Service Providers deployment on the Client and the Server on page 32. Before you install Messaging Gateway for Service Providers, ensure that you read and understand the advantages and requirements necessary for each deployment scenario. Also, ensure that your environment meets the minimum system requirements. See System requirements on page 40. About Messaging Gateway for Service Providers deployment at the gateway layer Some organizations prefer to have secure gateways with no other active services. In these environments, all other services including antispam services function behind the first gateway layer. In this deployment configuration, Messaging Gateway for Service Providers resides at the outermost gateway layer. This layer contains the gateway MTA, which processes inbound mail and relays it to other relay layers or to the user-facing message store layer. See About Messaging Gateway for Service Providers deployment on page 24. See About the advantages of Messaging Gateway for Service Providers deployment at the gateway level on page 26. See About the Messaging Gateway for Service Providers basic deployment on page 26. See About Messaging Gateway for Service Providers deployment behind a firewall on page 27. See About Messaging Gateway for Service Providers deployment in a demilitarized zone (DMZ) on page 28. See About Messaging Gateway for Service Providers deployment for high availability and performance on page 28.

26 Planning for installation About Messaging Gateway for Service Providers deployment 26 About the advantages of Messaging Gateway for Service Providers deployment at the gateway level Following are the advantages when you deploy Messaging Gateway for Service Providers at the gateway level: Detects spam at the point of entry Saves the resources Lets you enable the early verdict feature Because spam originates from the outside world, the gateway is the logical, effective place to deploy the server. When you deploy Messaging Gateway for Service Providers closer to the gateway, you can minimize mail processing and storage requirements. Spam is removed from the stream, which reduces network bandwidth. When you deploy the product at the gateway, the Scanner can determine an early verdict on the IP address before the entire message is received. If the message is blocked, the MTA does not need to continue through the remainder of the calls, thereby reducing scanning resources. See About Messaging Gateway for Service Providers deployment at the gateway layer on page 25. About the Messaging Gateway for Service Providers basic deployment Figure 2-1 shows the Messaging Gateway for Service Providers deployment scenario in which there is no firewall. Please note that the text "Symantec Message Filter" in the Inbound MTA portion of the figure should instead read "Symantec Messaging Gateway for Service Providers."

27 Planning for installation About Messaging Gateway for Service Providers deployment 27 Figure 2-1 Basic deployment See About Messaging Gateway for Service Providers deployment at the gateway layer on page 25. About Messaging Gateway for Service Providers deployment behind a firewall Figure 2-2 shows Messaging Gateway for Service Providers deployment behind the firewall. On all configured server computers, configure port 443 to permit outbound connections to the BLOC. Please note that the text "Symantec Message Filter" in the Inbound MTA portion of the figure should instead read "Symantec Messaging Gateway for Service Providers." Figure 2-2 Behind the firewall

28 Planning for installation About Messaging Gateway for Service Providers deployment 28 See About Messaging Gateway for Service Providers deployment at the gateway layer on page 25. About Messaging Gateway for Service Providers deployment in a demilitarized zone (DMZ) In this scenario, Messaging Gateway for Service Providers deployment is behind a double layer of firewalls or in a demilitarized zone. Figure 2-3 illustrates a typical DMZ configuration. Please note that the text "Symantec Message Filter" in the Inbound MTA portion of the figure should instead read "Symantec Messaging Gateway for Service Providers." Figure 2-3 In a demilitarized zone See About Messaging Gateway for Service Providers deployment at the gateway layer on page 25. About Messaging Gateway for Service Providers deployment for high availability and performance You can configure Messaging Gateway for Service Providers for high availability and performance. Messaging Gateway for Service Providers is licensed on a per-user as opposed to per-server basis. Therefore, you can install the software on as many servers as is necessary to handle your needs. The client supports round robin load balancing and fails over to secondary servers or tertiary servers

29 Planning for installation About Messaging Gateway for Service Providers deployment 29 for redundancy. The filtering daemon is multi-threaded, so it makes optimal use of multi-cpu systems. High availability deployments typically use two Messaging Gateway for Service Providers Servers. Some customers that use dedicated systems have numerous MTAs installed with the Messaging Gateway for Service Providers client. All of these MTAs point at a pair of Messaging Gateway for Service Providers servers. To provide redundancy, the Messaging Gateway for Service Providers client configuration includes the IP addresses of both available Messaging Gateway for Service Providers servers. Figure 2-4 illustrates the high availability scenario for Messaging Gateway for Service Providers deployment. Figure 2-4 High availability scenario See About Messaging Gateway for Service Providers deployment at the gateway layer on page 25. About Messaging Gateway for Service Providers deployment at the post gateway layer In this deployment method, MTAs at the gateway layer accept mail from the Internet. Then they relay unfiltered mail to the MTA that is integrated with Messaging Gateway for Service Providers software. The Server filters mail from the gateway layer and relays mail to other MTAs downstream.

30 Planning for installation About Messaging Gateway for Service Providers deployment 30 See About Messaging Gateway for Service Providers deployment on page 24. See About considerations for Messaging Gateway for Service Providers deployment at the post gateway layer on page 30. See About the advantages of Messaging Gateway for Service Providers deployment at the post-gateway layer on page 30. About considerations for Messaging Gateway for Service Providers deployment at the post gateway layer Following are some considerations for Messaging Gateway for Service Providers deployment at the post gateway layer: You must set up SMTP or Sendmail, Postfix, or an MTA with a Messaging Gateway for Service Providers integration to relay mail. If you run other applications such as antivirus software on this computer, ensure that there are enough resources to support Messaging Gateway for Service Providers software. See About Messaging Gateway for Service Providers deployment at the post gateway layer on page 29. About the advantages of Messaging Gateway for Service Providers deployment at the post-gateway layer Following are some advantages of Messaging Gateway for Service Providers deployment at the post-gateway layer: Reduced downtime Multiple services on one computer From an architecture perspective, this method often requires the least amount of downtime. Administrators can build the system, test it, and then deploy it into production. Multiple services is an efficient way to deploy Messaging Gateway for Service Providers in a multi-layer scenario on one box. For example, you can run antispam, antivirus, and other services on one physical computer. Figure 2-5 illustrates Messaging Gateway for Service Providers deployment at the post-gateway. Please note that the text "Symantec Message Filter" in the Inbound MTA portion of the figure should instead read "Symantec Messaging Gateway for Service Providers."

31 Planning for installation About Messaging Gateway for Service Providers deployment 31 Figure 2-5 Post-gateway deployment See About Messaging Gateway for Service Providers deployment at the post gateway layer on page 29. About Messaging Gateway for Service Providers deployment at the mail server In this deployment method, Messaging Gateway for Service Providers Server integrates directly with the internal mail server at the last node in any relay chain. If you run multiple mail servers, you might have to install multiple instances of Messaging Gateway for Service Providers Servers. See About Messaging Gateway for Service Providers deployment on page 24. See About the advantages of Messaging Gateway for Service Providers deployment at the mail server on page 31. About the advantages of Messaging Gateway for Service Providers deployment at the mail server The advantage of deploying Messaging Gateway for Service Providers at the mail server is as follows: Integrated solution This option is ideal for smaller organizations who do not deploy new servers. See About Messaging Gateway for Service Providers deployment at the mail server on page 31.

32 Planning for installation About Messaging Gateway for Service Providers deployment 32 About Messaging Gateway for Service Providers deployment on the Client and the Server Messaging Gateway for Service Providers software can be deployed in a variety of computing environments, from single computer setups to distributed client-server configurations. In each case, the Messaging Gateway for Service Providers Client integration communicates with the MTA by using standard libraries. As messages flow through the mail server, the Client calls the Server. The Server checks individual messages against antispam filters, antivirus definitions, and other filters that you configure. Based on the verdict that the Server returns and the Server and the configuration options that you configure, the mail may be handled differently. Table 2-1 summarizes the configurations in general terms. Table 2-1 Configuration scenarios with the Client/MTA integration and the Server Scenario Advantages Notes Single MTA and Messaging Gateway for Service Providers Server on one computer Saves the hardware cost because the MTA and the Server reside on the same computer. MTAs tend to be inbound and outbound. By comparison, the Server is CPU-intensive, so the two programs use different software resources. However, if the Server saves spam to disk or performs virus processing, it is inbound and outbound. The MTA must not use a large quantity of CPU cycles. Single MTA and Messaging Gateway for Service Providers Server on separate computers Advantages of the MTA and the Server installation on separate computers are as follows: Requires minimal or no change to an MTA server Provides scalability As mail throughput increases, you can add processors or memory to the Server to suit your needs. Provides flexibility The MTA server and the Server can run on separate platforms. This configuration is an adequate solution for most small to medium-sized enterprises.

33 Planning for installation About plan for disk space storage 33 Table 2-1 Configuration scenarios with the Client/MTA integration and the Server (continued) Scenario Multiple MTAs and Messaging Gateway for Service Providers Servers Advantages Advantages of multiple MTA and the Server installations are as follows: Provides maximum scalability Offers full failover and redundancy Provides built in round robin load balancing Allows for easy implementation of a virtual IP (VIP), which enables scalable load balancing Provides flexibility since the MTA server and the Server can run on separate platforms Notes See About Messaging Gateway for Service Providers deployment for high availability and performance on page 28. Most of this information is applicable to all MTAs. Consult your Symantec representative to determine which scenario best meets your needs. If your environment has a high volume of traffic, consider to use Symantec Traffic Shaper. This network device allocates reduced bandwidth to MTAs that deliver spam. The load on your MTAs is reduced without introducing false positive risks. For more information about Symantec Traffic Shaper, contact your Symantec sales representative. See About Messaging Gateway for Service Providers deployment on page 24. About plan for disk space storage The system requirements for Messaging Gateway for Service Providers describe the minimum system requirements that you need for available disk space. However, you should also consider your organization's plans to use the Log. The way that you intend to use these features affects the amount of disk space that you need to reserve. See System requirements on page 40. About firewall configuration After you install Messaging Gateway for Service Providers, you must configure your firewall to allow port connections for specific servers within your corporate network. See Ports required for Messaging Gateway for Service Providers on page 35.

34 Planning for installation About firewall configuration 34 Configuring firewall port connections for a standard deployment model Figure 2-6 illustrates a corporate network based on the standard deployment model that most organizations use. In this model, the Symantec Messaging Gateway for Service Providers resides behind a single firewall. If you use this model, you must configure your firewall to allow port connections from your Gateway MTA server so that it can access other servers over the Internet, such as the Symantec Global Threat Center and the Symantec LiveUpdate. Please note that the text "SMF" in the Gateway MTA SMF Scanner portion of the figure should instead read "SMG-SP." Figure 2-6 Sample Standard Deployment Model Workstation Internal MTAs Gateway MTA SMF Scanner 4 Corporate Firewall Internet 5 LDAP Server Table 2-2 lists the port numbers that are required for the standard deployment model.

35 Planning for installation Ports required for Messaging Gateway for Service Providers 35 Table 2-2 Firewall Port Connection Requirements for Standard Deployment Model Connection Description Inbound connection from SMF scanner to internal MTAs to relay messages Outbound connection from internal workstation to SMF web interface Inbound connection from Internet from incoming messages to Gateway MTA Outbound connection from SMF scanner to Internet for rule downloads and updates Inbound connection to Internal LDAP server from SMF scanner for LDAP queries Ports Ports required for Messaging Gateway for Service Providers Table 2-3 list of the ports that are required for Messaging Gateway for Service Providers. Table 2-3 Default ports Purpose Application layer protocol Transport layer protocol Default port Access to name service DNS UDP (TCP) 53 Access to time service NTP UDP 123 Access to the computer SSH TCP 22

36 Planning for installation About using Messaging Gateway for Service Providers with other filtering products 36 Table 2-3 Default ports (continued) Purpose Application layer protocol Transport layer protocol Default port Outbound access to the Internet HTTP TCP 80 Outbound access to Conduit HTTPS TCP 443 Outbound access to LiveUpdate HTTP TCP 80 MTA to Scanner (bidirectional) not applicable TCP See About firewall configuration on page 33. About using Messaging Gateway for Service Providers with other filtering products Messaging Gateway for Service Providers evaluates headers as part of the filtering process. Its ability to accurately identify spam depends on access to messages in their original form. Although MTAs or the products that add X-headers do not significantly affect filtering, your effectiveness is greater if you use unaltered message headers. Avoid placing Messaging Gateway for Service Providers behind other filtering products such as content filtering or MTAs. They can alter or remove pre-existing message headers or modify the message body. Some smaller organizations do not have dedicated gateway servers or a gateway layer. Instead, they deploy gateway servers and internal mail servers on the same computers. The best practice to add antivirus protection to Messaging Gateway for Service Providers software is to deploy the antivirus filtering feature. See About filtering for viruses on page 199. If you use a third-party antivirus product that has its own MTA, you may need to make the following adjustments: Ensure that Windows SMTP or Sendmail listens on port 25 and relays to an alternate port, such as port 26. Deploy the third-party antivirus product on another computer as a separate hop in the architecture of your inbound mail flow.

37 Planning for installation About adjusting MX records for Messaging Gateway for Service Providers software 37 If you choose to use a file system antivirus solution on the same computer as this Messaging Gateway for Service Providers, ensure that the antivirus solution does not scan the following directories: The temporary directory The Messaging Gateway for Service Providers working file directory and all of its subdirectories If your antivirus solution uses the Windows SMTP service, you do not need to make any changes. About adjusting MX records for Messaging Gateway for Service Providers software When you implement Messaging Gateway for Service Providers with a separate relay in front of your primary MTA, change the DNS mail exchange (MX) records. The records must point incoming messages to the new server that Messaging Gateway for Service Providers scans. The new server should have a lower MX number (a higher priority) than the previous MTA. If you list the Symantec-filtered MTA as a higher weighted MX record in addition to the existing MX record, a spammer can look up the previous MTA's MX record. This configuration lets the spammer send spam directly to the old server and bypass your spam filtering. Send test messages through Messaging Gateway for Service Providers and verify that the messages arrive at the target inbox before you re-direct your MX records. To prevent spammers from bypass the new spam-filtering servers, you should perform one of the following tasks: Remove the previous MTA's MX record from DNS. Block off the MTA from the Internet using a firewall. Modify the firewall's network address translation (NAT) tables to route external IP addresses to internal non-routable IP addresses. You can then map from the old server to the new Messaging Gateway for Service Providers-protected server. Use another method to protect the MTA. When you name the new Messaging Gateway for Service Providers-filtered MTA, ensure that the name that you choose does not imply its function. For example, poor choices would include: antispam.symantecexample.com, brightmail.symantecexample.com, or bas.symantecexample.com.

38 Planning for installation About access by the Server to perimeter information 38 About access by the Server to perimeter information You can deploy Messaging Gateway for Service Providers in communication with an MTA that is at the gateway or with an internal MTA. If you use an internal MTA, you must specify your internal ranges for IP-based reputation to work. See Specifying internal mail hosts on page 208. About preserving quarantined mail for access after update Symantec Messaging Gateway for Service Providers no longer supports message quarantine. If your organization wants to have access to quarantined mail on the spam spool directory from previous releases, you must back it up manually before updating to Symantec Messaging Gateway The default location for quarantined is as follows. Linux and Solaris: /var/spool/brightmail/spam Windows: <loadpoint or scanner dir>\bmispool\spam If you have configured a spool directory path that is different from the default, check the <spooldir> configuration in bmiconfig.xml file.

39 Chapter 3 Installing Messaging Gateway for Service Providers This chapter includes the following topics: Before you install System requirements New installation Installing Messaging Gateway for Service Providers on Linux and Solaris Configuring Messaging Gateway for Service Providers on Linux and Solaris Installing Messaging Gateway for Service Providers on Windows Update installation Updating one or more Solaris or Linux systems Updating one or more Windows systems Uninstalling Messaging Gateway for Service Providers Backing out of an update Before you install The Scanner processes messages according to the configuration options that you specify.

40 Installing Messaging Gateway for Service Providers System requirements 40 The Scanner contains the following subcomponents: Client Server System requirements If you install the Server component of the Scanner, the installer prompts you to register the product. Messaging Gateway for Service Providers requires multiple licenses for full functionality. One license activates scanning, while the other license updates rules. During installation, you can install only one license. You can install the additional license after the installation is complete. If you upgrade from Symantec Message Filter 6.3 and have a license already registered, you do not need to re-register your license. See About registering your Scanner license on page 210. Perform the following tasks (if they apply to your configuration) before you install Messaging Gateway for Service Providers: 1 Read the information about planning for installation. See About Messaging Gateway for Service Providers deployment on page Ensure that your organization uses static IP addresses. Messaging Gateway for Service Providers does not support the use of dynamically assigned IP addresses. 3 If you upgrade from a previous version of Messaging Gateway for Service Providers, review the information about migration. 4 Ensure that the hosts on which you plan to install Messaging Gateway for Service Providers components meet the minimum system requirements. See System requirements on page Obtain your license from Symantec and know the file location. See About registering your Scanner license on page 210. The system requirements for Messaging Gateway for Service Providers 10.5 are as follows: Table 3-1 lists the system requirements for Solaris.

41 Installing Messaging Gateway for Service Providers System requirements 41 Table 3-1 Requirement Platform Solaris system requirements Description Solaris 11/10 on 32-bit and 64-bit systems Solaris 9 on 32-bit system Note: Messaging Gateway for Service Providers is supported in English locales only. Processor RAM Disk space Mail transfer agent SPARC Ultra 4 4 GB 100 GB (10-15 GB for BEIK integrations) Any of the following: Sendmail 8.13 or later Sendmail 8.14 or later Postfix 2.6 or later Table 3-2 lists the system requirements for Linux. Table 3-2 Requirement Platform Processor RAM Disk space Mail transfer agent Linux system requirements Description Red Hat Enterprise Linux 5.X/6.X on 32-bit and 64-bit systems Note: Messaging Gateway for Service Providers is supported in English locales only. Intel DualCore processor 2.6 Ghz or later 4 GB 100 GB (10-15 GB for BEIK integrations) Any of the following: Sendmail or later Sendmail Switch 3.1 or later Postfix 2.6 or later Message Systems Table 3-3 lists the system requirements for Windows.

42 Installing Messaging Gateway for Service Providers New installation 42 Table 3-3 Requirement Platform Windows system requirements Description Any of the following: Windows Server 2003 (SP 1) Standard Edition or Enterprise Edition 64-bit system Windows Server 2008 Standard Edition or Enterprise Edition 64-bit system Windows Server 2008 R2 Standard Edition or Enterprise Edition 64-bit system Note: Messaging Gateway for Service Providers is supported in English locales only. Processor RAM Disk space Intel DualCore processor 2.6 Ghz or later 4 GB 100 GB (10-15 GB for BEIK integrations) Note: The file cacls.exe must be present on Windows 64-bit systems to ensure proper functioning of Symantec Messaging Gateway for Service Providers. This file is included in Windows 64-bit systems by default. New installation The following list contains recommendations and information for new Symantec Messaging Gateway for Service Providers installations: Verify that your MTA properly delivers and accepts before you install the Symantec Messaging Gateway for Service Providers. For information about planning for installation, see Symantec Messaging Gateway for Service Providers 10.5 Implementation Guide. Ensure that your new Symantec Messaging Gateway for Service Providers servers have been assigned static IP addresses. Symantec Messaging Gateway for Service Providers does not support the use of dynamically assigned IP addresses. Ensure that the computers on which you plan to install Symantec Messaging Gateway for Service Providers components meet the minimum system requirements. See Symantec Messaging Gateway for Service Providers 10.5 Implementation Guide.

43 Installing Messaging Gateway for Service Providers Installing Messaging Gateway for Service Providers on Linux and Solaris 43 Obtain your license from Symantec and make a note of the location where you saved the license file. Client-only installation is no longer supported on the Windows platform. Accordingly, update from a client-only installation of Symantec Message Filter 6.3 to Symantec Messaging Gateway for Service Providers 10.5 is also not supported. You must manually uninstall the 6.3 client. Installing Messaging Gateway for Service Providers on Linux and Solaris Before you begin with the installation, ensure that you have completed all of the preinstallation steps and your computer meets the system requirements. Also ensure that you install all the latest patches for your operating system. See Before you install on page 39. See System requirements on page 40. Note: Installation of Symantec Messaging Gateway for Service Providers in non-global zones is supported for Solaris 10 and 11. Messaging Gateway for Service Providers contains the following types of installation: Complete Server only Client only Installs all components of the Scanner. Installs only the server components of the Scanner. Installs only the client. You do not need to register a Scanner if you install only the client.

44 Installing Messaging Gateway for Service Providers Installing Messaging Gateway for Service Providers on Linux and Solaris 44 To install Messaging Gateway for Service Providers on Linux and Solaris 1 Download the file(s) for installation. The following table lists the files that are used for installation. Complete On 32-bit Linux: SYMCMsgFilter-complete-linux-i i386.rpm On 64-bit Linux: SYMCMsgFilter-complete-linux-x86_ i386.rpm On 32-bit Solaris: SYMCMsgFilter-complete-sparc32.pkg Server only On 32-bit Linux: SYMCMsgFilter-server-linux-i i386.rpm On 64-bit Linux: SYMCMsgFilter-server-linux-x86_ i386.rpm On 32-bit Solaris: SYMCMsgFilter-server-sparc32.pkg Client only On 32-bit Linux: SYMCMsgFilter-client-linux-i i386.rpm On 64-bit Linux: SYMCMsgFilter-client-linux-x86_ i386.rpm On 32-bit Solaris: SYMCMsgFilter-client-sparc32.pkg 2 Select the appropriate type of installation. 3 Install Messaging Gateway for Service Providers by typing the following command: On Linux: rpm -ivh complete path package name For example: rpm ivh /temp/symcmsgfilter-complete-linux-i i386.rpm On Solaris: pkgadd -d complete path of.pkg file For example: pkgadd -d /temp/symcmsgfilter-complete-sparc32.pkg After you complete the installation, configure the product. See Configuring Messaging Gateway for Service Providers on Linux and Solaris on page 45.

45 Installing Messaging Gateway for Service Providers Configuring Messaging Gateway for Service Providers on Linux and Solaris 45 Configuring Messaging Gateway for Service Providers on Linux and Solaris After you install Messaging Gateway for Service Providers, you must configure it. The configuration script enables you to configure the following files: bmiconfig.xml register.sh brightmail-env mailwall Note: You must manually enable zodiac and new dispositions after you run the configuration script. To configure Messaging Gateway for Service Providers on Linux and Solaris 1 Go to the location /opt/symantec/smg-sp/scanner/. 2 Run the configure.sh utility by entering the following command: configure.sh 3 Accept the End User License Agreement (EULA) by pressing y. 4 Enter the temp directory location. The default location is /tmp. 5 Enter the log directory location. The default location is /var/log/brightmail. 6 Enter the spool directory location. The default location is /var/spool/brightmail. 7 Accept the antivirus scanning support by pressing y. 8 Enter Symantec license file (.slf) path to register the product. Your license file is an.slf file that you receive from Symantec Enterprise Licensing System (ELS) when you purchased the product.

46 Installing Messaging Gateway for Service Providers Installing Messaging Gateway for Service Providers on Windows 46 Installing Messaging Gateway for Service Providers on Windows Before you begin with the installation, ensure that you have completed all of the preinstallation steps and your computer meets the system requirements. Also ensure that you install all the latest patches for your operating system. Note: The file cacls.exe must be present on Windows 64- bit systems to successfully install and run Symantec Messaging Gateway for Service Providers, along with the Microsoft Redistributable library. The file cacls.exe is part of the Windows 64-bit operating system by default, so it should already be present in most cases. Update installation See Before you install on page 39. See System requirements on page 40. To install Messaging Gateway for Service Providers on Windows 1 Log on to Windows as an administrator. 2 Download the installation file. 3 In the command line, type the following installer name: SYMCMg-sp-win64-installer-105.vbs 4 Press y when the message Do you agree EULA [Y/N]: appears. 5 Enter the location where you want to install Messaging Gateway for Service Providers. The default location is C:\program files\symantec\smg-sp. 6 Enter the temp directory location for JLU. The default location is C:\program files\symantec\smg-sp\temp. 7 Accept the antivirus scanning support by pressing y. 8 When the installation is complete, press Enter. The following list contains recommendations about upgrading to Symantec Messaging Gateway for Service Providers: Symantec Messaging Gateway for Service Providers supports updates from Symantec Message Filter 6.3 only. You must first update Symantec Brightmail

47 Installing Messaging Gateway for Service Providers Updating one or more Solaris or Linux systems 47 AntiSpam version or Symantec Brightmail Message Filter version 6.1.x/6.2.x to Symantec Message Filter 6.3 before you update to Symantec Messaging Gateway for Service Providers Symantec Messaging Gateway for Service Providers does not support the Control Center. The update process will prompt you to uninstall the Control Center. On updating from Symantec Message Filter 6.3 to Symantec Messaging Gateway for Service Providers 10.5 in Windows, the smg-sp folder is not created, although that folder is the default location for a fresh installation. Instead, all of the updated files are placed in C:\Program Files\Symantec\sbas by default. Updating one or more Solaris or Linux systems To update Solaris or Linux systems Note: The update process requires stopping and restarting the mail filtering engine. This will represent an "outage" of mail filtering and may, depending on your existing deployment, also represent an interruption in acceptance and delivery, so please plan accordingly. 1 Review the update notes. See Update installation on page If the machine you are updating is being administered by any instances of the Control Center, login to the Control Center and remove the machine to be updated from that Control Center s span of control. 3 Determine whether the system you are updating is intended to be a client, a server, or both, as this will determine which packages you need to install: Servers are machines that are currently running the Symantec Message Filter filtering engine, and will require you to install the SYMCmg-sp-server package. (If there is any doubt, you may verify this by executing a command such as pgrep bmserver or ps -e grep bmserver which will identify any instances of the bmserver process that are running.) Clients are machines that are running your Message Transfer Agent (MTA), e.g. SendMail, Postfix, JMS, etc. and will require you to install the SYMCmg-sp-client package. If your system is running both the MTA AND the Symantec Message Filter filtering engine, you will need to install the SYMCmg-sp-complete package.

48 Installing Messaging Gateway for Service Providers Updating one or more Solaris or Linux systems 48 4 Ensure that you have access to the packages that are appropriate for your operating system, architecture and client/server role: Linux 32 bit packages: SYMCmg-sp-client-linux-i i386.rpm (client) SYMCmg-sp-server-linux-i i386.rpm (server) SYMCmg-sp-complete-linux-i i386.rpm (contains both client and server) Linux 64 bit packages: SYMCmg-sp-client-linux-x86_ x86-64.rpm (client) SYMCmg-sp-server-linux-x86_ x86-64.rpm (server) SYMCmg-sp-complete-linux-x86_ x86-64.rpm (contains both client and server) Solaris 32 bit packages: SYMCmg-sp-client-sparc32.pkg (client) SYMCmg-sp-server-sparc32.pkg (server) SYMCmg-sp-complete-sparc32.pkg (contains both client and server) Solaris 64 bit packages: SYMCmg-sp-client-sparc64.pkg (client) SYMCmg-sp-server-sparc64.pkg (server) SYMCmg-sp-complete-sparc64.pkg (contains both client and server) 5 Once you have determined which package needs to be installed and that you have the correct software available to you, begin the upgrade process by executing the command /etc/init.d/mailwall stop. This command will ensure that all processes that are associated with the Symantec Message Filter are stopped.

49 Installing Messaging Gateway for Service Providers Updating one or more Solaris or Linux systems 49 6 Run the appropriate pkgadd or rpm command to update the software on the selected system: On Solaris 64 bit systems, select one of the following: Both client and server: pkgadd -d SYMCmg-sp-complete-sparc64.pkg or Server only: pkgadd -d SYMCmg-sp-server-sparc64.pkg or Client only: pkgadd -d SYMCmg-sp-client-sparc64.pkg On Solaris 32 bit systems, select one of the following: Both client and server: pkgadd -d SYMCmg-sp-complete-sparc32.pkg or Server only: pkgadd -d SYMCmg-sp-server-sparc32.pkg or Client only: pkgadd -d SYMCmg-sp-client-sparc32.pkg On Linux 64 bit systems, select one of the following: Both client and server: rpm -ivh SYMCmg-sp-complete-linux-x86_ x86-64.rpm or Server only: rpm -ivh SYMCmg-sp-server-linux-x86_ x86-64.rpm or Client only: rpm -ivh SYMCmg-sp-client-linux-x86_ x86-64.rpm On Linux 32 bit systems, select one of the following: Both client and server: rpm -ivh SYMCmg-sp-complete-linux-x86_ x86-64.rpm or Server only: rpm -ivh SYMCmg-sp-server-linux-x86_ x86-64.rpm or Client only: rpm -ivh SYMCmg-sp-client-linux-x86_ x86-64.rpm

50 Installing Messaging Gateway for Service Providers Updating one or more Windows systems 50 7 If the Control Center is installed on the server, you will be asked whether you want to un-install the control center. This is optional, but be aware that SMG-SP is NOT compatible with the Control Center and any attempts to use the Control Center to configure Symantec Messaging Gateway for Service Providers will result in unexpected operation. 8 Complete the rest of the installation steps as prompted by the installation package you have chosen in step 6. 9 After the appropriate package has been installed, you will be asked to run the configure.sh script. This script will aide you in customizing the specific product installation for your site, as well as guides you through the licensing process. (note: in the case of an upgrade, you will not have to re-install any licenses when migrating from Symantec Message Filter to Symantec Messaging Gateway for Service Providers). 10 Test the updated installation and verify the post-installation steps as described in the Symantec Messaging Gateway for Service Providers Implementation Guide. 11 Repeat the above steps for each machine on which you intend to run the Symantec Messaging Gateway for Service Providers product. Updating one or more Windows systems To update Windows systems 1 Review the update notes. See Update installation on page Stop all services that are currently running on your system, i.e., Brightmail Agent, Brightmail Conduit, Brightmail LiveUpdate, Brightmail Server, Brightmail SMTP Harvester, Brightmail Virus Cleaner 3 Run the following scanner installer: SYMCmg-sp-win64-installer-105.vbs Note: because the Windows client has been deprecated, you cannot do a client update on Windows. 4 Test the updated installation and verify the post-installation steps as described in the Symantec Messaging Gateway for Service Providers Implementation Guide. 5 Repeat the above steps for each machine on which you intend to run the Symantec Messaging Gateway for Service Providers product.

51 Installing Messaging Gateway for Service Providers Uninstalling Messaging Gateway for Service Providers 51 Uninstalling Messaging Gateway for Service Providers When you uninstall Messaging Gateway for Service Providers, the uninstaller utility removes the files and directories that were initially installed with the installation script. However, the files that were modified during the installation are not removed. When the uninstallation is complete, the uninstaller utility provides a list of the directories and files that were not removed. If you do not want to reinstall the product, you can remove these files manually. To uninstall Messaging Gateway for Service Providers from Linux and Solaris 1 Log on Linux or Solaris as the root user. 2 Type the following command to uninstall Messaging Gateway for Service Providers: On Linux: rpm -e package name For example: rpm -e SYMCMsgFilter-complete-linux-i i386 On Solaris: pkgrm package name For example: pkgrm SYMCMsgFilter-complete-sparc32 3 Press y to uninstall. To uninstall Messaging Gateway for Service Providers from Windows 1 Log on to Windows as the root user. 2 In the command line, type the following installer name: SYMCmg-sp-win64-installer-105.vbs 3 Press y when the message Do you want to uninstall? appears. Backing out of an update If your update fails, carefully record any error messages and symptoms and open a case with Symantec Support for Symantec Messaging Gateway for Service Providers.

52 Installing Messaging Gateway for Service Providers Backing out of an update 52 To back out of an update 1 Completely uninstall Symantec Messaging Gateway for Service Providers from all respective servers. 2 Reinstall the original version of Symantec Messaging Gateway for Service Providers and reinstall all of its components. 3 On the Symantec Messaging Gateway for Service Providers Scanners, stop the Symantec Messaging Gateway for Service Providers services and replace the new bmiconfig.xml file with the backup you created before you began the installation. 4 Restart the Symantec Messaging Gateway for Service Providers services.

53 Chapter 4 Optimizing Messaging Gateway for Service Providers This chapter includes the following topics: Managing your system for service providers Optimizing performance on Solaris SPARC Optimizing performance on Linux Optimizing performance on Windows About enhancing performance for outbound About the factors that affect performance Managing your system for service providers This section provides recommendations specific to service providers. It provides suggestions for how you can tune Messaging Gateway for Service Providers to make it more effective for your unique environment. About IPv6 address in Messaging Gateway for Service Providers Messaging Gateway for Service Providers now accepts inbound messages from any MTA with IPv6 addresses. You can also add IPv6 addresses in the allowedblockedlist.txt. IPv6 is not supported for the following features:

54 Optimizing Messaging Gateway for Service Providers Managing your system for service providers 54 Connection Classification and Fastpass DNS IP reputation About the Sender Reputation Service The Sender Reputation Service is the name for a set of downloadable IP address lists that you can use to block SMTP connections from known spam IP addresses or allow SMTP connections from known reputable IP addresses. You can import the lists into your zone files on your DNS servers. You can also deploy the lists at your firewalls, mail transfer agents, or routers. Symantec monitors hundreds of thousands of sources to determine how much is sent from these addresses is legitimate and how much is spam. By evaluating the sender according to dimensions such as mail volume, the percentage of spam sent, and a variety of vulnerabilities, the Sender Reputation Service creates a reputation profile for a given IP address. from these sources can then be blocked or allowed based on the reputation value of the source that Symantec determines. The Sender Reputation Service currently includes the following classification lists of IP addresses, which are continuously compiled and updated: Open Proxy List IP addresses that are open proxies. When this option is enabled, the flow of spam through open proxy servers is blocked. This method is the preferred conduit for spammers. Safe List IP addresses from which almost no outgoing is spam. These sources have sent a large amount of mail for a considerable period and have not had any messages marked as spam by Symantec. This list lets legitimate mail to flow through to recipients immediately, bypassing further filtering. Note: You can enable the DNS IP reputation feature if you do not want to use the Sender Reputation Service. See About DNS-based IP reputation on page 58. Benefits of the Sender Reputation Service The Sender Reputation Service provides the following benefits to users:

55 Optimizing Messaging Gateway for Service Providers Managing your system for service providers 55 Better resource utilization More effective and accurate spam filtering Built-in quality assurance When you block spam at the gateway according to its IP address, you reduce the amount of that your downstream servers process and store. This method reduces the amount of hardware that is needed at your site to handle . Because the message source (connecting IP address) is hard for spammers or forge, source-based filtering is a powerful way to filter . The lists are entirely data driven. Organizations cannot pay or petition to be added to or removed from this list. To ensure accuracy, the lists are updated as frequently as every hour. Symantec applies many measures and processes to ensure that the lists are as accurate as possible. For example, when Symantec compiles the Safe List, IP addresses whose owners are changing are automatically eliminated. About Open Proxy/Safe List formats Symantec supplies the Open Proxy List and the Safe List in the following formats: Plain text CIDR A plain text file with one IP address per line. A plain text file with one IP address in CIDR notation per line. Currently, all CIDR addresses in the lists end with /32. Each address denotes one IP address. About downloading the lists Symantec recommends that you write a script to download and install the lists that you want. The script downloads the appropriate files from URLs. It also supplies a user name and password that is available from a Symantec Support. The files and URLs are as follows: Open Proxy List Safe IP List (One IP address per line) For example, your script can use the GNU wget utility to automatically download the lists that you need. The following sample wget command downloads the plain text format composite suspect IP and Open Proxy List from Symantec, provided that the file size is different from the file on the local disk, in effect, when a new version of the file is detected.

56 Optimizing Messaging Gateway for Service Providers Managing your system for service providers 56 $ wget -cq --http-user=user --http-passwd=passwrd where $user and $password are your user name and password. Since the lists change every hour, run a similar script every 30 minutes to check whether an updated file is available. When an updated file is detected, the wget script downloads the full file. If you want to download more than a single list, you can put the URLs into their own file and use the --input-file=url_file.txt option of wget. After you download the files that you want, your script should deploy the files to the appropriate network location. See About deploying the lists on page 56. About deploying the lists Deploy the lists where it makes the most sense given your network architecture as follows: DNS server zone files MTA The most common deployment strategy is to convert the IP addresses to zone files and import the file through zone transfer into a local DNS server cluster for real-time blacklists (for example, spamhaus data feed synchronized to a local LAN DNS). However, it may have negative performance impacts with a remote server (for example, shared spamhaus public server over the Internet). You might find it easier to deploy the lists in the gateway MTAs with reject and allow features. Routers or firewalls Another place to deploy the lists is at your routers or firewalls. If your device supports importing an Access Control List (ACL), deploy lists at your routers or firewalls to block traffic with no impact on your MTAs. You do not need to make any changes to your Symantec software installation to use the lists. Addressing end user and mailer concerns The Sender Reputation Service gives you the power to block more connections according to the quality of source. Table 4-1 provides some guidance on how to deal with the customer service and the help desk situations that may arise due to increased blocking.

57 Optimizing Messaging Gateway for Service Providers Managing your system for service providers 57 Table 4-1 Situation Solutions for increased blocking issues Solution A user feels legitimate was not delivered. A bulk mailer complains about being unable to send mail to one of your customers. In some cases, legitimate mail that is sent from an IP address which generates a significant percentage of spam is blocked. Also note that the sites that let users forward their unfiltered to external accounts may have their servers look like they are a spam-sending source. You need to balance the benefit of reduced bandwidth and resource costs with your tolerance for false positives. Increase the threshold for extended Suspect Spam list as appropriate. Explain to the user that the blocking decision was made based on the amount of spam that comes from the sender s server. Explain to the bulk mailer that servers and IP addresses are placed on the lists that are based on objective analysis of traffic from those servers. If the Sender Reputation Service identifies a server as being a spam source, the only way to remove it from the list is to ensure that the server ceases to disseminate spam. If a mail server that is considered to be a spam source by the Sender Reputation Service does not send unwanted messages for a given time period, that mail server's profile is updated accordingly when the lists are next generated. A bulk mailer wants to contact Symantec for removal. Given that the Sender Reputation Service is data- driven based on sending patterns, it is not a Symantec practice to manually place or remove IP addresses to or from the lists. Do not encourage bulk mailers to contact Symantec for remediation through Symantec Support. When responding to mailers, stress that they should adhere to generally accepted best practices to avoid having their mail filtered as spam such as the following: All mailing list members must be added by verified opt-in (double opt-in). Users must have options to opt-out of information sharing. All must be RFC-compliant. For more information about how RFC pertains to , on the Internet, go to the following URL: The privacy policy must be visible before sign-up. All servers that connect to Symantec customer mail servers must be secured to prevent unauthorized use (may not be an open proxy or open relay). Communications must be clear and not attempt to disguise content or origin. All addresses receiving more than five hard bounces from the customer mailer daemon must be removed.

58 Optimizing Messaging Gateway for Service Providers Managing your system for service providers 58 Table 4-1 Situation Solutions for increased blocking issues (continued) Solution A bulk mailer wants to be manually placed on the Safe List. Symantec generates the Safe IP address list according to its analysis of traffic and its automated review of sources on the Internet. Organizations or companies cannot petition to be manually placed on the Safe List. About DNS-based IP reputation DNS-based IP (DNS IP) reputation allows the delivery of the Symantec Global Bad Senders list, which is the largest Symantec IP reputation list. Symantec Global Bad Senders list is substantially larger than the historical downloaded rules in the Allowed Senders and Blocked Senders (libpermit) module. You must use Symantec Global Bad Senders list only against the external connecting IP as it includes IPs that are not authorized to make mx-to-mx type connections, for example dynamic IP ranges. Following are the reputation values with its description in a DNS IP reputation service: Reputation Values in the bmiconfig.xml file Description OPL Safe list True False True False The IP addresses that are zombies, open proxies, snowshoe IPs, spamming IPs, and the IPs that are not authorized to make mx-to-mx type connections. Also known as Global Bad reputation or Symantec Global Bad Senders. The IP addresses from which almost no outgoing is spam. Also known as Global Good reputation. For example, if an inbound arrives in your organization and the DNS IP reputation is enabled, the IP address of this inbound is sent to the Symantec DNS reputation server. If this IP address in the Symantec DNS reputation server is recorded as bad, an Open Proxy List (OPL) verdict is provided back to the Symantec Messaging Gateway for Service Providers. See Enabling or disabling DNS IP reputation on Symantec Messaging Gateway for Service Providers on page 59. See Disabling rule updates in the senders list on page 60. See About local DNS server configuration on page 61. See About DNS latency parameters for DNS IP reputation on page 62.

59 Optimizing Messaging Gateway for Service Providers Managing your system for service providers 59 Enabling or disabling DNS IP reputation on Symantec Messaging Gateway for Service Providers After you install and configure Messaging Gateway for Service Providers, you must enable DNS IP reputation on your system to filter your inbound . To enable DNS IP reputation on Messaging Gateway for Service Providers 1 Open bmiconfig.xml in a text editor. 2 Modify the value of the dnsreputationlookups element to true as follows: <dnsreputationlookups enabled="true"/> 3 Modify the value of the dnslatencytracker element to true as follows: <dnslatencytracker enabled="true"> 4 Save the file and exit. 5 To apply the bmiconfig.xml settings, either restart the appropriate server or kick the server. For example: On Windows systems, type the following command: <path>\scanner\bin\kicker.exe -s BMISERVERSVC On UNIX systems, type the following command: <path>/scanner/bin/kicker <path>/scanner/etc/bmiconfig.xml <path>/scanner/jobs/bmserver/bmserver.pid To disable DNS IP reputation on Messaging Gateway for Service Providers 1 Open bmiconfig.xml in a text editor. 2 Modify the value of dnsreputationlookups element to false as follows: <dnsreputationlookups enabled="false"/> 3 Modify the value of dnslatencytracker element to false as follows: <dnslatencytracker enabled="false">

60 Optimizing Messaging Gateway for Service Providers Managing your system for service providers 60 4 Save the file and exit. 5 To apply the bmiconfig.xml settings, either restart the appropriate server or kick the server. For example: On Windows systems, type the following command: <path>\scanner\bin\kicker.exe -s BMISERVERSVC On UNIX systems, type the following command: <path>/scanner/bin/kicker <path>/scanner/etc/bmiconfig.xml <path>/scanner/jobs/bmserver/bmserver.pid See About DNS-based IP reputation on page 58. See Disabling rule updates in the senders list on page 60. See About DNS latency parameters for DNS IP reputation on page 62. Disabling rule updates in the senders list Messaging Gateway for Service Providers can filter s based on verdicts from the reputation database. Following are the two reputation databases that are available: The Symantec Global Bad Senders (DNS IP reputation) The Allowed Senders List and the Blocked Senders List (senders list) The senders list updates its reputation data through rule updates. It also enables you to add local reputation information. The DNS IP reputation is a superset of the information available in the senders list. When both these reputation databases are enabled, the DNS lookup in the DNS IP reputation and the rule updates in the senders list use more bandwidth to collect the same reputation information from the Symantec servers. Therefore, after you enable DNS IP reputation, Symantec recommends that you disable the rule updates in the senders list without disabling the senders list.

61 Optimizing Messaging Gateway for Service Providers Managing your system for service providers 61 To disable rule updates in the senders list 1 Open the bmiconfig.xml file by using a text editor. 2 Comment the rules tag in libpermit as follows: <module critical="false" enabled="true" name="libpermit" xsi:type="permitmoduletype"> <!--rules> <url rulename="permit">_https://aztec.brightmail.com/rules4/ permit_rules </url> </rules--> <opldisposition enabled= false /> <safedisposition enabled= false /> </module> 3 Save the file and exit. 4 To apply the bmiconfig.xml settings, either restart the appropriate server or kick the server. For example: On Windows systems, type the following command: <path>\scanner\bin\kicker.exe -s BMISERVERSVC On UNIX systems, type the following command: <path>/scanner/bin/kicker path/scanner/etc/bmiconfig.xml path/scanner/jobs/bmserver/bmserver.pid See About DNS-based IP reputation on page 58. See Enabling or disabling DNS IP reputation on Symantec Messaging Gateway for Service Providers on page 59. About local DNS server configuration The DNS IP reputation information is delivered through DNS lookups instead of delivering information through the rule updates. Reputation data is stored in the DNS TXT record for a given IP address. When Messaging Gateway for Service Providers is enabled with DNS IP reputation, for every inbound connection, Messaging Gateway for Service Providers initiates a DNS lookup with the Symantec DNS reputation server. If the connecting IP is external, DNS lookup is initiated on each connection. If the connecting IP is internal, DNS lookup is initiated for the first external IP in each message. The DNS lookup process may consume time based

62 Optimizing Messaging Gateway for Service Providers Managing your system for service providers 62 on the proximity of the scanner to the Symantec DNS reputation server. Therefore, you can configure the Sender Reputation Service to maintain the IP reputation information locally and avoid time latency. See About the Sender Reputation Service on page 54. See About DNS-based IP reputation on page 58. About DNS latency parameters for DNS IP reputation DNS latency is the time that the system takes to look up DNS information. By using the DNS latency parameters, administrators can control the effect of latency on DNS lookups that take place as part of the DNS IP reputation module's execution of mailwall scanning. Note: When the DNS lookup response slows due to network congestion, you can temporarily disable the DNS IP reputation module and then re-enable the module when the network congestion decreases. However, when you disable the DNS IP reputation module, the throughput may increase, but the effectiveness or correctness of scanning may decrease. You can tweak these settings for optimum function as the need arises. The following table lists the DNS latency parameters in the bmiconfig.xml file for DNS IP reputation: Parameter dnslatencytracker windowsizelookups allowedlatencyseconds dnsbypassperiodseconds Values True False Description Enables or disables DNS latency. The default value is false. The number of messages that the mailwall samples to determine whether the module should be enabled or disabled. The default value is 20. The average of the DNS latency values for the number of messages that the mailwall samples. The default value is 5 seconds. The number of seconds for which the DNS IP reputation module is disabled. After this period, the sampling starts again. The default value is 300. For example, assume that you set the following DNS latency parameters:

63 Optimizing Messaging Gateway for Service Providers Managing your system for service providers 63 windowsizelookups= 20 allowedlatencyseconds= 5 dnsbypassperiodseconds= 300 The mailwall samples 20 messages and calculate the average DNS lookup time for these 20 messages. If the average is greater than 5 seconds, the DNS IP reputation module is disabled for 300 seconds. After 300 seconds, the mailwall repeats this process. See About DNS-based IP reputation on page 58. See Enabling or disabling DNS IP reputation on Symantec Messaging Gateway for Service Providers on page 59. About selecting the optimal rule set to optimize performance Selecting the right rule set is an important step in optimizing performance. For high load or hardware limited environments, the Service Provider Express rule set delivers effective spam detection at reduced hardware requirements. The default rule set is Server Provider Full. Implementing custom rule sets In almost all cases, the standard antispam rule sets that Symantec provides meet the needs of our customers. In some cases, Symantec Security Response may make available a custom rule set available to a customer. To implement a custom rule set 1 Open bmiconfig.xml in a text editor. 2 Specify the custom URL in the rules section as follows: <rules> <url rulename="rules" defaultdisposition="spam" displayname=" Body Hash Rules" enabled="true"> </rules> Using Keep Alive You can use Keep Alive to maintain idle client-server connections. Alternatively, you can leave the configuration file unaltered and inherit your operating system's default behavior for Keep Alive.

64 Optimizing Messaging Gateway for Service Providers Optimizing performance on Solaris SPARC 64 To configure Keep Alive through the bmi file 1 Using a text editor, go to the bmserver section of the bmiconfig.xml file. 2 Add the following lines to the bmserver section: <keepalive enabled="true" /> to turn on keep alive for connections <keepalive enabled= "false" > to turn off keep alive Optimizing performance on Solaris SPARC The multi-threaded capabilities of the UltraSPARC T1 and T2 processors with CoolThreads provide fast and efficient message processing. The UltraSPARC T Series processors consist of a number of cores each on which reside multiple hardware threads giving you a total number of logical processors. For example, the T1000 has a T1 processor with 8 cores and 4 hardware threads per core for a grand total of 32 logical processors. The Solaris operating system reports 32 CPUs on the computer. 8 cores * 4 hardware threads = 32 logical processors The number of service threads should be equal to the number of logical processors on the computer (the number of CPUs reported by Solaris). For details on these capabilities including benchmark data, on the Internet, go to the following URL: Software tuning for Messaging Gateway for Service Providers is required to maximize message processing and includes the following tasks: Increasing service threads The maxservicethreads attribute limits the maximum number of threads that can exist at one time. The default value is 32. Increasing the value increases the speed in which messages are processed due to the multi-threaded capability of the T2000.

65 Optimizing Messaging Gateway for Service Providers Optimizing performance on Solaris SPARC 65 Integrating Multi-Threaded malloc (mtmalloc) Mtmalloc is a version of the standard UNIX malloc memory allocation library that is especially tuned for multi-threaded programs. The Solaris OS mtmalloc library is tuned to minimize lock contention resulting in a lower probability that a thread is suspended while it waits to obtain a lock within the memory allocation library. To enable mtmalloc, you must change the LD_PRELOAD environment variable to point to the mtmalloc shared library. You can also use alternative mallocs. The mtmalloc libraries are faster than the standard malloc library. These libraries come at the cost of higher virtual memory usage and in addition to VM fragmentation. The higher virtual memory usage can eventually lead to a heap exhaustion on a server. Ensure that you periodically restart the bmserver process to avoid issues. For more information, visit the Sun Web site. For information on increasing the number of available service threads in the bmiconfig file, see BrightmailBluePrintJune2009.pdf. To increase the number of available service threads through the bmiconfig.xml file Modify the value of maxservicethreads. The default value is 32. To use the Solaris OS mtmalloc library 1 Using any standard text editor, open the file brightmail-env. By default, this file is located as follows: /opt/symantec/smg-sp/scanner/etc/brightmail-env If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. 2 Add the following lines: LD_PRELOAD=libmtmalloc.so export LD_PRELOAD 3 Save brightmail-env.

66 Optimizing Messaging Gateway for Service Providers Optimizing performance on Solaris SPARC 66 To use the Solaris OS libumem library 1 Using any standard text editor, open the file brightmail-env. By default, this file is located as follows: /opt/symantec/smg-sp/scanner/etc/brightmail-env If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. 2 Add the following lines: LD_PRELOAD=libumem.so export LD_PRELOAD 3 Save brightmail-env. Optimizing performance with Java Message Service You can increase the number of threads to take advantage of Cool threads hardware and feed the high number of threads in AS scanner. You can also use the memory queue to simulate high performance SAN storage (not suitable for production use since the queue fails on power outages). For more information about how to optimize performance for Java Message Service, on the Internet, go to the following URLs: To increase the number of threads 1 Open the following file in a text editor: /opt/sun/comms/messaging64/config/imta.cnf 2 Change the following values: MIN_PROCS=8 MAX_PROCS=32 3 Save and close the imta.cnf file.

67 Optimizing Messaging Gateway for Service Providers Optimizing performance on Linux 67 To simulate high performance SAN storage 1 Open the following file in a text editor: /opt/sun/comms/messaging64/config/imta_tailor 2 Modify the following value: IMTA_QUEUE=/var/run/queue/ 3 Save and close the imta_tailor file. Optimizing performance on Linux The number of service threads should be equal to two (2) times the number of logical processors on the computer (the number of CPUs reported by Linux). Optimizing performance on Windows The number of service threads should be equal to two (2) times the number of logical processors on the computer (the number of CPUs reported by Windows). About enhancing performance for outbound Messaging Gateway for Service Providers is not an MTA, but rather a filtering product that integrates with existing MTAs. If you do not have a need to filter outbound mail, you can save processing overhead and not filter outbound mail. To disable outbound mail filtering, adjust your MX records and smarthost configurations to ensure that outbound mail does not go through the same Messaging Gateway for Service Providers-filtered SMTP server. For more information about how to configure outbound scanning to fit your organization's specific needs, contact your Symantec sales representative. Configuration tips to reduce outbound spam Outbound spam affects the delivery of legitimate mail, tarnishes brand reputation, and imposes unnecessary costs. One of the key enablers for outbound spam is the proliferation of botnets. Botnets are vast networks of compromised "zombie" computers that collectively send out huge quantities of spam and other threats. By controlling a botnet, a malicious sender can disseminate vast quantities of spam, engage in identity theft, and infect computers with spyware. You can control a botnet when you funnel traffic through the legitimate servers that service providers manage.

68 Optimizing Messaging Gateway for Service Providers About the factors that affect performance 68 Table 4-2 lists suggested Messaging Gateway for Service Providers configurations that you can make to the configuration file (bmiconfig.xml) to enhance outbound scanning. Note: These modifications fall outside the scope of supported customer operations. Any changes that are described in Table 4-2 should only be made with the assistance of your technical account manager or Symantec Support. Table 4-2 Task Change the default rule set. Suggested configurations for outbound scanning Description Change the default rule set to Service Provider Express. This rule set provides the following features: Primarily based on signatures for known and active spam attacks Excellent message-per-second throughput and CPU stability Low false positive rate Best for minimizing hardware costs Create distinct configuration files for inbound and outbound filtering. Disable inbound-focused filtering technologies. Disable suspect thresholds. Messaging Gateway for Service Providers installations should have separate configuration files for inbound and outbound filtering to allow for separate tuning. To avoid the risk of false positives for outbound filtering, disable the following technologies when you scan outbound Consent service (libpermit) See libpermit on page 96. Header rules within the Heuristics module (also known as the Spamhunter module) See About the Virus Services Type on page 87. Fastpass See libfastpass on page 90. Disable any suspect or gray thresholds for outbound filtering. See About the Consent Service Type on page 89. About the factors that affect performance Many factors can affect the performance of Messaging Gateway for Service Providers. This section provides guidelines regarding those factors and suggestions that may improve performance.

69 Optimizing Messaging Gateway for Service Providers About the factors that affect performance 69 When you evaluate your hardware needs, tailor your messaging environment for the MTA and your mail flow, rather than for Messaging Gateway for Service Providers. Overall performance involves several factors. Some factors depend on the configuration options and deployment options that you choose. Others depend on external factors, such as the percentage of your organization's that is spam. Hardware components that affect performance The components that make up the system affect its performance. Increase performance by increasing the physical make-up of your system. Consider the following recommendations for the computers that run Symantec software: Network CPU (speed and type) RAM (speed and type) Use switched 100 Mb/s fast Ethernet or gigabit network connections between each Scanner. Increase the number and speed of CPUs per server. We recommend dual Intel Xeon processors if your traffic rate suggests the need. Track memory usage and increase RAM as necessary to minimize or avoid disk swapping. Environmental factors that affect performance Environmental factors affect the performance of the system. These factors include the usage patterns of your particular deployment. Collect the following information about your environment to understand typical information: MTA version Outgoing SMTP connections Ensure that you have the most up-to-date version of your MTA that Symantec supports. Different MTAs may perform differently with the product due to integration differences and configuration differences. Determine if end users' clients connect to the MTA for outgoing SMTP connections. This configuration can cause additional overhead because it swells local disk queues with destined for the remote servers that may not immediately accept new . Larger queues on disk result in reduced MTA performance. Ideally, you should configure inbound and outbound mail streams to work on separate computers.

70 Optimizing Messaging Gateway for Service Providers About the factors that affect performance 70 External and internal MTA performance Determine the performance of the MTA that sends inbound to your MTA, and the performance of your gateway and internal MTAs and message store. The characteristics of messages that are sent and received can affect performance. Key parameters to identify are as follows: Average message size Number of messages with attachments Average attachment size Types of attachments Percentage of spam in the traffic Percentage of virus-infected messages in the traffic Types of end users (ISP or enterprise) About the Messaging Gateway for Service Providers settings that affect performance The following settings can affect Messaging Gateway for Service Providers performance:

71 Optimizing Messaging Gateway for Service Providers About the factors that affect performance 71 Filtering components The following filtering components can affect system performance: Outgoing versus incoming filtering Filtering outgoing messages causes additional overhead. Custom filters Infrequently, custom filters may affect performance. Monitor the system after introducing them. Antivirus scanning Monitor performance and consider lowering the maximum scanning depth and maximum attachment size to improve it. Although the impact varies by deployment, antivirus scanning can decrease performance by up to 25% or more. Consider performing virus scanning after spam filtering. The load that the antivirus scanner processes is reduced by filtering out spam first. Group policies If a message has more than one recipient and each message has a different policy, then the message may need to be bifurcated (split into two or more messages) for modification before delivery. The bifurcated messages that result from many group policies may degrade performance. Use group policies as necessary but be aware that a high number of policies can affect performance. Table 4-3 lists some additional factors about performance that you should consider before you install the product. Table 4-3 Factor Factors that impact performance Questions to ask Performance/effectiveness implications Characteristics of the computer that runs Messaging Gateway for Service Providers What is the processor speed? How much memory is available? What is the current load on the computer? Are there spare CPU cycles? Filtering is primarily CPU-dependent. But statistics, logging, the Conduit, and antivirus filtering (if deployed) can cause moderate disk I/O. Assess the current server load if Messaging Gateway for Service Providers is deployed on an existing server.

72 Optimizing Messaging Gateway for Service Providers About the factors that affect performance 72 Table 4-3 Factors that impact performance (continued) Factor Questions to ask Performance/effectiveness implications Mail flow How much mail does the Server receive? What is the average number of messages per second? What is the peak message traffic? What is the average size of mail messages? If Messaging Gateway for Service Providers is deployed after other filters, there is lower mail volume and processing requirements for Symantec Brightmail software. Spam flow What is the estimated percentage of spam in the overall mail flow (20%, 50%, 70%)? Smaller amounts of spam result in lower performance because legitimate messages must pass all filtering tests. Optional features Will antivirus filtering be running? Will you create custom rules? All of these optional features decrease performance. Will you be spooling messages to disk? Shared versus dedicated Will the Server be on a dedicated computer? Will the Client and Server run on the same computer? For maximum performance, employ a dedicated Server.

73 Chapter 5 Configuring Messaging Gateway for Service Providers This chapter includes the following topics: About configuring settings for a large number of users Setting up Scanner services on Linux and Solaris Setting up Scanner services on Windows About configuration file elements About the Installation section About the Services section About the Spam Service Type About the Virus Services Type About the Consent Service Type libfastpass libpermit About the Language Service Type About the Reinsert Service Type About the Programs section About the Filter program

74 Configuring Messaging Gateway for Service Providers About configuring settings for a large number of users 74 About the Client program About the Server program About the Conduit program About the LiveUpdate program About the AntiVirus Cleaner program About the Engine section About bmicheckreputation About the Policies section Adding a new disposition through the command line Updating an existing disposition Changing the destination string of an existing disposition Changing the order of message scanning Managing logs for stand-alone Scanners About the log level element About the log period element About the periodunits element About the numberretained element About managing statistics for stand-alone Scanners About conduit rule updates About LiveUpdate rule updates About configuring settings for a large number of users You might want to manage your scanners by using a third-party management software when your site has a large number of users or a high flow. Note: Once installation and registration are complete, do not install any other software or follow any test or other procedures.

75 Configuring Messaging Gateway for Service Providers Setting up Scanner services on Linux and Solaris 75 To configure and manage services on Linux and Solaris, use a shell script. By default, this shell script is located in the following directory: /opt/symantec/smg-sp/scanner/sbin/controller.sh Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. To configure and manage services on Windows, use the Windows Services tool. See Setting up Scanner services on Windows on page 76. Setting up Scanner services on Linux and Solaris The controller.sh tool has the following syntax: controller.sh <action> <component> where <component> is a service within Messaging Gateway for Service Providers and <action> is a request for status or for change to the specified component. The following components are available: bmserver bmifilter conduit cleaner jlu-controller The Server, which the Runner controls The Filter (Sendmail only), which the Runner controls The Conduit, which the Runner controls The AntiVirus Cleaner, which the daemon controls The LiveUpdate, which the Runner controls The following actions are available: start enable disable Have a component begin processing. If the specified component is already processing, nothing is done. Have a component stop processing. If the specified component is not processing, nothing is done. The next time the Runner restarts, allow a service to begin processing. The next time the Runner restarts, prevent a service from beginning to process. Once disabled, a service cannot be initiated with start until enabled.

76 Configuring Messaging Gateway for Service Providers Setting up Scanner services on Windows 76 kick Sends a message instructing the process to reload its configuration or, in the case of LiveUpdate and Conduit, to also load new rules. Upon successful completion, controller.sh returns 0, otherwise a non-zero value is returned. In the case of the AntiVirus Cleaner, new configuration data cannot be kicked immediately. It is pushed for loading the next time the Cleaner starts. Note: Source $LOADPOINT/etc/brightmail-env before you run kick. The LOADPOINT is the directory into which you installed the product. isenabled isactive Tests to see if the given component is enabled. If the service is enabled, a value of 0 is returned. Otherwise, a value of 1 is returned. Determines if a service is running. If the service is running, a value of 0 is returned. Otherwise, a value of 1 is returned. To set up Scanner services on Linux or Solaris 1 Log on to the Scanner host as user mailwall. 2 Type the following command to start the runner: /etc/init.d/mailwall start 3 If you do not use Sendmail as the MTA, stop and disable the Filter. controller.sh stop bmifilter controller.sh disable bmifilter Setting up Scanner services on Windows You can control all Windows Scanner services through the Windows Services console. To set up Scanner services on Windows 1 On the Windows Menu, click Start, then Administrative Tools, then Services. 2 Enable the Server, the LiveUpdate, the Conduit, and the AntiVirus Cleaner within Windows Services. 3 In the properties for each service, set it to start automatically whenever Windows is started. For each service, right-click the service, click Properties, and change Startup Type from Manual to Automatic. 4 Start the Server, Conduit, AntiVirus Cleaner, and LiveUpdate.

77 Configuring Messaging Gateway for Service Providers About configuration file elements 77 About configuration file elements The configuration file contains the element settings that the Scanner uses for configuration. When you use a Scanner in stand-alone mode, you can edit the configuration file to modify its behavior. You can find the configuration file in the following location: Linux and Solaris /opt/symantec/smg-sp/scanner/etc/bmiconfig.xml Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. Windows \Program Files\Symantec\smg-sp\Scanner\Config\bmiconfig.xml Note: You should make a backup copy of the bmiconfig.xml file before you make any modifications. The configuration file is formatted in UTF-8, but all data in the file must be maintained in standard ASCII. Data within the file is written in XML. About the Installation section The <installation></installation> section contains a set of configuration elements that apply to all other major sections of bmiconfig.xml. The following is an example from a Windows installation. It varies slightly depending on the operating system that you use: <installation xmlns:xsi=" xmlns:bmi=" os= windows arch= x86 version=" "> Table 5-1 lists the Installation section valid elements and their values.

78 Configuring Messaging Gateway for Service Providers About the Installation section 78 Table 5-1 Element totalprofiling Valid Installation section elements Description Tracks the performance of each module and records CPU usage levels for each message in a stat file. The entry in the stat file consists of the total CPU time for message processing (that is, from the time the message enters the system to the time the message exits). The elements usertime and systemtime are added in the <MSG> node. These elements break down the message processing time down into CPU user time and CPU system time. The Conduit reads the per message stat files and creates a stat package that it sends to BLOC. A "profiling" element is added in the module node to enable individual module level profiling. It has a default value of "true." A value of "false" disables the detailed profile output in the stat. Module level detail profiling is outputted for each enabled module. So if only totalprofiling is enabled, there is no separate entry in the stat file. An example of the profiling element is as follows: <module xsi:type='bodyhashmoduletype' name='libbh' enabled='true' critical='false' profiling='false'> <url> </module> An example of the engine stats file format is as follows: <MSG ip=" " etime=" " latency="16604" bytes="42395" usertime=" " systemtime="154321" helo="doedevimage" from="[email protected]"> <mod name=libbh usertime="12345" systemtime="54321" /> <mod name=libregex usertime="23451" systemtime="43215" />... (N number of profiled enabled modules, N=0 to max loaded modules)<verd disp="spam" rules=" , , "> <RCPT addr="[email protected]" /> </VERD> </MSG> An example of the totalprofiling element in the bmiconfig.xml file is as follows: <totalprofiling>true</totalprofiling>

79 Configuring Messaging Gateway for Service Providers About the Installation section 79 Table 5-1 Element productname Valid Installation section elements (continued) Description Hard-coded value. Do not change. Default: SMF (headless mode) productversion loadpoint Hard-coded value. Do not change. Directory that represents the base location that is assigned to Messaging Gateway for Service Providers software. You select the loadpoint during product installation. This location is stored in the $LOADPOINT variable. Linux and Solaris: /opt/symantec/smg-sp/scanner Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. Windows default: C:\Program Files\Symantec\smg-sp\Scanner logdir Directory where log files are placed. Log files contain both errors and general information on system activity. Linux and Solaris default: /var/log/brightmail Windows default: \Program Files\Symantec\smg-sp\Scanner\logs spooldir Directory in which spool information is located. Within this directory are directories for Harvester and Virus Cleaner messages. Linux and Solaris default: /var/spool/brightmail Windows default: \Program Files\Symantec\smg-sp\Scanner\BmiSpool statsdir Directory in which the Scanner deposits statistics files. You select the statistics directory during product installation. This location is stored in the $STATSDIR variable. Statistics are logged initially per message in an XML format. The Scanner writes this information to a statistics log file named bmi_eng_stats. Periodically, the file is renamed to engine_stats.xxx.xml, where xxx is a unique timestamp, which can be picked up by the Conduit. Linux and Solaris: /opt/symantec/smg-sp/scanner/stats Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. Windows default: \Program Files\Symantec\smg-sp\Scanner\Stats

80 Configuring Messaging Gateway for Service Providers About the Services section 80 Table 5-1 Element configdir Valid Installation section elements (continued) Description Directory that contains configuration files. This directory includes the bmiconfig.xml file as well as certificate files, and virus notifications. Linux and Solaris: /opt/symantec/smg-sp/scanner/etc Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. Windows default: \Program Files\Symantec\smg-sp\Scanner\Config reinsertionkey Key that is used to secure the reinsertion system. You must create your own reinsertion key. A reinsertion key can contain any number of characters and must be valid UTF-8 and valid XML. You should create a new insertion key rather than use the value that is shown in the example or the default value that is included in bmiconfig.xml. Use the same key across all Scanners. Example: <reinsertionkey>hva\*xgzis}nol#uu_{, </reinsertionkey> About the Services section The <services></services> section contains the following service type descriptions: Spam Antivirus service that filters messages according to antivirus modules and policies. See About the Spam Service Type on page 81. Virus Custom rules filtering service that filters messages according to customer-created Sieve rules and in conformance to modules and policies. See About the Virus Services Type on page 87. Custom Custom rules filtering service that filters messages according to customer-created Gatekeeper rules and in conformance to modules and policies. Consent Whitelist and blacklist service that filters messages according to Symantec-supplied and user-supplied whitelists and blacklists. See About the Consent Service Type on page 89.

81 Configuring Messaging Gateway for Service Providers About the Spam Service Type 81 Language Linguistic analyzer service that identifies the language of a message. See About the Language Service Type on page 100. Reinsert Required service that prevents the messages that the product generates (such as alerts and reports) from being scanned. It also prevents the messages that have already been filtered by the software from being filtered again and potentially causing a mail loop. See About the Reinsert Service Type on page 101. About the Spam Service Type By default, the Spam Service Type is named spam, is enabled, and has not expired. Default: <service xsi:type="spamservicetype" name="spam" enabled="true" expired="false"> Available Spam Service Type modules generally contain the following definitions: type name enabled critical Provides a specified type for the module. Provides a specific name for the module. Specifies whether the module is active. Valid values are true and false. Indicates whether the module is mission-critical. Valid values are true and false. If true, the module is considered mission-critical and when not in operation, messages are automatically rejected. If false, the messages that the module cannot process stay in the flow of . profiling url Indicates each module's message processing profiling. Web address used by modules to retrieve information by which they process messages. The Spam Service modules are as follows: libbh See libbh on page 82. libintsig See libintsig on page 82.

82 Configuring Messaging Gateway for Service Providers About the Spam Service Type 82 libstatsig See libstatsig on page 82. libspamsig See libspamsig on page 83. libregexfilter See libregexfilter on page 83. libspamhunter See libspamhunter on page 84. libbh After installation, libbh has a defined type, name, enable status, critical status, and URL definition as shown in the default values. Default: <module xsi:type="bodyhashmoduletype" name="libbh" enabled="true" critical="false"> <url rulename="hashes> </url> </module> libintsig This module is the 8-bit version of the intsigmoduletype module. Default: <module xsi:type="intsigmoduletype"name="libintsig" enabled="true" critical="false"> <url rulename="intsigs> intsigs</url> </module> libstatsig After installation, libstatsig has a defined type, name, enable status, critical status, and URL definition as shown in the default values. Default: <module xsi:type="statsigmoduletype" name="libstatsig" enabled="true" critical="false" profiling="false"> <url rulename="statsigs">

83 Configuring Messaging Gateway for Service Providers About the Spam Service Type 83 /statsigs</url> </module> libspamsig After installation, libspamsig has a defined type, name, enable status, critical status, and URL definition as shown in the default values. Default: <module xsi:type="spamsigmoduletype" name="libspamsig" enabled="true" critical="false"> <url rulename="spamsigs> /spamsigs</url> </module> libregexfilter This spam module manages header rules using regular expressions (regexmoduletype module). Default: <module xsi:type="regexmoduletype"name="libregexfilter" enabled="true" critical="false"> <url rulename="blrm"> blrm</url> <maxtotalheaderslength>32768</maxtotalheaderslength> <RHK enabled="true"/> </module> Table 5-2 describes the libregexfilter valid elements and their values

84 Configuring Messaging Gateway for Service Providers About the Spam Service Type 84 Table 5-2 Element maxtotalheaders Length Valid libregexfilter elements Description Maximum length, in bytes, of headers that libregexfilter examines. libregexfilter returns a spam disposition for any message with headers that exceed this limit. Each occurrence is logged at the NOTICE level. The default of 32 KB is the same as the built-in limit that Sendmail imposes. Sendmail and Postfix impose header length limits on incoming messages. Other MTAs have no limit restrictions on message header length. For installations using an MTA other than Sendmail or Postfix, maxtotalheaderslength prevents a large number of messages with exceedingly large headers from causing mail to back up. Default: <maxtotalheaderslength>32768</ maxtotalheaderslength> RHK Regex Hash Key acceleration is a technique for improving performance of the programs that need to evaluate a large number of regexes against the same text. Default: <RHK enabled="true" /> libspamhunter After installation, libspamhunter has values that are shown as follows. Default: <module xsi:type="spamhuntermoduletype" name="libspamhunter" enabled="true" critical="false" profiling="false"> <url rulename="spamhunter"> rules4/spamhunter</url> <grayfactor>80</grayfactor> <urlhashlimit>0</urlhashlimit> <imageevalrules enabled="false"/> <!-- null value here means accept all languages --> <acceptedlanguages> <language></language> </acceptedlanguages> <ruletypes/> <RHK enabled="true" /> <RBE enabled="true"/>

85 Configuring Messaging Gateway for Service Providers About the Spam Service Type 85 <scanattachments enabled="false"/> </module> Table 5-3 describes the libspamhunter valid elements and their values. Table 5-3 Element grayfactor Valid libspamhunter elements Description Specifies the lowest score that you want to be classified with a gray (suspected spam) verdict. A suspect spam message is a message that shows many characteristics of spam. However, Symantec is not 100% confident the message is, in fact, spam. When you enable suspect spam and set the threshold by which it is classified, you define how lenient you want to be on the messages that have these spam characteristics. Values for grayfactor range from 28 through 99 in the configuration file. To disable suspect spam verdicts entirely, set this value to 100. The lower the value, the broader is the potential scope for suspected spam messages. The grayfactor element represents the lowest score at which a message can be considered suspected spam. The default value for grayfactor is 80. Default: <grayfactor>80</grayfactor> urlhashlimit Sets a range of message sizes in bytes. If a message size falls within this range, urlhash rules are fired, which are fast regardless of message size. The default value of 0 allows for urlhash rules to be fired on all messages up to the maximum message size, which has a default value of 130 KB. To enable urlhash rules to fire on messages of larger sizes, set the value to an appropriately large number greater than 130 KB. To enable urlhash rule firing on all messages regardless of size, set this value to -1. Default: <urlhashlimit>0</urlhashlimit> acceptedlanguages This element is no longer used. Use language services instead. See About the Language Service Type on page 100.

86 Configuring Messaging Gateway for Service Providers About the Spam Service Type 86 Table 5-3 Element ruletypes Valid libspamhunter elements (continued) Description Lists each valid rule type. The following rule types are supported and enabled by default: urlhash url_regex header_regex body_regex lang_header_regex lang_body_regex bodysig iprange The iprange rule type checks if the connecting IP address or any IP address that is found in the RECEIVED: headers matches the range in the rule. The rule types that implement heuristics for this module are header_regex, body_regex, lang_header_regex, and lang_body_regex. Heuristics and the url_regex rule types use the most CPU resources. Performance improves if you disable them. However, disabling them can lead to a loss in filter effectiveness. To disable a rule type, remove its line from the configuration file. When no rule types are specified, all rule types are active. RHK Regex Hash Key acceleration is a technique for improving performance of the programs that need to evaluate a large number of regexes against the same text. Default: <RHK enabled="true" /> RBE Rule-based extraction (RBE) lets Symantec deliver new message extraction techniques to your mailwalls as they arise in the field. This element lets Symantec extract new, identifiable features from spam messages, whether they are URLs, telephone numbers, or similar transient information. Rule-based extraction lets data be incorporated into your antispam rules in minutes, rather than waiting for a patch or new product release. By default, RBE is enabled to maximize product effectiveness. If performance consistency is more of a concern than effectiveness, you can disable this feature in bmiconfig.xml. Default: <RBE enabled="true" />

87 Configuring Messaging Gateway for Service Providers About the Virus Services Type 87 About the Virus Services Type By default, the Virus Service Type is named virus, is enabled, and has not expired. Default: <service xsi:type="virusservicetype" name="virus" enabled="true" expired="false"> The Virus Service Type contains the libantivirus module, which generally contains characteristics such as name and type. libantivirus The default setting is as follows. Default: <module xsi:type="avmoduletype" name="libantivirus" enabled="true" critical="false" profiling="false"> Table 5-4 describes the libantivirus valid elements and their values. Table 5-4 Element heuristiclevel Valid libantivirus elements Description Heuristic level for the antivirus scanning engine, also known as Bloodhound. The heuristic level determines the way in which viruses are flagged. The heuristic level can be one of the following: 0 - No heuristics 1 - Lowest level 2 - Medium level 3 - Highest level Default: <heuristiclevel>2</heuristiclevel> This value must match the heuristic value for the AntiVirus Cleaner. See About the AntiVirus Cleaner program on page 116.

88 Configuring Messaging Gateway for Service Providers About the Virus Services Type 88 Table 5-4 Element reinsertionleeway Valid libantivirus elements (continued) Description Maximum allowed time, in seconds, between when the Cleaner begins to process a message and when that message is passed on to the MTA for delivery. If this time is exceeded, the message is scanned again. Default: <reinsertionleeway>600</reinsertionleeway> maxcontained FileBytes Maximum file size, in bytes, beyond which the system consults the policy for large file handling. The recommended value is 1 MB. This value is to be equal to or larger than the maximum file size that your environment expects for any message. Default: <maxcontainedfilebytes> </ maxcontainedfilebytes> worms A list of worms against which message attachments are checked. The enabled attribute modifies each worm definition with values of true or false. The default configuration defines the worms as follows: Yaha Bugbear Hybris Magistr Sobig Mimail Cult Dumaru maxarchivescan Depth Maximum number of containers through which message scanning occurs before the message is considered unscannable. Valid values are between 1 and 50. Default: <maxarchivescandepth>20</maxarchivescandepth>

89 Configuring Messaging Gateway for Service Providers About the Consent Service Type 89 Table 5-4 Element Symantec decomposer Valid libantivirus elements (continued) Description This element contains the definitions that are related to Symantec decomposer. The following settings are used in Symantec decomposer definitions: filesystemsize Specifies the limit on the size of the in-memory file system that the Symantec decomposer uses. If this limit is exceeded, files are written to disk and scanned there, rather than in memory. filesizethreshold Specifies the size of individual files within the in-memory file system that the Symantec decomposer uses. If this limit is exceeded, files are written to disk and scanned there, rather than in memory. symengine symengine specifies the engines that the Symantec decomposer uses. symoption For the specific engines that require them, specifies the option settings that the Symantec decomposer uses. The following options are selected by default: dec_option_enable_mime_engine Allows for the processing of MIME type message dec_option_enable_uue_engine Allows for the processing of UUEncoded message dec_option_enable_binhex_engine Allows for the processing of binhex encoded messages maxarchivescan Time This element is the value, in seconds, to spend processing containers through which message scanning occurs before the message is processed as unscannable. Valid values are any positive value in seconds. Default: <maxarchivescantime>60</maxarchivescantime> About the Consent Service Type By default, the Consent Service Type is named consent, is enabled, and has not expired. Default:

90 Configuring Messaging Gateway for Service Providers libfastpass 90 <service xsi:type="consentservicetype" name="consent" enabled="true" expired="false"> <url> </url> The Consent Service Type contains the following modules: libfastpass See libfastpass on page 90. libpermit See libpermit on page 96. Similar to the consent service type, these modules contain characteristics such as name and type. libfastpass Fastpass improves mailwall performance by skipping a subset of antispam filters for logical connection addresses with a demonstrated history of sending no spam messages. A "pass" is granted to a message source if that source has sent a specified number of consecutive, sampled legitimate messages (25 by default). Once a source has received a pass, the amount of antispam processing that is applied to messages from that source decreases. The number of messages that are permitted to bypass antispam filtering increases as more and more legitimate comes from the source. Fastpass reduces the processing time that is required for messages from legitimate sources. If a message source that has a pass subsequently sends a spam message that is sampled, the pass is immediately revoked. A full antispam analysis is performed on all messages from that source. The source remains eligible to receive another pass, however, by once again meeting all the criteria that is specified in the module configuration. You can configure the following options within the libfastpass module: The number of legitimate messages that are required to receive a pass The number of messages that can bypass once a pass is received The sliding scale that is used to increase the number of messages that can bypass The libfastpass module uses a memory-resident table to store and categorize the message source IP addresses are granted a pass and those that are currently being evaluated for a possible pass. Fastpass takes some time to build up its effectiveness after it is first enabled. However, it retains its data across restarts and the data it collects is persistent across restarts.

91 Configuring Messaging Gateway for Service Providers libfastpass 91 The Fastpass table is divided into two parts: trial table pass table Contains the entries that are being evaluated for inclusion in the pass table. A determination is made to move an IP address from the trial table to the pass table according to successful testing for legitimate messages for the IP address. Contains the entries that are granted a pass by the Fastpass module according to no spam coming from the IP address for a specified number of messages. By default, the Fastpass table can contain up to 250,000 IP address entries. 25% of the overall table size is reserved for the IP addresses that are granted a pass (up to 62,500 entries). The remaining 75% is reserved for trial table space. Default module settings are as follows: <module xsi:type="fastpassmoduletype" name="libfastpass" enabled="false" critical="false" profiling="false"> <tablesize>250000</tablesize> <entrysamplingrate>3</entrysamplingrate> <legitmessagesrequired>12</legitmessagesrequired> <initialsamplingrate>5</initialsamplingrate> <ignoregray enabled="false"/> <excluderanges/> <bouncestrings> <bouncestring>mailer-daemon</bouncestring> <bouncestring>postmaster</bouncestring> <bouncestring>autoreply</bouncestring> <bouncestring>auto-reply</bouncestring> </bouncestrings> <persistintervalseconds enabled="true">600</persistinvervalseconds <dropblock enabled="false" /> </module> Table 5-5 describes the Fastpass module valid elements and their values.

92 Configuring Messaging Gateway for Service Providers libfastpass 92 Table 5-5 Element tablesize Fastpass module elements Description Capacity of the Fastpass table, expressed as the number of IP addresses stored. Up to 25% of the specified table capacity can be used for the pass table. The trial table uses the remainder the trial table for those IP addresses that are selected for evaluation but are not yet granted a pass. Example: <tablesize>50000</tablesize> entrysamplingrate Specifies the likelihood that messages from an unknown IP address are selected for evaluation and entered into the trial table. A value of 1 is a reserved value. Only use this value at the direction of Symantec Technical Support. A value of 'n' will result in an IP address having a 1 in 'n' chance of being entered into the trial table each time a legitimate message from that IP address is received. For example, specifying an entry rate of 5 results in a 1 in 5 chance that an IP address is entered into the trial table. Example: <entrysamplingrate>3</entrysamplingrate> legitmessages Required Specifies the number of legitimate messages that must be sampled from an IP address before it is granted a pass. Note that due to the sampling rate attribute (entrysamplingrate), not every source that sends a legitimate message is immediately placed into the trial table. Example: <legitmessagesrequired>12</legitmessagesrequired>

93 Configuring Messaging Gateway for Service Providers libfastpass 93 Table 5-5 Element initialsamplingrate Fastpass module elements (continued) Description Specifies the initial, nominal sampling rate that is used to determine antispam processing on messages when a pass is first issued to an IP address. As the IP address continues to send legitimate messages, the sampling rate decreases from this nominal rate. For example, an attribute value of 8 results in nominally sampling 1 message out of 8 immediately after a pass is granted. As additional legitimate messages are received from an IP address, the nominal sampling rate is adjusted so that fewer messages are sampled. The nominal sampling rate cannot fall to less than 5 times the initial sampling rate. In other words, with an initial sampling rate of 8, the nominal sampling rate would gradually decrease towards 8 5 as additional legitimate messages are processed, until the nominal sampling rate is 1 message out of 40. Example: <initialsamplingrate>5</initialsamplingrate> ignoregray Determines how a message with a disposition of gray (suspected spam) is handled for an IP address that is granted a pass. If ignoregray is enabled, a sampled message with a disposition of suspected spam is treated as legitimate for the purposes of Fastpass. If ignoregray is disabled, a sampled message given a disposition of suspect spam causes a pass to be revoked. Example: <ignoregray enabled="true" />

94 Configuring Messaging Gateway for Service Providers libfastpass 94 Table 5-5 Element excluderanges Fastpass module elements (continued) Description Specifies a set of address ranges that are never entered into the Fastpass table. Messaging Gateway for Service Providers processing is always performed for addresses in any exclude range. Notation for exclude ranges is the same as the notation that is used for internal address ranges: individual IP address, address/mask, hostnames, or CIDR notation. Note: If you specify hostnames, an additional load is incurred. The system has to look up the hostname of the IP for every sampled message to ensure that it does not match a hostname that you have specified in the excluderanges. Example: <excluderanges> <excluderange> /24</excluderange> </excluderanges> bouncestrings Specifies a series of strings that can indicate a message is a bounce (an automatically-generated message). If any bounce string that is specified occurs (in unencoded form) within either the Subject or From header, then the message is treated as a bounce. It is excluded from Fastpass module processing. This comparison is case-insensitive. Regardless of the defined bounce strings, any message that contains an auto-submitted header is treated as a bounce. Example: <bouncestrings> <bouncestring>mailer-daemon</bouncestring> <bouncestring>postmaster</bouncestring> <bouncestring>autoreply</bouncestring> <bouncestring>auto-reply</bouncestring> </bouncestrings>

95 Configuring Messaging Gateway for Service Providers libfastpass 95 Table 5-5 Element persistinterval Seconds Fastpass module elements (continued) Description Specifies the persistence interval. By default, the persistintervalseconds value is enabled with a value of 600. To disable persistintervalseconds, change the "enabled" value in the configuration file to false. If the value that is specified in the configuration file is an integer, persistence occurs every time persistintervalseconds has passed since the previous persist dump or when the bmserver process is sent a shutdown signal. Consider the impact if you modify the persistintervalseconds value. For example, a low persistintervalseconds value can result in a data dump almost continuously. Conversely, a high value can essentially disable persistence until bmserver shuts down. Example: <persistintervalseconds enabled="true">600 </persistinvervalseconds> dropblock Causes Fastpass to drop all. Dropping the /24 range increases effectiveness against attacks where the sender can easily change IP addresses within the range (for example, snowshoe spam). This element is enabled by default on clean installations. It is disabled by default on upgrade. Change the enabled value to true to cause Fastpass to drop all entries from the table in the entire /24 block when a spam message is received from an address that has a pass. Enabling this setting increases effectiveness with minimal performance impact. For example: <dropblock enabled="true"/> Some Fastpass use scenarios Table 5-6 provides some scenarios that you might encounter if you enable Fastpass and suggested solutions.

96 Configuring Messaging Gateway for Service Providers libpermit 96 Table 5-6 Troubleshooting Fastpass Scenario or problem I can see that as our number of messages increases, we do not have sufficient server capacity to filter all of them. I have enabled Fastpass. But now I occasionally see some missed spam that is attributed to Fastpass. What should I do? I do not get as much effect from Fastpass as I had hoped. Suggestion or solution Enable Fastpass. It cuts down on the messages that you filter. When you configure Fast pass optimally, it does not appreciably increase spam for your users. Increase the legitmessagesrequired attribute. The higher you make this number, the harder it is for an IP address to get a pass. A pass is less likely to be granted to a site that sends a mixture of legitimate and spam messages. Perhaps your message stream has so much spam that few passes are granted. Or perhaps your traffic of legitimate messages comes from such a diverse set of addresses that it takes a long time for Fastpass to be effective. Check the messages in the log for table duration. The log gives the number of seconds of data that is retained in the tables. A value of 86,400 equals one day. Increasing the duration increases the effectiveness of Fastpass, assuming that the system runs long enough to take advantage of the increased duration. You can increase the duration when you increase the table size or decrease the entrysamplingrate. libpermit Consent services, whitelist module, and blacklist module (permitmoduletype). Default: <module xsi:type="permitmoduletype" name="libpermit" enabled="true" critical="false" profiling="false"> <url rulename="permit"> permit_rules </url> Table 5-7 describes the libpermit valid elements and their values.

97 Configuring Messaging Gateway for Service Providers libpermit 97 Table 5-7 Element rulefile Valid libpermit elements Description Specifies the directory location and file name for the Allowed Senders List and the Blocked Senders List. Linux and Solaris default: /opt/symantec/smg-sp/scanner/etc/allowedblockedlist.txt Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. Windows default: \Program Files\Symantec\smg-sp\Scanner\Config\allowedblockedlist.txt internalrange Specifies the default list of included internal mail host ranges. The modules ignore the addresses that are associated with the messages that are within an internal range. An address can be entered in plain IP, CDR, or netmask format. The default internal mail hosts ranges are as follows: <internalrange hidden="true"> / </internalrange> <internalrange hidden="true"> / </internalrange> <internalrange hidden="true"> / </internalrange> <internalrange hidden="true"> / </internalrange> <internalrange hidden="true"> / </internalrange> <internalrange hidden="true"> / </internalrange> See Specifying internal mail hosts on page 208. bbl enabled Specifies that you want the Scanner to scan against the allowed senders list or blocked senders list for permit rules. Default: <bbl enabled="true" /> rcvddnsbl Enables or disables a lookup of the IP addresses in the RECEIVED line headers of a message, using the third-party blacklist Services. A value of true enables DNS lookup. A value of false disables it. Default: <rcvddnsbl enabled="false" />

98 Configuring Messaging Gateway for Service Providers libpermit 98 Table 5-7 Element safelist Valid libpermit elements (continued) Description When true, the libpermit module checks the IP addresses against Symantec safe IP lists. IP addresses that match entries in the safe list bypass content scanning resulting in faster scanning for known good senders. Default: <safelist enabled="true" /> extendedwhite Check When true, the libpermit module checks addresses in addition to the logical connection address against the customer-defined Allowed Senders List. Generally, the logical connection address is the first address found when the header is scanned that is not an address that is included in an internalrange definition. When false, only the first address of header addresses not defined in an internalrange element is considered. If missing, the default value of false applies. Default: <extendedwhitecheck enabled="false"/> dbgshowscan If you enable this element, the product logs the IP addresses that are parsed from the message. In order for this debug setting to send information to the log file, the logging level for the bmserver program process must be set to the debug level. When you enable this option, it can affect performance even if the debug level is not set to this level. Use this attribute for advanced troubleshooting and leave it at false unless you are instructed to change it by Symantec Support. If you set it to true, it can have a negative impact on system performance. Default: <dbgshowscan enabled="false"/>

99 Configuring Messaging Gateway for Service Providers libpermit 99 Table 5-7 Element dbgdumprules Valid libpermit elements (continued) Description If you enable this element, the rules are dumped to the log. Rules from the downloaded rule set are considered restricted and are not dumped at customer sites. For this debug setting to send information to the log file, the logging level for the bmserver program process must be set to the debug level. When you enable this option, it can affect performance even if the debug level is not set to this level. Use this attribute for advanced troubleshooting and leave it at false unless you are instructed to change it by Symantec Support. If you set it to true, it can have a negative impact on system performance. Default: <dbgdumprules enabled="false"/> dbgtimeruleload Logs the amount of processing time that is used to load rules. In order for this debug setting to send information to the log file, the logging level for the bmserver program process must be set to the debug level. When you enable this option, it can affect performance even if the debug level is not set to this level. Use this attribute for advanced troubleshooting and leave it at false unless you are instructed to change it by Symantec Support. If you set it to true, it can have a negative impact on system performance. Default: <dbgtimeruleload enabled="false"/> dbgtimerulesearch If you enable this option after rule loading, it executes 1,000,000 random searches of the IP rules and logs the processing time that is used. For this debug setting to send information to the log file, the logging level for the bmserver program process must be set to the debug level. When you enable this option, it can affect performance even if the debug level is not set to this level. Use this attribute for advanced troubleshooting and leave it at false unless you are instructed to change it by Symantec Support. If you set it to true, it can have a negative impact on system performance. Default: <dbgtimerulesearch enabled="false"/>

100 Configuring Messaging Gateway for Service Providers About the Language Service Type 100 About the Language Service Type By default, the Language Service Type is named language, is disabled, and has not expired. Default: <service xsi:type="languageservicetype"name="language" enabled="false" expired="false"> The Language Service Type consists of the liblanguageid module. liblanguageid This module uses models to identify the language or languages in which a message is composed. Default: <module xsi:type="languagemoduletype" name="liblanguageid" enabled="true" critical="false" profiling="false"> Similar to the consent service type, the related modules contain characteristics such as name and type. In addition to these standard values, other definitions may also apply. Table 5-8 describes the liblanguageid valid elements and their values. Table 5-8 Element maxlanguages Valid liblanguageid elements Description Maximum number of the languages that are returned on analysis. Default: <maxlanguages>3</maxlanguages> maxmessagesize Specifies the maximum size, in bytes, that a message can be to be processed. Default: <maxmessagesize>100000</maxmessagesize>

101 Configuring Messaging Gateway for Service Providers About the Reinsert Service Type 101 Table 5-8 Element samplesize Valid liblanguageid elements (continued) Description Number of bytes that are examined from the message to determine its language. The sample is selected randomly from each message. Using more than 512 bytes does not provide measurably more accurate results in language identification for this module. Default: <samplesize>512</samplesize> About the Reinsert Service Type By default, the Reinsert Service Type is named "Reinsert" and is enabled. Default: <service xsi:type="reinsertservicetype" name="reinsert" enabled="true"> The Reinsert Service Type consists of the libreinsert module. libreinsert The message reinsertion module reinserts processed messages into the MTA queue. Default: <module xsi:type="reinsertmoduletype" name="libreinsert" enabled="true" critical="false" profiling="false"> Table 5-9 describes the libreinsert valid elements and their values. Table 5-9 Element timeout Valid libreinsert elements Description Maximum allowed time, in seconds, between when a message is first reinserted and when that message is passed on to the MTA for delivery. If the specified time is exceeded, the message is scanned again. Default: <timeout>600</timeout>

102 Configuring Messaging Gateway for Service Providers About the Programs section 102 Table 5-9 Element recipients Valid libreinsert elements (continued) Description Lists the addresses that are trusted recipients for message insertion. Messages for these recipients are not scanned. Default: <recipients> *.brightmail.com</trustedrecipient> </recipients> This address can include? as a wildcard for any single character or * as a wildcard for zero or more characters. x-header X-header that must be included in the message header in order for reinsertion to occur. Default: <xheader>x-bltreinsert</xheader> About the Programs section The <programs> </programs> section of the bmiconfig.xml file contains settings for the following programs: Filter See About the Filter program on page 103. Client See About the Client program on page 104. Server See About the Server program on page 106. Conduit See About the Conduit program on page 107. LiveUpdate See About the LiveUpdate program on page 111. Antivirus Cleaner See About the AntiVirus Cleaner program on page 116.

103 Configuring Messaging Gateway for Service Providers About the Filter program 103 About the Filter program For Sendmail-based installations, the Filter enables communications between Messaging Gateway for Service Providers and Sendmail. In the configuration file, the address for communication is provided through the sendmailconnection element. The Filter is only used in the implementations that use the Sendmail MTA. Default: <program xsi:type="bmifiltertype" name="bmifilter"> <sendmailconnection> inet:41001 </sendmailconnection> </program> Attribute settings let you override the return values from the bmifilter to Sendmail. When bmifilter encounters what it considers an error state, it sends by default an accept (SMFIS_ACCEPT) value back to Sendmail. By default, when it encounters what it considers to be a warning state, it sends an ignore (SMFIS_CONTINUE) value back to Sendmail. Table 5-10 describes the bmifilter valid elements and their values. Table 5-10 Element errorhandling Valid bmifilter elements Description Error handling is confined to memory allocation difficulties. This handler sends a message from Messaging Gateway for Service Providers to Sendmail through the bmifilter. The following messages are possible: ignore Continue processing the message for any other available milters. In other words, Messaging Gateway for Service Providers is done with any processing for this message. accept Accepts the message for this state. reject Rejects the message for this state.

104 Configuring Messaging Gateway for Service Providers About the Client program 104 Table 5-10 Element warninghandling Valid bmifilter elements (continued) Description Warnings are confined to configuration problems and queue problems or when the product initialization produces a warning. This handler sends a message to Sendmail through the bmifilter. Set this attribute to ignore in all circumstances. The following messages are possible: ignore Continue processing the message for any other available milters. In other words, Messaging Gateway for Service Providers is done with any processing for this message. accept Accepts the message for this state. reject Rejects the message for this state. About the Client program The Client monitors the MTA and shuttles messages for processing by the Server. The Client program is defined as follows: Default: <program xsi:type="bmclienttype" name="bmclient"> Table 5-11 describes the Client program valid elements and their values. Table 5-11 Element servers Valid Client program elements Description Specifies the name and the port that is assigned to the server host for the Client. Default: <server host="$server$" port="41000"> </server>

105 Configuring Messaging Gateway for Service Providers About the Client program 105 Table 5-11 Element log Valid Client program elements (continued) Description Specifies the log level, log retention characteristics, and log file location information. See About managing statistics for stand-alone Scanners on page 132. Default for Linux and Solaris: <log level="4" period ="1" periodunits="day" numberretained="30"> /var/log/brightmail/ bmclient_log</log> Default for Windows: <log level="4" period ="1" periodunits="day" numberretained="30">c:\program Files\ Symantec\smg-sp\Scanner\Logs\bmclient_log.txt</log> connection Defines the connection characteristics for the Client. Valid elements are as follows: timeoutsec Number of seconds the Client waits for a response from a Server before it breaks the connection. maxperserver The maximum number of connections with each Server that is maintained in an open state during message processing. This option also sets the maximum number of connections possible with each Server. numberpersistent The maximum number of persistent connections with each Server that is maintained in an open state during message processing. This number must be less than or equal to maxperserver. Default: <connection timeoutsec="0" maxperserver="1000" numberpersistent="512"/>

106 Configuring Messaging Gateway for Service Providers About the Server program 106 Table 5-11 Element transaction Valid Client program elements (continued) Description Defines the connection characteristics for the Client. Valid elements are as follows: timeoutsec Number of seconds the Client waits for a response from a Server before it breaks the connection. bufferflushsize Number of bytes to buffer for body and header processing. Default: <transaction timeoutsec="0" bufferflushsize="65536" /> delay CommunicationInit Enables (true) a delay in the initial communications to the Server or disables (false) an initial delay in communications connection to the Server. Symantec recommends that you enable this option only for single-threaded client integrations. Default: <delaycommunicationinit>false </delaycommunicationinit> About the Server program The Server processes the messages that are sent to it by the Client. It returns one or more verdicts to the Client for each message that it processes. The Server program is defined as follows: Default: <program xsi:type="bmservertype" name="bmserver"> Table 5-12 describes the Server program valid elements and their values.

107 Configuring Messaging Gateway for Service Providers About the Conduit program 107 Table 5-12 Element log Valid Server program elements Description Specifies the log level, log retention characteristics, and log file location information. See About managing statistics for stand-alone Scanners on page 132. Default for Linux and Solaris: <log level="4" period ="1" periodunits="day" numberretained="30"> /var/log/brightmail/ bmserver_log</log> Default for Windows: <log level="4" period ="1" periodunits="day" numberretained="30">c:\program Files\ Symantec\SBAS\Scanner\Logs\bmserver_log.txt</log> networkaddress Address of the Server. Multiple addresses are not supported. The asterisk (*) indicates any available computer on the indicated port (all local Ethernet addresses). Default: <networkaddress host="*" port="41000"> </networkaddress> The pidfile attribute has been removed. maxqueuesize The bmserver keeps an internal queue of transactions with clients. You can expand or contract this value to adjust for performance limits on your host. If the queue is full, the bmserver rejects connections. A larger queue size can adversely affect RAM availability. It can also increase the need to swap memory. Default: <maxqueuesize>2048</maxqueuesize> About the Conduit program The Conduit performs the following functions: Manages the communications setup between Symantec and your site during installation and initial setup Obtains the rule updates from Symantec Security Response

108 Configuring Messaging Gateway for Service Providers About the Conduit program 108 Validates the new rules Delivers the rule updates to the modules Consolidates the statistics information and uploads it to Symantec Security Response Default: <program xsi:type="conduittype" name="conduit"> Table 5-13 describes the Conduit program valid elements and their values. Table 5-13 Element log Valid Conduit program elements Description Specifies the log level, log retention characteristics, and log file location information. See About managing statistics for stand-alone Scanners on page 132. Default for Linux and Solaris: <log level="4" period ="1" periodunits="day" numberretained="30"> /var/log/brightmail/ conduit_log</log> Default for Windows: <log level="4" period ="1" periodunits="day" numberretained="30">c:\program Files\ Symantec\smg-sp\Scanner\Logs\conduit_log.txt</log> kickcommand Command that re-initializes the Server. Linux and Solaris default: <kickcommand>/opt/symantec/smg-sp/scanner/bin/ kicker /opt/symantec/smg-sp/scanner/etc/ bmiconfig.xml /opt/symantec/smg-sp/scanner/jobs/ bmserver/bmserver.pid</kickcommand> Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. Windows default: <kickcommand>c:\progra~1\symantec\sbas\scanner\ bin\kicker.exe -s BMISERVERSVC</kickCommand>

109 Configuring Messaging Gateway for Service Providers About the Conduit program 109 Table 5-13 Element interval Valid Conduit program elements (continued) Description Time value, in seconds, to wait between queries for new rules. Default: <interval>60</interval> overriderule UpdateTTLSeconds Note: Do not change this value without consulting Symantec Support. Overrides frequency of ruleset updates to the BLOC, which are normally set dynamically by the BLOC. For instance, to force a 1 minute check interval, set to 60. Changes are not recommended unless directed by Support. Default: <overrideruleupdatettlseconds min="0" max="300" /> minkickinterval Seconds Sets a minimum rate of "kicks" of the engine (for example, module ruleset reload) so that the rate can be reduced if a performance problem occurs. Changes are not recommended unless directed by Support. Default: <minkickintervalseconds>1</minkickintervalseconds> blocstatsinterval Number of interval increments to wait before the Conduit sends statistics to Symantec Security Response. For example, if the value of interval is 60 (seconds), and the value of blockstatsinterval is 10, the Conduit sends statistics every 10 minutes. Default: <blocstatsinterval>10</blocstatsinterval> Note: Do not change this value without consulting Symantec Support. statscleanthreshold Sets the number of days that mc_stats files are retained on the computers that process messages. Default: <statscleanthreshold>3</statscleanthreshold>

110 Configuring Messaging Gateway for Service Providers About the Conduit program 110 Table 5-13 Element httptimeout Valid Conduit program elements (continued) Description Sets a timeout value, in seconds, for the HTTP communication between the Conduit and Symantec Security Response. Default: <httptimeout>3600</httptimeout> statsurl URL at which stats files are available for retrieval by Symantec Security Response. Default: <statsurl> statsurl> Note: Do not change this element. The software does not function properly with a value other than the default. registrationurl URL to which the installer connects to establish the secure keys that are based on your customer license. Default: <registrationurl> register</registrationurl> Note: Do not change this element. The software does not function properly with a value other than the default. testurl URL for testing the exchange of Client and Server keys that are used to establish secure HTTPS communication. Default: <testurl> blrm</testurl> Note: Do not change this element. The software does not function properly with a value other than the default.

111 Configuring Messaging Gateway for Service Providers About the LiveUpdate program 111 Table 5-13 Element proxy Valid Conduit program elements (continued) Description Specifies whether proxy service is required for receiving rules through secure HTTPS. Valid values are true and false. The default value is false. Default: <proxy enabled="false"> <server host="none" port="false"/> </proxy> If this option is enabled=true, you must at least supply a server host. You can also supply the port. The port attribute must be a TCP/IP address. There is no default port. Use the following for a proxy user name and password, if needed. Example: <password>mysecurepassword</password> <username>myidentity</username> About the LiveUpdate program Messaging Gateway for Service Providers relies on up-to-date information to detect viruses and threats. One of the most common reasons that problems occur is that virus definition files are not up-to-date. Symantec regularly supplies the updated virus definition files that contain the necessary information about all newly discovered viruses and threats. Regular updates of that information maximize security and guard your organization against infections and the downtime that is associated with an outbreak. LiveUpdate performs the following functions: Obtains the antivirus rule updates from Symantec Definition Server Validates the new rules Delivers the rule updates to the antivirus module Default: <program xsi:type="jlucontrollertype" name="jlu-controller"> See About LiveUpdate rule updates on page 135. Table 5-14 describes the LiveUpdate program valid elements and their values.

112 Configuring Messaging Gateway for Service Providers About the LiveUpdate program 112 Table 5-14 Element log Valid LiveUpdate program elements Description Specifies the log level, log retention characteristics, and jlu-controller log file location information. Default for Linux and Solaris: <log level="4" period ="1" periodunits="day" numberretained="30"> /var/log/brightmail/ jlu_controller_log</log> Default for Windows: <log level="4" period ="1" periodunits="day" numberretained="30">c:\program Files\ Symantec\smg-sp\Scanner\Logs\jlu_controller_log.txt</log> kickcommand Specifies the command that re-initializes the Server. Default for Linux and Solaris: <kickcommand>/opt/symantec/smg-sp/scanner/bin/ kicker /opt/symantec/smg-sp/scanner/etc/ bmiconfig.xml /opt/symantec/smg-sp/scanner/jobs/ bmserver/bmserver.pid</kickcommand> Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. Default for Windows: <kickcommand>c:\progra~1\symantec\smg-sp\scanner\ bin\kicker.exe -s BMISERVERSVC</kickCommand> jluclientlog Specifies the file that contains jlu-client log. Jlu-controller component uses jlu-client to download platinum antivirus definitions. Default for Linux and Solaris: <jluclientlog> > /var/log/brightmail/ liveupdt.log</jluclientlog> Default for Windows: <jluclientlog>c:\program Files\Symantec\ smg-sp\scanner\logs\liveupdt.log</jluclientlog>

113 Configuring Messaging Gateway for Service Providers About the LiveUpdate program 113 Table 5-14 Element javahome Valid LiveUpdate program elements (continued) Description Specifies the location of Java Runtime Environment. Default for Linux and Solaris: <javahome>/opt/symantec/smg-sp/scanner/jre</javahome> Default for Windows: If you are a Windows user, you need to install Java Runtime Environment 1.5 or later. If you already have installed JRE on your computer, Messaging Gateway for Service Providers detects it and saves the javahome location. See System requirements on page 40. jlutempdir Specifies the temporary directory for LiveUpdate where it initially downloads platinum antivirus definitions. Default for Linux and Solaris: <jlutempdir>/tmp</jlutempdir> Default for Windows: <jlutempdir>c:\program Files\Symantec\ smg-sp\scanner</jlutempdir> mode Specifies the type of antivirus definitions, where 1 is Platinum definitions and 2 is Rapid Release definitions. Default for Linux, Solaris, and Windows: <mode>2</mode>

114 Configuring Messaging Gateway for Service Providers About the LiveUpdate program 114 Table 5-14 Element platinumdefshost Valid LiveUpdate program elements (continued) Description Specifies from where to obtain platinum virus definitions. Platinum virus definitions can be obtained from the Symantec LiveUpdate server or from the LAN host. To obtain virus definitions from the LAN host you need to specify the address, port, user name, password, and proxy host information. For example, <customserver enabled="true"> <address> <username>pqr</username> <password plain="true">1234</password> <proxy enabled="true"> <server host=" " port="12"/> <username>xyz</username> <password plain="true">abc</password> </proxy> </customserver> Default for Linux, Solaris, and Windows: <platinumdefshost defaulturl= " <customserver enabled="false"> </customserver> </platinumdefshost> See Obtaining the virus definition updates on page 204.

115 Configuring Messaging Gateway for Service Providers About the LiveUpdate program 115 Table 5-14 Element avdefsplatinum Product Valid LiveUpdate program elements (continued) Description Specifies the product name, version, type of definition, and language attributes of the platinum definitions. Default for Linux, Solaris, and Windows: <avdefsplatinumproduct> <name platformcontrol="win64">smf Virus Definitions Windows 64-bit</name> <name platformcontrol="win32">smf Virus Definitions Windows 32-bit</name> <name platformcontrol="linux">smf Virus Definitions RHEL 32-bit</name> <name platformcontrol="solaris">smf Virus Definitions Sparc-Solaris 32-bit</name> <version>1.0</version> <type>virusdef</type> <language>symalllanguages</language> </avdefsplatinumproduct> rapidreleaseurls Specifies the Rapid Release definitions URLs and sequence number URLs for Rapid Release definitions downloads. Default for Linux, Solaris, and Windows: <rapidreleaseurls> <sequrl> /defs/rapidrelease/version-info.txt</sequrl> <defsurl platformcontrol="win32">http: //definitions.symantec.com/defs/rapidrelease/ ennlu.x86</defsurl> <defsurl platformcontrol="win64">http: //definitions.symantec.com/defs/rapidrelease/ symrapidreleasedefsi64.exe</defsurl> <defsurl platformcontrol="linux">http: //definitions.symantec.com/defs/rapidrelease/ ennlu.lin</defsurl> <defsurl platformcontrol="solaris">http: //definitions.symantec.com/defs/rapidrelease/ ennlu.sol</defsurl> </rapidreleaseurls>

116 Configuring Messaging Gateway for Service Providers About the AntiVirus Cleaner program 116 About the AntiVirus Cleaner program The AntiVirus Cleaner first processes messages for cleaning and then transfers potentially infected messages from a spool to an SMTP server for delivery. Multiple destinations can be accommodated. Default: <program xsi:type="cleanertype" name="cleaner"> Table 5-15 describes the AntiVirus Cleaner program valid elements and their values. Table 5-15 Element log Valid AntiVirus Cleaner program elements Description Specifies the log level, log retention characteristics, and log file location information. See About managing statistics for stand-alone Scanners on page 132. Default for Linux and Solaris: <log level="4" period ="1" periodunits="day" numberretained="30"> /var/log/brightmail/ cleaner_log</log> Default for Windows: <log level="4" period ="1" periodunits="day" numberretained="30">c:\program Files\ Symantec\smg-sp\Scanner\Logs\cleaner_log.txt</log>

117 Configuring Messaging Gateway for Service Providers About the AntiVirus Cleaner program 117 Table 5-15 Element smtpclient Valid AntiVirus Cleaner program elements (continued) Description The AntiVirus Cleaner has a definition for the SMTP Client that contains a timeout setting and the address for the SMTP Server. Default: <smtpclient> <timeout>480000</timeout> <servers> <server host=" " port="25"/> </servers> </smtpclient> Valid elements are as follows: timeout Number of miliseconds the Cleaner waits before it ends an idle connection to the SMTP Server. Default: <timeout>480000</timeout> servers IP address and port of the SMTP server to which the Cleaner sends the messages that are cleaned. The default port is 25. Alternatively, you can enter a hostname or an IP address. The Cleaner cannot perform an MX lookup. You can enter multiple addresses for redundancy when separated by a comma and a space. The Cleaner uses the first address that works. The Cleaner does not perform automatic load balancing. Default: <servers> <server host=" " port="25"/> </servers>

118 Configuring Messaging Gateway for Service Providers About the AntiVirus Cleaner program 118 Table 5-15 Element avnoticefile Valid AntiVirus Cleaner program elements (continued) Description The path to the XML file that contains all of the notifications that the Cleaner uses to notify the recipient or sender of a cleaned message. Linux and Solaris default: <avnoticefile>/opt/symantec/smg-sp/scanner/etc/ Notification.xml</avNoticeFile> Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp /Scanner with /$loadpoint. Windows default: <avnoticefile>c:\program Files\ Symantec\smg-sp\Scanner\etc\Notification.xml</avNoticeFile> maxsender Notifications The maximum number of notifications that the Cleaner sends to senders of viruses per queue run. For example, if this value is set to 20, and 50 messages are in the AntiVirus Spool when the Cleaner begins a queue run (processing run) on the AntiVirus Spool, it sends a notification to the senders of the first 20 messages that it attempts to clean. It does not send a notification to the senders of the other 30 messages. This process repeats for each queue run. You can use this setting to prevent Symantec Message Filter from clogging the network with messages in the case of a virus attack. The default value of 0 disables sender notification. To enable sender notification, this element can be set to 1 or more. Default: <maxsendernotifications>0 </maxsendernotifications> numberthreads The number of threads with which the Cleaner runs. Default: <numberthreads>5</numberthreads>

119 Configuring Messaging Gateway for Service Providers About the AntiVirus Cleaner program 119 Table 5-15 Element spool Valid AntiVirus Cleaner program elements (continued) Description Location of the antivirus spool where the Server deposits infected mail for the Cleaner. Default: <spool width="8" depth="0">$spooldir$$/$virus </spool> heuristiclevel Heuristic level for the antivirus scanning engine. The heuristic level determines the way in which viruses are flagged and can be one of the following: 0 - No heuristics 1 - Lowest level 2 - Medium level 3 - Highest level This value must match the heuristic value for the AntiVirus Module. See "libantivirus module". Default: <heuristiclevel>2</heuristiclevel> maxcontainedfile Bytes Maximum file size, in bytes, beyond which the program consults the <deletebigfiles> setting. Set this value to be equal to or larger than the maximum file size that your environment expects for any message. In most situations the value that you set for the maxcontainedfilebytes element in the module definition in the AntiVirus Service Type process should be less than or equal to the value given here. Default: <maxcontainedfilebytes> </ maxcontainedfilebytes>

120 Configuring Messaging Gateway for Service Providers About the AntiVirus Cleaner program 120 Table 5-15 Element deletebigfiles Valid AntiVirus Cleaner program elements (continued) Description The action that is taken when the size of an attachment, in bytes, exceeds the value of the <maxcontainedfilebytes> definition. The values for this element are as follows: False The file is skipped without further processing. This setting lets viruses pass through to a recipient's inbox. True The file is deleted from the message. Default: <deletebigfiles value="false"/> defaultusername The address specified in this element is used in the "From" line when a message is sent back to the sender of a virus. You must change the default value if you enable sender notification. See "maxsendernotifications". Default: <defaultusername>[email protected] </defaultusername> notificationsubject String to be included in the subject line when a message is sent to the sender of a virus. The contents of the Notification.xml file determines the text. Default: <notificationsubject>you have a virus! </notificationsubject> maxscantime The maximum amount of time the AV scanner can attempt to scan a message before it stops. Default: <maxscantime>600</maxscantime>

121 Configuring Messaging Gateway for Service Providers About the Engine section 121 About the Engine section The Engine (bmengine) section of the configuration file controls several key aspects of filtering. Table 5-16 lists the bmengine valid elements and their values. Table 5-16 Element mailflow defaultdestination Valid bmengine elements Description In Symantec Message Filter, the precedence element determined the sequence of scanning to be followed when a message is received. In Symantec Messaging Gateway for Service Providers, the mailflow element determines this. Specifies the destination where the Server delivers a message if it does not match any other dispositions. The value of this element should always match the destination value for the default policy. Default: <defaultdestination>inbox</defaultdestination> statsthreshold Specifies the sampling probability for each filtered message. The element value can be any number between 0 and 1 inclusive, with up to 5 significant digits. In practice, this number represents the percentage chance that any given message will have statistics reported for it. For example: A value of 0 means that no statistics are reported. A value of 1 means that a statistic for every message is reported. A value 0.5 means that every message has a 50% chance of being reported. This element only affects what is sent to Symantec Security Response by the Conduit. Note: Do not change this setting without specific instruction from Symantec Support. Default: <statsthreshold>1.0</statsthreshold>

122 Configuring Messaging Gateway for Service Providers About the Engine section 122 Table 5-16 Element spamthreshold Valid bmengine elements (continued) Description Value at and beyond which a message is classified as spam. By default, messages with a combined score of 90 or higher are classified as spam. Default: <spamthreshold>90</spamthreshold> Note: Do not change this setting. Doing so can cause your software to cease functioning properly, and can lead to an increase in false positives. clientoptin Specifies how users can be opted into Symantec services. When true, the integration is expected to handle all of the matters that are related to opt-in status. When false, the product handles all of the matters that are related to opt-in status. False is the only valid selection. Default: <clientoptin enabled="false" /> earlyverdictsip Lets the Scanner determine an early verdict on the IP address before the entire message is received. For more information about early verdicts, see the Messaging Gateway for Service Providers Software Development Kit Development Guide. The earlyverdictsip is disabled by default. To enable connection time verdicts, you must set its value to enabled='true'. Default: <earlyveridctsip enabled="false" /> bmicheck Reputation bmicheckreputation is a convenience API that gives the reputation of the IP address that is passed to it. See About bmicheckreputation on page 123. tracker Lets Symantec Support diagnose the false positives and false negative messages. Default: <tracker legacy="false" compressed="default" hash="sha1" signed="true" />

123 Configuring Messaging Gateway for Service Providers About bmicheckreputation 123 About bmicheckreputation bmicheckreputation is a convenience API that gives the reputation of the IP address that is passed to it. BMI_API BmiError bmicheckreputation(bmisystem *system, where: const char *ip_dotted_quad, BmiVerdict **verdict) BmiSystem *system - ptr to BMI System context const char *ip_dotted_quad - IP for which the reputation is needed const BmiVerdict **verdict - verdict to be returned Internally, bmicheckreputation maps to the following sequence of API calls: bmiinitmessage bmiprocessconnection bmifreemessage If the early verdict feature is enabled and if the IP address that is passed is blacklisted, a verdict is returned. If the early verdict feature is enabled and if the IP address that is passed is not blacklisted, the verdict pointer is NULL. If the early verdict feature is disabled, the verdict pointer is NULL irrespective of the reputation of the passed IP address. The message is handled according to the destination in the verdict. The BmiVerdict structure that is allocated here needs to be freed by the calling function. /* * Sample usage of the convenience API bmicheckreputation * Free the verdict once after using it. */ BmiVerdict *verdict_temp = NULL; //used with bmicheckreputation. Not a //const so that it can be freed using //bmifreeverdict if(strlen(ip_addr) > 0) { err = bmicheckreputation(csink::sm_bmisystem, IP_Addr, &verdict_temp);

124 Configuring Messaging Gateway for Service Providers About the Policies section 124 if (verdict_temp!= NULL) { bmi_debug2("the verdict destination is %s", bmiverdictaccessdestination(verdict_temp)); // Handle the message next according to the destination // in the verdict } else { bmi_debug1("the verdict is null"); // Do nothing } if (verdict_temp!= NULL) { bmifreeverdict(verdict_temp); } goto err_exit; About the Policies section Each policy in the policies section defines a policy by the following criteria: Defining a set of users (a population) Defining the dispositions to be used for a population Table 5-17 lists the Policies section valid elements and their values. Table 5-17 Element population Valid Policies section elements Description Defines the groups of users for a policy. The total population for a policy is limited to 10,000 member elements. No limit on the actual number of users that are represented by the member elements exists. A valid address pattern must be either an address or a domain name. Default: <population> <member xsi:type="addresspattern">*</member> </population>

125 Configuring Messaging Gateway for Service Providers About the Policies section 125 Table 5-17 Element disposition destination Valid Policies section elements (continued) Description A disposition is a result returned by a module, represented by a string. For example, spam, virus, and worm are dispositions. In other documentation, dispositions are called verdicts. String that is returned for a given verdict that contains the disposition. There must be one destination element within the disposition unless the disposition has a referral attribute. The destination string is treated according to the following rules: If the string is not specified, this option instructs Messaging Gateway for Service Providers to remove all the recipients from the verdict that contains this empty destination. If the string matches the string that is defined in the value of default destination. Messaging Gateway for Service Providers delivers the message normally for all the recipients from the verdict that contains this string. If the string is anything else, Messaging Gateway for Service Providers modifies the message headers for all the recipients from the verdict that contains this string. This modification instruction is a semicolon-delimited list of modifications, each of which can have any of the following formats: Xheader: value Adds a header that is called Xheader with the specified value. Subject: value Replaces the Subject line with value. Subject: value%s Prepends the value to the beginning of the Subject line. Subject: %x value Appends the value to the end of the Subject line. Note: These behaviors relate primarily to Sendmail and Windows IIS-based installations. Behaviors can be different for other MTAs.

126 Configuring Messaging Gateway for Service Providers About the Policies section 126 Table 5-17 Element action Valid Policies section elements (continued) Description Describes the server/engine action to be performed on a given verdict that contains the disposition. This element is an optional element that has no string value. A sample action appears as follows: <action name="modify" type="bmispool"> <path>$spooldir$$/$spam</path> <modify> <headers> <replace>x-whitelist: TRUE</replace> </headers> </modify> <server host=" " port="25"/> </action> The <action> element has the following attributes: type Required attribute for which the only valid value is bmispool. This attribute saves the message to disk. name Server action name, required. The name that is used to assist in configuration and can be any of the following: path Clean Folder SaveToDisk notifyunscannable Modify Single path element, required. The value of the path element is the location on disk where the message and its accompanying.recipients file are saved. modify Optional element that can only contain a <headers> element. headers Optional element subordinate to the <modify> element. A headers element can contain any number of add, replace, or transform elements. The add and replace elements take an attribute: value pair as their value.

127 Configuring Messaging Gateway for Service Providers Adding a new disposition through the command line 127 Table 5-17 Element action (continued) Valid Policies section elements (continued) Description The following examples show some of the uses of headers: <add> Subject: new_subject </add> Adds a subject line of new_subject. More than one subject line can be added. The one shown depends on the MTA. <replace> Subject: new_subject </replace>-replaces the old subject with a new subject, new_subject. <transform> Subject: [spam] %s </transform> Prepends the subject line, %s, with [spam]. Note: You can create the policies that result in the different actions that are performed on the same message, if different policies apply to different recipients. However, be careful when you create multiple policies that use different message header modifications. Modifying the headers of the same message in different ways for different recipients can lead to performance issues. See Adding a new disposition through the command line on page 127. See Updating an existing disposition on page 128. See Changing the destination string of an existing disposition on page 129. See Changing the order of message scanning on page 130. Adding a new disposition through the command line You can use Messaging Gateway for Service Providers to add a new disposition through the command line. To add a new disposition through the command line 1 On the command line, type the following command: policyconfig -i path/bmiconfig.xml -s <path>/bmiconfig.xsd For example: On UNIX systems, sbin/policyconfig -i etc/bmiconfig.xml -s etc/bmiconfig.xsd On Windows systems, policyconfig -i config/bmiconfig.xml -s etc/bmiconfig.xsd 2 Type 1 to select Add new disposition.

128 Configuring Messaging Gateway for Service Providers Updating an existing disposition Select the source to update: Type 1 to select an external source. Type 2 to select the firewall as a source. 4 Type the name for the new disposition. 5 Select one of the following disposition types. 6 Select one of the destination. Inbox (Deliver message normally) Delete (Delete message) Custom destination (Custom text/append or Prepend subject) Save to Disk 7 Type the name of the filtering policy. 8 Type the description of the filtering policy. 9 Select precedence. Precedence refers to the order of message scanning. 10 When the message Do you want to go back appears, select No by typing When the message Do you want to save the changes appears, select Yes by typing 1. See policyconfig on page 217. See About the Policies section on page 124. Updating an existing disposition You can use Messaging Gateway for Service Providers to update an existing disposition through the command line.

129 Configuring Messaging Gateway for Service Providers Changing the destination string of an existing disposition 129 To update an existing disposition 1 On the command line, type the following command: policyconfig -i <path>/bmiconfig.xml -s <path>/bmiconfig.xsd For example: On UNIX systems, sbin/policyconfig -i etc/bmiconfig.xml -s etc/bmiconfig.xsd On Windows system, policyconfig -i config/bmiconfig.xml -s etc/bmiconfig.xsd 2 Type 2 to select Update existing disposition. 3 Select the source to update: Type 1 to select an external source. Type 2 to select the firewall as a source. 4 Select the disposition update type: Type 1 to change destination. See Changing the destination string of an existing disposition on page 129. Type 2 to change linear precedence. See Changing the order of message scanning on page 130. See policyconfig on page 217. See About the Policies section on page 124. Changing the destination string of an existing disposition You can change the destination of a message when you update a disposition by using the Messaging Gateway for Service Providers command line. To change the destination string of an existing disposition 1 Run the policyconfig command to update the new disposition. See Updating an existing disposition on page Select the disposition update type: Type 1 to select change destination.

130 Configuring Messaging Gateway for Service Providers Changing the order of message scanning Select the disposition to update by typing the appropriate number. For example: Type 2 to select the dns_allow disposition. 4 Select one of the new destination. 5 When the message Do you want to go back appears, select No by typing 2. 6 When the message Do you want to save the changes appears, select Yes by typing 1. See policyconfig on page 217. See About the Policies section on page 124. Changing the order of message scanning You can change the precedence (the order in which a message is scanned) when you update a disposition by using the Messaging Gateway for Service Providers command line. To change the order of message scanning 1 Execute the policyconfig command to update the new disposition. See Updating an existing disposition on page Select the disposition update type. Type 2 to change linear precedence. 3 Type the number of the disposition for which you want to change the precedence. For example: Type 10 to select virus. Note: The number may be different if you have already changed the precedence. 4 Enter the new precedence number. For example: If you want the message to be first scanned for viruses, type 1. 5 When the message Do you want to go back appears, select No by typing 2. 6 When the message Do you want to save the changes appears, select Yes by typing 1.

131 Configuring Messaging Gateway for Service Providers Managing logs for stand-alone Scanners 131 See policyconfig on page 217. See About the Policies section on page 124. Managing logs for stand-alone Scanners Several services maintain logs for message scanning and processing activities on each Scanner. All logs and their settings are individually defined within the appropriate program section of the configuration file. Log levels should be kept low, 4 for example, under normal operating situations. The <logdir></logdir> element sets the directory for log files in the Installation section of the configuration file, bmiconfig.xml. See About the Installation section on page 77. The logging behavior for all logs follows a common pattern which the <log></log> tag governs in each service section. Specified in this tag are log level, log retention characteristics, and log file location information. For stand-alone scanners, you must set the log level to 5 or more in bmiconfig.xml file to enable Message audit log in bmiconfig.xml file. About the log level element Specifies the log information level. The level is an integer from 0-7, designating the severity of the error. Choose from the following levels: Error conditions Warning conditions Normal but significant conditions Informational message Debug level message For problem situations, set this value to 6. After you resolve the difficulty, set it to 4. In some circumstances, Symantec Support may ask you to set the value to 7 to obtain debug information as well. Note: To capture a verdict for each message in the log, set bmserver logging to at least level 5. With high message volume this configuration can use up a large amount of disk space.

132 Configuring Messaging Gateway for Service Providers About the log period element 132 About the log period element Specifies the length of time to retain logs as a number of periodunits. About the periodunits element Interval for log retention, entered as a string. Valid values are day or hour. About the numberretained element Integer value that specifies the number of rolled logs to retain. If this value is left blank or set to 0, rollover logs are not deleted automatically. For example, if you want to roll over the log every 4 hours and maintain 42 old logs (1 weeks worth of logs with 4 logs per day) in addition to the current log, a <log></log> tag might look like as follows: <log level="4" period="4" periodunits="hour" numberretained="42"> /var/log/brightmail/$sectionname_log</log> The file into which log information is rolled from the primary file is named baselog_filenameperiod_start, where: baselog_filename period_start Indicates the process that is being logged. The beginning point of the previous period as defined in the <log></log> tag. As an example, if the Server starts at 3:25 PM on December 18, 2008, with the above configuration parameters, the existing log is rolled over to boserver_log , and at 4:00 PM, the log gets rolled over to log Any log activity between 3:00 and 4:00 PM is written to the 12:00 P.M. log. If the bmserver_log already exists on startup and contains entries after 12:00 PM, the original log is retained without change and all the currently logged items are appended to it. The contents of the first log after startup may vary depending on the time of startup and the length of time that the Server is inactive. About managing statistics for stand-alone Scanners Each Scanner maintains its own statistics for processing. The Scanner statistics are maintained in the file mc_stats.<epoch>.xml. For each file, the word epoch is replaced with a 10-digit number which is the UNIX epoch

133 Configuring Messaging Gateway for Service Providers About managing statistics for stand-alone Scanners 133 time (the number of seconds since January 1, 1970, 00:00 o'clock). The file is generated, at most, once per minute and is stored in the statistics directory. The stats directory is defined in the bmiconfig.xml file as: Linux and Solaris Windows <statsdir>/opt/symantec/smg-sp/scanner/stats</statsdir> Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. <statsdir>c:\program Files\Symantec\smg-sp\Scanner\stats</statsdir> The tag <statscleanthreshold> tag governs the retention period for this file in the Conduit section of bmiconfig.xml. The default file retention period for <statscleanthreshold> is three days. At the end of the retention period the Conduit deletes the file. The bmi_eng_stats and other stats files should not be modified. The Conduit should manage it directly. However, you can view the mc_stats.<epoch>.xml file to access statistics information. Table 5-18 lists the Scanner statistics tags that are in the contents file. Table 5-18 Tag LOG MSG ip etime latency bytes helo from VERD DISP rules RCPT addr Scanner statistics tags Description Log, includes version Message tag IP address End time of the message processing The time that it took the message to process The size of the message in bytes Helo domain Mail from address Verdict Disposition Rules that fired on this message Message recipient Recipient address

134 Configuring Messaging Gateway for Service Providers About conduit rule updates 134 Example: <LOG version="2.0"> <MSG ip=" " etime=" " latency="29" usertime="20000" systemtime="0" bytes="3505" helo="localhost" source="external" api="msg"> <MOD name="libbh"></mod><mod name="libintsig"></mod><mod name="libstatsig"></mod><mod name="libspamsig"></mod><mod name="libregexfilter"></mod><mod name="libspamhunter"><disp>spam</disp></mod><mod name="libpermit"></mod><mod name="libreinsert"></mod> <VERD rules=" , "><disp rules=" , "> spam</disp> <RCPT </VERD> </MSG> </LOG> About conduit rule updates The file ruleupdates.xml is a self-explanatory file that provides information about the type of rule that is updated and the time of last update. You may want to view this file to verify rule status for stand-alone Scanners. A single entry in the file appears as follows: <RULEUPDATE last-modified-date=" t05:45:30z" lastupdate=" t05:45:30z" module="module name" rawrulecount="number" rgmname="modulename_rules" rulecount="number" ruletype="rules"/> where: Module Rgmname Rawrulecount Rulecount Ruletype Name of module for which rule was updated Name of the directory for which the module was updated Total number of rules downloaded Total rules loaded by the engine If the downloaded type was a rule or a hash Table 5-19 describes the Conduit rule updates valid rule types.

135 Configuring Messaging Gateway for Service Providers About LiveUpdate rule updates 135 Table 5-19 Conduit rule types Rule type blrm hashes spamhunter spamsigs intsigs statsig permit_rules Module name regex hashes spamhunter spamsig intsig statsig permit About LiveUpdate rule updates The file jlustats.xml is a self-explanatory file that provides information about the antivirus ruleset that is updated. You may want to view this file to verify rule status for the Messaging Gateway for Service Providers stand-alone Scanners. A single entry in the file appears as follows: <RULEUPDATE ruletype="av" lastupdate="yyyy-mm-ddthh:mm:ss" lastupdate-status="status" current-status="status" last-modified-date=" YYYY-MM-DDThh:mm:ss" lastupdate-version="yyyy-mm-dd" lastupdate-revision="revision" lastupdate-package="package" last-good-update=" YYYY-MM-DDThh:mm:ss" retries-since-last-good-update="the NUMBER OF ATTEMPTS" /> The RULEUPDATE attributes are described as follows: ruletype lastupdate lastupdate-status current-status The type of the rule that is updated. The date and the time when the antivirus rule set was last downloaded. Date and time are given in UTC (Coordinated Universal Time). Status of the last downloaded antivirus ruleset. A status can be In-progress, Success, Failed, or Waiting. Status of the current antivirus ruleset download. A status can be In-progress, Success, Failed, or Waiting.

136 Configuring Messaging Gateway for Service Providers About LiveUpdate rule updates 136 last-modified-date lastupdate-version The date when Symantec Security Response changed the ruleset. Date and time are given in UTC. The version of the last downloaded antivirus ruleset. A version is the date when Symantec Security Response released the ruleset. For example, lastupdate-version=" " lastupdate-revision The revision of the last downloaded antivirus ruleset. A revision is the number of the ruleset version. For example, lastupdate-revision="33" lastupdate-package last-good-update retries-since-last-good-update The file name of the ruleset that was last downloaded. The latest successfully downloaded antivirus ruleset. The number of attempts made to download the antivirus ruleset since last successful download. See About conduit rule updates on page 134. See About updating virus definitions on page 201.

137 Chapter 6 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers This chapter includes the following topics: About integrating the Sun Java Messaging Server MTA with Messaging Gateway for Service Providers Installation overview Configuring Messaging Server for Messaging Gateway for Service Providers Configuring a multi-node deployment About enabling the tracker for Messaging Server Troubleshooting issues with Messaging Server integration About integrating the Sun Java Messaging Server MTA with Messaging Gateway for Service Providers This section describes how the Sun Java System Messaging Server MTA (Messaging Server) interacts with Messaging Gateway for Service Providers to create a secure environment.

138 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers Installation overview 138 Installation overview Follow these instructions to install the Messaging Gateway for Service Providers server. Then, configure Messaging Server to use Messaging Gateway for Service Providers. Messaging Gateway for Service Providers software can be located on the same system as the MTA or on a separate host. Alternatively, you can have a farm of Messaging Gateway for Service Providers Servers serving one or more MTAs. The Messaging Gateway for Service Providers SDK uses the bmiconfig_client.xml file to determine which servers to use. These steps assume that you install the Messaging Gateway for Service Providers server and Messaging Server on the same host. See Configuring a multi-node deployment on page 144. Messaging Server uses the Messaging Gateway for Service Providers SDK to communicate with the Messaging Gateway for Service Providers server. The MTA dispatches the messages that are based on the response from Messaging Gateway for Service Providers. After an MTA receives a mail message, the MTA sends a copy of the message contents to the Messaging Gateway for Service Providers server. Messaging Gateway for Service Providers determines if the message is a spam or virus. It then returns a destination string to the MTA. Based on the destination string, the MTA either discards the message, alters it, delivers it to a particular folder in the Message Store. The MTA might also deliver it to the default inbox folder, depending on the Sieve action that is configured on the Sun Java Messaging Server side Once the SDK is loaded, several factors and levels of granularity determine the Messaging Gateway for Service Providers message processing. You use the software to opt-in for active processing of one form or another by using a specific "optin" value. The following criteria determine message processing behavior: Whether the source channel or destination channel is enabled for Messaging Gateway for Service Providers (imta.cnf) Whether there is a channel default for the services for which you have opted-in (imta.cnf) Whether there is a per domain opt-in value (LDAP) Whether there is a per-user opt-in value (LDAP) Messaging Server passes an opt-in variable to the Messaging Gateway for Service Providers server according to the following conditions:

139 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers Configuring Messaging Server for Messaging Gateway for Service Providers 139 If a destination opt-in value (spamfilternoptin) or a source opt-in value (sourcespamfilternoptin) is passed, marking is placed on a relevant channel in the imta.cnf file. If a domain or user has the appropriate LDAP attribute set to an opt-in value, the opt-in value is passed as the value of the optin variable to Messaging Gateway for Service Providers. If you enable the client-side opt-in and the opt-in value is not set, the default is NULL. Specific users' s are not filtered with any Messaging Gateway for Service Providers services. Thus, if you want to configure no filtering and the Messaging Gateway for Service Providers client side filtering is enabled, pass NULL as the opt-in value to Messaging Gateway for Service Providers. The following opt-in values are offered with Messaging Gateway for Service Providers: spam virus reinsert language custom consent In addition, Messaging Gateway for Service Providers supports Group Policies, which enable different actions for different users according to the same verdict. See About group policies on page 164. When a message contains a virus, you can configure the software to clean the virus and resubmit the cleaned message back to the MTA. Messaging Server supports early verdicts when this feature is enabled in Messaging Gateway for Service Providers (this feature is disabled by default). See Table 5-10 on page 103. Configuring Messaging Server for Messaging Gateway for Service Providers Follow these procedures to configure Messaging Server for Messaging Gateway for Service Providers and verify that it functions.

140 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers Configuring Messaging Server for Messaging Gateway for Service Providers 140 Note: A backward slash (\) at the end of a line of code indicates that the line continues unbroken to the following indented line.

141 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers Configuring Messaging Server for Messaging Gateway for Service Providers 141 To modify the option.dat and imta.cnf files 1 Modify the option.dat file as follows. The Messaging Gateway for Service Providers client is located under the /usr/lib directory. The bmiconfig_client.xml file is located under the /opt/sunwmsgsr/config/ directory.!! Brightmail Configuration Settings!! Fundamental options to locate the Brightmail client library routines and! client library configuration file:! SPAMFILTER1_CONFIG_FILE=/opt/SUNWmsgsr/config/ bmiconfig_client.xml SPAMFILTER1_LIBRARY=/user/lib/libbmiclient.so!! Options typically recommended for good operational practice; but make! sure you haven't already set LOG_FILTER elsewhere in option.dat!! SPAMFILTER1_OPTIONAL=-2 LOG_FILTER=1!! Site's goal-specific/brightmail-configuration-specific options;! must be coordinated with site's Brightmail configuration:!! The "null" verdict -- means to discard the message! SPAMFILTER1_VERDICT_0=null SPAMFITLER1_ACTION_0=data:,discard!! An "X-verdict: spam" verdict -- means to file to "spam" folder! SPAMFILTER1_VERDICT_1=*X-verdict: spam* SPAMFILTER1_ACTION_1=data:, require "fileinto"; fileinto "spam";

142 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers Configuring Messaging Server for Messaging Gateway for Service Providers Modify the imta.cnf file. Messaging Gateway for Service Providers scanning can be selected in the MTA in a variety of ways, by use of either a per-user or per-domain LDAP attribute or according to a source or a destination channel. A typical usage is to scan the messages that are destined for locally hosted users. In other words, on all of the messages that are delivered to users by an ims-ms channel, or by tcp_lmtp* client channels. For instance, to trigger Messaging Gateway for Service Providers spam filtering on all of the messages that ims-ms channel delivers to the store. If the system uses spam or virus filter package # 1, add destinationspamfilter1optin spam, virus, reinsert, language, custom, and consent to the ims-ms channel definition in the imta.cnf file. Such a channel definition might appear as follows:! ims-ms ims-ms defragment subdirs 20 notices \ backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" \ maxjobs 2 pool IMS_POOL fileinto $U+$S@$D \ destinationspamfilter1optin1 \ spam,virus,reinsert,language,custom,consent ims-ms-daemon 3 Compile the MTA configuration../imsimta cnbuild 4 Restart the MTA Dispatcher. This step causes the MTA to start a new SMTP process with the new Messaging Gateway for Service Providers configuration. imsimta restart dispatcher

143 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers Configuring Messaging Server for Messaging Gateway for Service Providers 143 To verify that the Messaging Server is operational 1 Run the imsimta test -rewrite command on a sample local user address. There should be no errors. For example: /opt/sunwmsgsr/sbin/imsimta test -rewrite -debug=level=4 -filter [email protected] 12:32:29.33: - passed. 12:32:29.33: - send_access mapping check: l [email protected] ims-ms user99@ims-ms-daemon 12:32:29.33: Mapping 4 applied to [email protected] ims-ms user99@ims-ms-daemon 12:32:29.33: Final result "l [email protected] ims-ms user99@ims-msdaemon" 12:32:29.33: - passed. 12:32:29.33: - adding address user99@ims-ms-daemon to channel ims-ms 12:32:29.33: Closing URL context 1, new type = 7 12:32:29.33: - adding address [email protected] to headers. 12:32:29.33: Copy estimate after address addition is 2 *** Expanded address: [email protected] Submitted address list: ims-ms user99@ims-ms-daemon (orig [email protected], inter [email protected], host ims-ms-daemon) *NOTIFY-FAILURES* *NOTIFY-DELAYS* Submitted notifications list: 2 Compose and send an . 3 Look at the Messaging Gateway for Service Providers server logs under the /var/log/brightmail directory and verify that the bmserver_logs file contains information about this message. 4 If the MTA is configured as described in the preceding steps with the following values for option.dat options: SPAMFILTER1_VERDICT_0=null SPAMFILTER1_ACTION_0=data:, discard SPAMFILTER1_VERDICT_1=*X-verdict: spam*

144 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers Configuring a multi-node deployment 144 SPAMFILTER1_ACTION_1=data:, require "fileinto"; fileinto "spam"; LOG_FILTER=1 then the LOG_FILTER=1 causes inclusion of an additional field in the message transaction records in the mail.log* files that record both other sorts of Sieve filter results, as well as Messaging Gateway for Service Providers results that are applied to each message recipient. Exactly what appears in the result portion of this field depends on the verdict or destination that the software returns, and how the MTA in turn is configured to react to that verdict or destination. But the general form is: spamfilter<n>:<hash-of-mta-verdict-option>, <Sieve-action(s)-comma-separated> where in general (when other forms of Sieve filtering are also in use) this is one part (also comma-separated) within the overall filter field. For instance, a message recipient with no general MTA Sieve, no applicable channel Sieve, no applicable domain Sieve, and no personal Sieve, but where Messaging Gateway for Service Providers returned a "null destination-data" result (normally configured to be interpreted as a request to discard the message, it having been determined to be spam), where here Messaging Gateway for Service Providers is assumed to be configured as spam/virus filter package # 1, might show in the filter field as: 'spamfilter1:eaa5ndzbmui5mzc2ndq1nj==, discard;' 5 Or, if the system has been configured to return X-brightmail: destination-data (normally configured to be interpreted as a request to file the message to a "spam" folder), in the case of messages that are determined to be spam, then this might show in the filter field as: 'spamfilter1:4bopbmmlplff4jax2iwlng==, fileinto "spam";' If you set SPAMFILTER1_OPTIONAL=-2 and LOG_FILTER=1, then that provides the following two ways to verify the MTA/Messaging Gateway for Service Providers operation: Check for warning syslog messages. Check that "expected" results appear in the filter field in mail.log* records. Configuring a multi-node deployment On a multi-node installation of Messaging Gateway for Service Providers and Messaging Server -- where the Messaging Gateway for Service Providers server

145 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers About enabling the tracker for Messaging Server 145 is running on one host and Messaging Server is running on a separate host -- in addition to the previous steps, perform the following steps: To configure Messaging Gateway for Service Providers on multi-node deployments 1 Copy the libbmishareddata.so to the Scanner directory. For example: cp libbmisharedata.so /opt/symantec/smg-sp/scanner/lib 2 Make sure that the Messaging Gateway for Service Providers Client is installed where your MTA exists. About enabling the tracker for Messaging Server The Client can provide the rule IDs of the rules that were violated to the Messaging Server. Specific details on violated rule IDs are listed in the XBrightmail-Tracker header for a given message and Symantec Support can use to help diagnose problems. The following is an example of an encoded X-Brightmail-Tracker header: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJpMTGxVLPwMCoK8Eb52twvJffYu0aEQdGj+Vrb7IGMEY JBpcmZaUml1gpRAcXJObGqhYnCGZ8XfaSpeAIU8XvmVcYGxh3MHUxcnAICfhLtH 0N7WLk5BAW4JU4fL2PEcSWEBCVeDCpm2kCI/ MqRpbi0jyjTYxAG7luKuzZwXh3vc4hRiYOzkOMAhyMSjy8jAwMDEKsiWXFlbkgce 5DjJIcTEqiEHG+pPyUyozE4oz4otKc1OJDjBIcPEoiEDneYqDbijPTYVJqHBwCC3r ZpFhA4koSEEWCRanpqRVpmTklqUUQhZcYRaWEIZI8BalFuZklEPFXjOJA98BkMvNK4Ea/ AtrKhLC1JBEhJdXAaFWsrvtk67qSx1sXnRed5rfp5mVBv3ucZ76aeJblNIm3l2XoTv SK/zV/zaOIrkXRHo8KnjV6RF1IWS4df1Qy5fZaTh+f8rJdZmlGK7LEDB6+5t7XuPn1 r2fxxlfnjztpka+2nizoflow8dwemi+3azqf1/jvdai41g5wtlu4pdxc9jk65xfojz bijerdleai4kqaghpfcdwbaaa= To create a header with the value that the Client returns, you can use one of the following methods:

146 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers Troubleshooting issues with Messaging Server integration 146 Modify the filter Modify the filter in option.dat file as follows: require ["addheader"]; addheader "X-Brightmail-Tracker $M" For example: SPAMFILTER1_STRING_ACTION=data:,require "addheader"; addheader "X- Brightmail-Tracker: $M";addtag "SPAM detected $U" $M acts as a substitute character that adds the tracker information after the X-Brightmail-Tracker header. This setting should always be enabled. Modify the option.dat file In the option.dat file, add the following entry: LOG_FILTER = 1 This entry logs the verdict, the tracker, and the action taken. Troubleshooting issues with Messaging Server integration Use the following suggestions to troubleshoot problems with your configuration: If there is a problem in bringing up the Messaging Gateway for Service Providers server, check the log file for errors. If the log file does not display errors, then there is most likely a write permissions problem with the log file. For troubleshooting problems, you can change the log level from the default of 4 to log level 7. Level 7 should be used for debugging only. Leaving the debug level at 7 decreases performance and fills your disk. Modify the bmiconfig.xml file under the /opt/symantec/smg-sp/scanner/etc directory to change the server log level from the default value of 4 to 7. Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. If you are using a non-default directory, modify the bmiconfig.xml file under the /$loadpoint/scanner/etc directory. Then restart the mailwall. Also, modify the bmiconfig_client.xml file in the /opt/symantec/smg-sp/scanner (default directory) or /$loadpoint/scanner (non-default directory) to change the client log level from 4 to 7, and then restart the client. If there is a problem with either Messaging Gateway for Service Providers itself, or with the integration configuration, check the following: If the SPAMFILTERn_OPTIONAL option in the file option.dat is set to -2 or 2, then

147 Configuring Java Messaging Server to integrate with Messaging Gateway for Service Providers Troubleshooting issues with Messaging Server integration 147 trouble getting a result back from the nth spam or virus filter package results in a syslog notice, with syslog facility and the severity that the SNDOPR_PRIORITY global MTA option controls, with text of the general form: SPAMFILTERn, error-text When Messaging Gateway for Service Providers is the spam filter or virus filter package, more informational text may be available. If error location or type information is also available, then the text takes the form: where the square bracket characters that is shown above indicate the optional additional information and are not part of the actual output string. In the case of Messaging Gateway for Service Providers, the error-text always indicates the stage at which processing failed. The error-location can be any of client, network, or server; the error-type can be any of memory, network, timeout, data, module down, type arg, or bad version. SPAMFILTERn, error-text [ - error-location ][ - error-type ] When configuring the MTA for Messaging Gateway for Service Providers, consider turning on other debug items until the spam filter works (in option.dat). For example:! Turn on debug info mm_debug=5 os_debug=1

148 Chapter 7 Configuring Sendmail to integrate with Messaging Gateway for Service Providers This chapter includes the following topics: About integrating Sendmail Understanding the filter address and optional settings About configuring Sendmail Switch to work with Messaging Gateway for Service Providers Configuring Sendmail for Messaging Gateway for Service Providers with sendmail.cf About configuring Sendmail for Messaging Gateway for Service Providers with M4 About using the runner and cron Understanding automatic library paths About managing Scanner components with the runner Starting the runner About stopping the runner (and all Scanner jobs) Testing the runner

149 Configuring Sendmail to integrate with Messaging Gateway for Service Providers About integrating Sendmail 149 About monitoring job statuses About stopping and starting jobs About the runner configuration file About integrating Sendmail The Messaging Gateway for Service Providers Client communicates with the Sendmail MTA with the Sendmail Mail Filter API. To implement this integration, the Messaging Gateway for Service Providers Client uses the Filter (bmifilter -- an intermediary program) which connects to Sendmail over a socket connection. The Filter program also controls client-side actions, such as removing mail and tagging spam. Based on the version of Sendmail that you use, do the following: If you use Sendmail Switch, use the Sendmail Administration Console to define the filter. See About configuring Sendmail Switch to work with Messaging Gateway for Service Providers on page 150. If you use Sendmail or later, either manually edit the sendmail.cf file or edit the M4 file. See Configuring Sendmail for Messaging Gateway for Service Providers with sendmail.cf on page 151. See About configuring Sendmail for Messaging Gateway for Service Providers with M4 on page 153. When you install Messaging Gateway for Service Providers, the Filter is configured to use port with a default setting of inet: This Filter port number must correspond to the port number for the Xbmifilter setting in Sendmail. Understanding the filter address and optional settings In Sendmail and later, the X setting has the following format: Xbmifilter,S=inet:<port_number>@<computer>.your_domain.com where <port_number> is the valid networking port number that you configured for the bmifilter program, and <computer> is the IP address or DNS name of the computer that runs bmifilter. You can also specify the behavior when Sendmail cannot connect to the Filter. You can configure Sendmail to:

150 Configuring Sendmail to integrate with Messaging Gateway for Service Providers About configuring Sendmail Switch to work with Messaging Gateway for Service Providers 150 Temporarily reject the message with an SMTP 4xx instruction. To specify this behavior, add the F=T flag to the X setting. Permanently reject the message with an SMTP 5xx instruction. To specify this behavior, add the F=R flag to the X setting. Accept the message and send it through (as if the Filter is not present). You specify this behavior by omitting the F= option. Specify a timeout period. To specify a timeout period, add the T=C flag to the X setting. The following example omits the F= flags so that Sendmail accepts messages if it cannot connect to the Filter: Xbmifilter, S=inet:41001@<computer>.your_domain.com where <computer> is the host to which Sendmail connects. If you do not specify a computer name, Sendmail tries to connect on the same computer. In Sendmail Switch, you specify the filter name, filter address, and optional settings differently. You type bmifilter in the Filter Name field, and the filter address and optional settings in the Equates field of the INPUT_MAIL_FILTERS() option. See About configuring Sendmail Switch to work with Messaging Gateway for Service Providers on page 150. The following example shows the use of the T= flag to specify a timeout period (this example may not be optimal for your environment): Xbmifilter, S=inet:[email protected]_domain.com, F=T, T=C:10m;S:1m;R:1m;E:10m where C is the connect timeout, S is the send time-out, R is the receive timeout, E is the total timeout, and m represents minutes. To specify both F= and T= flags, separate them with a comma followed by a space. For more information on the syntax for this setting, on the Internet, go to the following URL: About configuring Sendmail Switch to work with Messaging Gateway for Service Providers Before you follow this procedure, make sure that you have followed the instructions to configure Milter protocol for sendmail.

151 Configuring Sendmail to integrate with Messaging Gateway for Service Providers Configuring Sendmail for Messaging Gateway for Service Providers with sendmail.cf 151 To configure Sendmail Switch to work with a Messaging Gateway for Service Providers 1 Use the appropriate URL for your environment and open the Sendmail Administrator Console in a Web browser. 2 Log on to the Sendmail Administrator Console. 3 Click Edit Existing Configuration. 4 If necessary, select the host or cluster to configure, and then click select. 5 Highlight an existing configuration or type a configuration in the text field, and then click load. 6 In the menu on the left side, click Expert Configuration. 7 In the scrolling list, select INPUT_MAIL_ FILTERS(), and then click view/edit. 8 Click add. 9 In the Filter Name field, type bmifilter. 10 In the Equates field, specify the filter address and any optional settings. The following example is appropriate in most cases: S=inet:[email protected], T=C:10m;S:1m;R:1m;E:10m The filter name and the filter executable name must be the same to monitor it from the Service Control page. See Understanding the filter address and optional settings on page Click Apply to apply the filter. 12 Save your changes and deploy the configuration file. Configuring Sendmail for Messaging Gateway for Service Providers with sendmail.cf You can configure Sendmail to work with Messaging Gateway for Service Providers in several ways. You can either edit the sendmail.cf file, or you can use M4 to generate a new sendmail.cf file. The information about using M4 is available. See About configuring Sendmail for Messaging Gateway for Service Providers with M4 on page 153. The instructions to be followed, before you start this procedure, are available.

152 Configuring Sendmail to integrate with Messaging Gateway for Service Providers Configuring Sendmail for Messaging Gateway for Service Providers with sendmail.cf 152 To configure Sendmail for Messaging Gateway for Service Providers with sendmail.cf 1 Log on as root. 2 Open the Sendmail configuration file, sendmail.cf. The sendmail.cf file is located in the following location: /var/mail/sendmail.cf or /etc/mail/sendmail.cf. 3 In the OPTIONS section, add the Filter as follows: OPTIONS O InputMailFilters=bmifilter 4 In the MAIL FILTER DEFINITIONS section, type the following line to complete the socket for the Filter configuration: Xbmifilter, S=inet:[email protected]_domain.com See Understanding the filter address and optional settings on page Save the file. 6 Type the following command to stop Sendmail: # /etc/init.d/sendmail stop 7 Type the following command to verify that Sendmail is no longer running: # ps -ef grep sendmail 8 If any processes are shown other than grep, type the following command for each process to terminate it: # kill process_id 9 Type the following command to restart Sendmail: # /etc/init.d/sendmail start 10 Type the following command to verify that Sendmail has restarted: # ps -ef grep sendmail

153 Configuring Sendmail to integrate with Messaging Gateway for Service Providers About configuring Sendmail for Messaging Gateway for Service Providers with M4 153 About configuring Sendmail for Messaging Gateway for Service Providers with M4 You can configure Sendmail to work with Messaging Gateway for Service Providers in several ways. You can either edit the sendmail.cf file, or you can use M4 to generate a new sendmail.cf file. This section covers what you need to know to use M4 to configure Sendmail. The information about using sendmail.cf file is available. See Configuring Sendmail for Messaging Gateway for Service Providers with sendmail.cf on page 151. The instructions to be followed before you start this procedure are available. If you use an M4 file, instead of editing sendmail.cf, you should edit your M4 file to include the following command, and then regenerate your sendmail.cf file as usual: INPUT_MAIL_FILTER( bmifilter', S=inet:[email protected], T=C:10m;S:5m;R:5m;E:10m') where is any valid networking port number that you configure for the bmifilter program, and machine.xyz.com is the IP address or DNS name of the computer that runs bmifilter. This command must come after any MAILER line(s). The information about timeout settings is available. See Understanding the filter address and optional settings on page 149. About using the runner and cron Both cron and the runner play a major role in operating scanners. The following section describes the important interactions. Understanding automatic library paths Each script that a crontab statement calls refers to the file, /opt/symantec/smg-sp/scanner/etc/brightmail-env. Note: If you use a non-default installation directory location, replace /opt/symantec/smg-sp/scanner with /$loadpoint. The following command sets the LD_LIBRARY_PATH: # Sets environment variables needed by Symantec # Brightmail Anti-Spam executables. LD_LIBRARY_PATH=/opt/symantec/smg-sp/

154 Configuring Sendmail to integrate with Messaging Gateway for Service Providers About managing Scanner components with the runner 154 Scanner/lib:/usr/local/lib export LD_LIBRARY_PATH BMI_CONFIG_FILE=/opt/symantec/smg-sp/Scanner/ etc/bmiconfig.xml export BMI_CONFIG_FILE If you ever need to reset LD_LIBRARY_PATH to a value other than this default, change its value in this file. The value is passed to crontab. About managing Scanner components with the runner The runner is a job control shell similar to inittab in UNIX. A configuration file configures the runner that you specify during the invocation of the runner. Use the runner to start, monitor, and stop program facilities for an individual Scanner as necessary. When the runner starts, it creates a lock file with a name generally formed as runner_configuration_file_name.lock. This file guards against multiple instances of the runner starting with a configuration file that is already in use and controlling the processes that are specified in the configuration file. The runner creates pid files for the processes it starts at /opt/symantec/smg-sp/scanner/jobs. The kicker uses one of the.pid files that the runner creates (bmserver.pid) to reload rules as they are received from Symantec Security Response. The complete path to this file is as follows: /opt/symantec/smg-sp/scanner/jobs/$program/$program.pid where $program represents a particular component. Note: If you use a non-default directory, replace /opt/symantec/smg-sp/scanner with /$loadpoint/. The runner is configured to monitor the Server daemons and restarts any defined jobs that exit. By default, the runner executes a clean-up script that is called process-cleanup before it restarts any job that exits with a non-zero status. The clean-up script puts crash information in a directory and sends a notification to the postmaster alias. Depending on the exit status of a job, the clean-up script can also perform additional functions. In Scanner stand-alone or troubleshooting situations, you can use the runner to start, monitor, and stop the following job processes: Server Conduit Filter

155 Configuring Sendmail to integrate with Messaging Gateway for Service Providers Starting the runner 155 LiveUpdate The runner can start the Server but for the AntiSpam Filters Module and the AntiVirus Filters Module remain inactive. This situation happens if a module is not registered or if a trial time period has expired. Check the logs for the Server if you suspect such a condition exists. Starting the runner During installation, an rc script for the runner is installed in /etc/init.d. The rc script is called mailwall. You can start, stop, and restart the runner with the following commands: /etc/init.d/mailwall start /etc/init.d/mailwall stop /etc/init.d/ mailwall restart You can also start the runner from the command line. The runner takes as a single argument the location of the configuration file and service that you want to control. For example, you can type the following command to control the Server: $ /opt/symantec/smg-sp/scanner/etc/runner /opt/symantec/smg-sp/ Scanner/etc/runner.cfg & Note: If you use a non-default directory, replace /opt/symantec/smg-sp/scanner with /$loadpoint/. The runner then operates in the background, so there is no response. You can check that the runner is functional by searching for its process ID: $ ps -ef grep runner This command should return process IDs for all of the jobs that are specified in runner.cfg, along with other information. About stopping the runner (and all Scanner jobs) You can stop the runner with /etc/init.d/mailwall stop. You can also send a TERM signal to the runner as user mailwall: $ ps -ef grep runner $ kill runner_pid where runner_pid is the process ID that the ps command you ran first returns.

156 Configuring Sendmail to integrate with Messaging Gateway for Service Providers Testing the runner 156 The runner then sends TERM signals to its jobs, waits until they exit, and then terminates itself. Testing the runner During installation, the install script creates a customized runner configuration file that includes job lines for the Server, the Conduit, the LiveUpdate, and BMI Filter. See About the runner configuration file on page 158. Note: Stop the runner if it is executing. Otherwise, the runner restarts jobs after you stop them. To test the runner 1 Type the following command to verify that no Messaging Gateway for Service Providers software processes are running. Otherwise, when you start the runner, duplicate processes contend for ports. $ ps -ef grep mailwall $ kill bmserver_process_id \ conduit_process_id bmifilter_process_id 2 As user mailwall, type the following command to invoke the runner. $ /etc/init.d/mailwall start See Starting the runner on page Wait for the runner to start the jobs. The specific amount of time that you must wait for the runner to start all of the jobs depends on the wait times that are specified in the configuration file that you use. 4 Type the following command to verify that the runner has started and that it has started all of the processes that are specified in the runner configuration file. $ ps -ef grep mailwall The runner monitors following processes: Server Conduit Filter

157 Configuring Sendmail to integrate with Messaging Gateway for Service Providers About monitoring job statuses 157 LiveUpdate 5 As user mailwall, type the following command to terminate the runner: $ /etc/init.d/mailwall stop About monitoring job statuses After it has started, the runner reads its configuration file. Then it starts jobs for each process, waiting the initial wait period that is configured in the respective job control line. The runner creates a file called job-name.pid in the working directory of each job that is started. However, the runner does not have its own PID file. The location for each job is defined in the D attribute of the runner.cfg file. When the job exits, the runner deletes the file. The presence of the file is an indication that the job is running. If a job exits with a non-zero status, the runner executes the process-cleanup script along with any secondary processes clean-up can require, waits the configured normal wait period, then restarts the process. The process-cleanup script creates a directory that is also in the location that the D option of the job control line specifies. The directory name is based on the date timestamp and timestamp of the event. The process-cleanup script places the following types of files in this directory: core.z file, if there is a core dump If the computer's core size is set too low, no dump is provided. For that reason, set the core size to unlimited. ps/pid files that list the processes that are running at the time (to facilitate troubleshooting) File that contains the message that are sent to the postmaster ident output of each module and library Regularly monitor and delete the accumulated files in this directory. Sending a USR1 signal to the runner causes it to write the following information to the logging facility that the F parameter in the runner.cfg file specifies: List of jobs Current states Total run time Number of crashes (non-zero exits)

158 Configuring Sendmail to integrate with Messaging Gateway for Service Providers About stopping and starting jobs 158 About stopping and starting jobs To stop a single process, create a file called job-name.stop in the working directory of the process. The contents of the file are irrelevant -- only the name is used. The name should match the job name that is specified in the N attribute of the job line in the runner.cfg file. For example: $ touch job-name.stop Once every second, the runner looks in the working directory of each job for a file called job-name.stop. If the file exists, the runner first sends a TERM. If the job does not turn off in the termination period, the runner sends a KILL. Stopped jobs do not run their clean-up scripts. A job can be restarted by removing the job-name.stop file. The runner restarts the job the next time it checks the working directory (once every second). If the job is not running and there is no job-name.stop file in its working directory, check the runner configuration file to make sure that the job control entry for the process is correct. See About the runner configuration file on page 158. Once you are sure that there is a proper entry for the job in the runner configuration file, you can restart the runner. About the runner configuration file The runner.cfg file must be set up on every computer that is running a Scanner. It is installed by default on the computer or computers where the installer runs. An example runner.cfg file based on the default directory is as follows: # The runner does not support the UNIX backslash convention # Lines in this file are one of the following: # -Comments: null or start with "#" # -Termination: default termination period is the period after TERM signals # are sent to the jobs (after the runner gets a TERM) during which it waits # for them to die nicely; if they haven't died in this period then runner # kills them with impunity (KILL) # format is "T<number of seconds>" # -Facility: set the syslog facility

159 Configuring Sendmail to integrate with Messaging Gateway for Service Providers About the runner configuration file 159 # format is "F<syslog_facility>" # -User/Group: sets user and group that runner and all children run as # format is "U<user_name>:<group_name>" where: # U<user_name> -- switches user but leaves group unchanged # U:<group_name> -- switches group but leaves user unchanged # U<user_name>:<group_name> -- switches both user and group # -Option: The one option available is to operate runner as a daemon or # not as a daemon # format is Ooption, where: # Odaemon -- runner operates as a daemon # Onodaemon -- runner does not operate as a daemon # If omitted, the default setting of Onodaemon is used # -Job control: define a job to run # format is "J<N>^<D>^<E>^<C>^<I>^<R>" where: # J -- initial character of each job control line # N -- job name # D -- directory to start job and cleanup from # E -- program name to exec (with args) # C -- cleanup program name to exec (with args) # special args allowed in the C argument list are: # -v3 -- indicates that %E and %G are needed # (if this parameter is not present process-cleanup # doesn't need %E and %G) # %N -- name of job # %S -- job exit status # %E -- job exit code # %G -- job signal code # %O -- path to file with the program's output # I -- initial wait period (number of seconds before first running of <E>) # R -- normal wait period (number of seconds after cleanup before # subsequent running of <E>) # set termination period to 30 seconds T30 # change the syslog facility to mail Fmail # change the user to mailwall Umailwall

160 Configuring Sendmail to integrate with Messaging Gateway for Service Providers About the runner configuration file 160 # set daemon option to operate runner as a daemon Odaemon # jobs #bmserver job line Jbmserver^/opt/symantec/smg-sp/Scanner/jobs/bmserver ^/opt/symantec/smg-sp/scanner/bin/bmserver -c /opt/symantec/smg-sp/scanner/etc/bmiconfig.xml ^/opt/symantec/smg-sp/scanner/etc/process-cleanup -v3 %N postmaster %S %E %G %O^0^0 #conduit job line Jconduit^/opt/symantec/smg-sp/Scanner/jobs/conduit ^/opt/symantec/smg-sp/scanner/bin/conduit -c /opt/symantec/smg-sp/scanner/etc/bmiconfig.xml ^/opt/symantec/smg-sp/scanner/etc/process-cleanup -v3 %N postmaster %S %E %G %O^10^0 # the bmifilter job for sendmail-milter. # This job requires that the directory: # bmifilter exists, and is writeable by runner. #bmifilter job line Jbmifilter^/opt/symantec/smg-sp/Scanner/jobs/bmifilter ^/opt/symantec/smg-sp/scanner/bin/bmifilter -c /opt/symantec/smg-sp/scanner/etc/bmiconfig.xml ^/opt/symantec/smg-sp/scanner/etc/process-cleanup -v3 %N postmaster %S %E %G %O^30^5 #jlu-controller job line Jjlu-controller^/opt/symantec/smg-sp/Scanner/jobs/jlu-controller ^/opt/symantec/smg-sp/scanner/bin/jlu-controller -c /opt/symantec/smg-sp/scanner/etc/bmiconfig.xml ^/opt/symantec//scanner/etc/process-cleanup -v3 %N postmaster %S %E %G %O^10^0 Note: If you modify the runner.cfg file, you must restart the runner by typing: /etc/init.d/mailwall restart Table 7-1 lists the configuration file types of entries.

161 Configuring Sendmail to integrate with Messaging Gateway for Service Providers About the runner configuration file 161 Table 7-1 Entry type Comments Termination period Configuration entry types Description Blank lines or the lines that start with a pound sign (#) are comments. The format for the termination period is: Tseconds where seconds is a positive integer. (In the example, this number is 30.) After TERM signals are sent to the jobs of the runner, the runner waits for them to exit cleanly for the interval that T defines. If they have not exited by the end of this interval, then the runner terminates them with KILL. Logging facility The runner can direct output to standard error (stderr), which sends errors directly to the user terminal, or to one of the standard syslog facilities at the ERR level. The format for the logging facility is: Ffacility where facility is the name of any standard syslog facility. (In the example, this is mail.) See syslog documentation for the standard syslog facilities. Note: The logging facility that is specified relates to information that the runner logs. The jobs that the runner log operates to the locations that is specified in the Brightmail configuration file, bmiconfig.xml. User and group name You can change the user in the runner by editing the U option in the runner.cfg file. This definition includes all groups of which the user is a member. The format for the user is: U$username In the example, this is Umailwall:bmi. With this setting, runner and all jobs it operates start as mailwall. Daemon operation You can set up the runner to operate as a daemon. If you omit this line, the runner does not operate as a daemon. The possible settings are as follows: Odaemon The runner operates in the background as a daemon Onodaemon The runner does not operate as a daemon Note: The instructions throughout this document assume that the runner operates as a daemon.

162 Configuring Sendmail to integrate with Messaging Gateway for Service Providers About the runner configuration file 162 Table 7-1 Entry type Job control lines Configuration entry types (continued) Description Each of these lines defines a job to run. With the exception of the first two elements, each element in the job control line is separated by a carat (^). The format is: JN^D^E^C^I^R. This table uses as its example the first job line in the runner configuration file: Jbmserver^/opt/symantec/smg-sp/Scanner/jobs/bmserver ^/opt/symantec/smg-sp/scanner/bin/bmserver -c /opt/symantec/smg-sp/scanner/etc/bmiconfig.xml ^/opt/symantec/smg-sp/scanner/etc/process-cleanup -v3 %N postmaster %S %E %G %O^0^0 Note: If you use a non-default directory, replace /opt/symantec/smg-sp/scanner with /$loadpoint/. The following list describes the elements in the runner configuration file: J Initial character of job control line. For example: J N Job Name: ASCII string that defines the name of the job. For example: bmserver D Working Directory: The runner starts the job and archives cleanup in this directory. The runner also places PID files in this directory. If the job dumps core and is configured to do so, it dumps in this directory For example: /opt/symantec/smg-sp/scanner/jobs/bmserver E Program Name to run (with arguments). The Server takes one argument: -c /path/to/config indicates the path to the configuration file. For example: ^/opt/symantec/smg-sp/scanner/etc/process-cleanup -v3 %N postmaster %S %E %G %O %O = Use job output filename (stdout and stderr)

163 Configuring Sendmail to integrate with Messaging Gateway for Service Providers About the runner configuration file 163 Table 7-1 Entry type Configuration entry types (continued) Description Job control lines (continued) C Cleanup program name to run (with arguments). If C is empty, no cleanup script is executed. Special arguments are allowed in the C argument list: -v3 = indication that %E and %G parameters is used in clean-up %N = Name of job (for example, bmserver) postmaster = address to send report; the postmaster alias must exist and be properly configured %S = Job exit status %E = job exit code %G = job signal code I Initial wait period: The number of seconds before first running of E For example: 0 R Normal wait period: The number of seconds after cleanup before restart of E. For example: 0

164 Chapter 8 Using group policies This chapter includes the following topics: About group policies Creating group policies Working with group policies About group policies Unlike previous releases of Symantec Message filter, which supported an unlimited number of user groups, Symantec Messaging Gateway for Service Providers supports a single policy: the Default policy. However, if you update from Symantec Message Filter 6.3, your custom user groups are retained. You can configure message management options for an unlimited number of user groups with the group policies that you can define. Policies collect the antispam, antivirus, and filtering verdicts and apply actions for a group. Messaging Gateway for Service Providers provides a preconfigured Default group policy, which is enabled by default. The Default group policy contains all users and all domains. Although you can modify actions for the Default group policy, you cannot add members to, change the precedence of, nor delete this group policy. See Creating group policies on page 165. See Working with group policies on page 166. Table 8-1 shows the actions that you can select for verdicts.

165 Using group policies Creating group policies 165 Table 8-1 Verdict verdicts and available actions Available actions Spam, Suspected Spam, Blocked sender, Company-specific content Mass-mailing worm Virus Unscannable Deliver the message normally Delete the message Save the message to disk Modify the message Deliver the message normally Delete the message Deliver the message normally Delete the message Clean and then deliver the message Deliver the message normally Delete the message Save the message to disk Modify the message Creating group policies You can specify the groups of users that are based on addresses or domain names. For each group, you can specify filtering actions for different types of violations. To create a new group policy, do all of the following: Create a name for the policy. Add the members for which the policy applies. For each type of violation, specify the actions to be taken if the policy is violated. After you create the policy, you must enable it for it to take effect. To create a group policy 1. Use a text editor to open the bmiconfig.xml file. 2. Copy the tags in <filtering_policies>, <policy>, <disposition>, <mailflow> and so on, and replace "default" with the custom policy name. 3. Save and close the bmiconfig.xml file.

166 Using group policies Working with group policies 166 To add a new member to this group policy 1. Use a text editor to open the bmiconfig.xml file. 2. Inside the population tag of the group policy, type valid addresses or domain names. Separate multiple entries with commas. Use * to match zero or more characters and? to match a single character. To add all recipients of a particular domain as members, type the following: *@domain.com 3. Save and close the bmiconfig.xml file. To enable a group policy 1. Use a text editor to open the bmiconfig.xml file. 2. To enable a group policy, make the following change in the file: <policy default="false" name="policy_custom" precedence="100" enabled="true"> 3. Save and close the bmiconfig.xml file. Working with group policies You can do the following tasks with group policies: Edit an existing group policy. You might want to change an existing policy to modify how you want to handle a violation, change how a subject line is appended, or how an X-header is labeled. Disable a group policy. You may want to disable a group policy periodically. When you disable a group policy, the policy still exists but is not active. When Messaging Gateway for Service Providers scans a message, it does not filter against the policies that are disabled. The ability to disable a policy lets you create the policies that you can enable periodically, as needed. It also lets you troubleshoot policy issues. Delete a group policy member. You can delete a member of a group policy if the member is no longer with the organization or if the policy no longer applies to that member. Delete a group policy. You can delete a group policy that you no longer need.

167 Using group policies Working with group policies 167 To edit an existing group policy You can edit an existing group policy Using the policyconfig tool, you can edit an existing group policy to change the destination and the precedence of a disposition. See Changing the destination string of an existing disposition on page 129. See Changing the order of message scanning on page 130. To disable a group policy 1. Use a text editor to open the bmiconfig.xml file. 2. To disable a group policy, make the following change in the config file: <policy default="false" name="policy_custom" precedence="100" enabled="false"> 3. Save and close the bmiconfig.xml file. To delete a group policy member 1. Use a text editor to open the bmiconfig.xml file. 2. To delete a member, delete the member from the <member> tag in the <population> tag of the policy. 3. Save and close the bmiconfig.xml file. To delete a group policy 1. Use a text editor to open the bmiconfig.xml file. 2. Locate the tags in <filtering_policies>, <policy>, <disposition>, <mailflow> and so on, and delete the custom policy name from the tag. 3. Save and close the bmiconfig.xml file.

168 Chapter 9 Filtering spam This chapter includes the following topics: About unwanted messages Enabling or disabling Messaging Gateway for Service Providers to filter unwanted messages About submitting messages for customer-specific spam rules About unwanted messages Messaging Gateway for Service Providers provides a set of default spam and unwanted policies. For a new install, the unwanted policies are not assigned to any group. For a new installation or an upgrade from a previous release, the unwanted policies are disabled and not assigned to any group. You can modify the actions in these policies or create your own policies. Table 9-1 describes the categories of unwanted s. Table 9-1 Unwanted category Marketing mail Newsletter Unwanted categories Description messages that contain commercial or fund-raising messages, that may have been requested by the user. These messages often do not include a functional opt-out facility. messages that include content on specific topics, on a known periodic basis, often weekly or monthly. The user may have requested to receive these publications. A functional opt-out facility is generally available.

169 Filtering spam Enabling or disabling Messaging Gateway for Service Providers to filter unwanted messages 169 Table 9-1 Unwanted category Suspicious URL Unwanted categories (continued) Description Suspicious URLs include free hosting sites, URL shortening services, and URL redirecting services which can potentially be abused to deliver spam or malware payloads. Messaging Gateway for Service Providers can filter against messages that contain one or more suspicious URLs. Note: Filtering for unwanted s can result in legitimate messages being filtered. Symantec recommends starting with an action such as subject line annotation. Enabling or disabling Messaging Gateway for Service Providers to filter unwanted messages Messaging Gateway for Service Providers can be enabled or disabled to filter unwanted messages. Following are the unwanted message categories with their corresponding XML tags in the bmiconfig.xml file: Unwanted message category Marketing mail Newsletter Suspicious URL XML tag in bmiconfig.xml <disp name="bulk" enabled="false"/> <disp name="newsletter" enabled="false"/> <disp name="suspicious_url" enabled="false"/> These unwanted message categories are available in the following spam filtering modules: bodyhashmodule intsigmodule statsigmodule spamsigmodule regexmodule spamhuntermodule You must manually enable the unwanted message category that you want to filter after you install and configure Messaging Gateway for Service Providers.

170 Filtering spam Enabling or disabling Messaging Gateway for Service Providers to filter unwanted messages 170 To enable Messaging Gateway for Service Providers to filter unwanted messages 1 Open bmiconfig.xml in a text editor. 2 Determine the unwanted message category that you want to enable. For example: you may only want to enable the newsletter category. 3 Enable the unwanted message category that you want to filter as follows: <disp name="unwanted message category" enabled="true"/> For example: <disp name="newsletter" enabled="true"/> 4 Locate the corresponding ruleset. 5 Enable the ruleset that you located in step 4 as follows: <url rulename="unwanted message category" defaultdisposition="unwanted message category" displayname="heuristic and URL Marketing Mail Rules" enabled="true"> For example: <url rulename="newsletter" defaultdisposition="newsletter" displayname="heuristic and URL Marketing Mail Rules" enabled="true"> 6 Ensure that you perform step 3 to step 5 in the following spam filtering modules: bodyhashmodule intsigmodule statsigmodule spamsigmodule regexmodule spamhuntermodule

171 Filtering spam Enabling or disabling Messaging Gateway for Service Providers to filter unwanted messages Save the file and exit. 8 To apply bmiconfig.xml settings, either restart the appropriate server or kick the server. For example: On Windows systems, type the following command: <path>\scanner\bin\kicker.exe -s BMISERVERSVC On UNIX systems, type the following command: <path>/scanner/bin/kicker <path>/scanner/etc/bmiconfig.xml <path>/scanner/jobs/bmserver/bmserver.pid To disable Messaging Gateway for Service Providers for filtering unwanted messages 1 Open bmiconfig.xml in a text editor. 2 Determine the unwanted message category that you want to disable. For example: you may only want to disable the newsletter category. 3 Disable the unwanted message category that you want to filter as follows: <disp name="<unwanted message category>" enabled="false"/> For example: <disp name="newsletter" enabled="false"/> 4 Locate the corresponding ruleset. 5 Disable the ruleset that you located in step 4 as follows: <url rulename="<unwanted message category>" defaultdisposition="<unwanted message category>" displayname="heuristic and URL Marketing Mail Rules" enabled="false"> For example: <url rulename="newsletter" defaultdisposition="newsletter" displayname="heuristic and URL Marketing Mail Rules" enabled="false"> 6 Ensure that you perform step 3 to step 5 in the following spam filtering modules: bodyhashmodule intsigmodule statsigmodule

172 Filtering spam About submitting messages for customer-specific spam rules 172 spamsigmodule regexmodule spamhuntermodule 7 Save the file and exit. 8 To apply bmiconfig.xml settings, either restart the appropriate server or kick the server. For example: On Windows systems, type the following command: path\scanner\bin\kicker.exe -s BMISERVERSVC On UNIX systems, type the following command: path/scanner/bin/kicker path/scanner/etc/bmiconfig.xml path/scanner/jobs/bmserver/bmserver.pid See About unwanted messages on page 168. About submitting messages for customer-specific spam rules You can obtain custom spam rules specifically for your organization based on the missed spam messages and the messages that incorrectly appear as spam. The administrators and the end users can submit these messages to Symantec by using the subm-config command. This feature provides the following benefits: It improves Messaging Gateway for Service Providers's ability to detect spam and helps administrators control false positive incidents. It makes it easier to submit missed spam messages or false positive messages to Symantec for analysis and ruleset creation. When you configure this feature, administrators and end users can submit messages to Symantec as missed spam or false positives. Within minutes, Symantec creates a custom ruleset. The conduit obtains the ruleset, which is then applied to each configured Scanner. If you want to use the customer-specific spam submission feature, you must obtain a submitter ID. The submitter ID ensures that custom rules are available only to those Scanners that requested the submitter ID. Messaging Gateway for Service Providers lets you specify who can submit messages for custom rules. Alternatively, you can specify who cannot submit messages.

173 Filtering spam About submitting messages for customer-specific spam rules 173 Restricted users' messages are submitted, but their messages are not considered for custom rules. There may be an instance in which you want to disable this feature and remove all of the customer spam submission data. You might want to delete all of the existing rules and create new ones. Messaging Gateway for Service Providers lets you delete all customer spam submission data. This data includes the submitter ID, all related rules, addresses in the submitters list, reporting information, and so on. Once this data is deleted, it cannot be retrieved or restored. Symantec considers all messages that are submitted as Spam or NOT Spam for global rules regardless of whether the customer-specific spam submission feature is enabled. By default, the customer-spam submissions feature is disabled. When you enable this feature, all of the messages that are submitted are considered for customer-specific rule generation. In addition, false positives can result in the elimination of a rule. If you disable the feature, messages that are submitted are still considered for customer-specific rule generation or rule elimination. Symantec continues to create new rules, but the new rules are not deployed. Customer-specific spam filtering policies are restricted to apply these rules against mail flow. If you enable the feature again, the rules that Symantec delivers change from the previous state when the feature was initially disabled. Customer-specific spam filtering policies are enabled, and these policies apply the latest customer-specific rules. If you delete all submission data, all of the messages that are submitted are considered only for global rule generation or rule elimination. BodyHash rules are highly accurate because they target the precise fingerprints of an message. BodyHash rules are particularly effective in combating the short messages and repeated messages that spammers and other attackers use. BrightSig3 rules adapt to spammer attempts to randomize and obfuscate malicious . These rules target the messages that have statistical similarity with a sample message. They are particularly effective combating spam attacks where there is significant similarity between messages. These rules employ fuzzy logic algorithms to defeat the spammer who attempts to use obfuscation and variation techniques to evade more traditional signatures. The combination of BodyHash and BrightSig3 rules provide a highly effective shield against attackers who use short messages or attacks where spammers use various attack obfuscation techniques. These technologies represent two of over 20 different technologies that Symantec uses to secure the global threat vector. Users of the customer-specific spam rules have the supplemental protection of additional BodyHash and BrightSig3 rules. Together, these rules are targeted specifically to the threats that individual organizations typically see.

174 Filtering spam About submitting messages for customer-specific spam rules 174 About the process that Symantec follows to create customer-specific spam rules Symantec goes through the following process to determine whether it should create a ruleset based on the messages that are submitted: 1. Verifies that the customer-specific spam submission feature is enabled. 2. Verifies that the message is originated from a valid source. 3. Verifies that the person who submitted the message is either in the Allowed list or is not in the Blocked list. 4. Determines whether the message itself is valid. Symantec may consider messages to be invalid and not use them for a custom ruleset in the following cases: Any message that is not RFC5322-compliant is considered invalid. Note: Outlook messages that are saved as.msg files are not RFC compliant and are not considered valid submissions. For more information about RFC5322 requirements, on the Internet, go to the following URL: Sometimes a message is modified in transit and loses its fidelity by the time it reaches Symantec. Messages that lose their fidelity cannot be used for custom rules. Loss of fidelity can occur for a variety of reasons. 5. Determines whether a global rule already exists. Symantec may create a custom rule even if a global rule already exists as a safeguard in case a global rule is deleted or disabled. 6. Determines whether the aggressiveness level is met. If the aggressiveness level is conservative, multiple users must submit the same message before the message is considered for a rule. 7. If all of the preceding conditions are met, if a spam message is submitted, Symantec creates a new rule. If a false positive message is submitted, no new rule is created, and Symantec might delete the custom rule that resulted in the false positive.

175 Filtering spam About submitting messages for customer-specific spam rules 175 Setting up customer-specific spam submissions Table 9-2 describes the process that you must follow to set up the customer-specific spam submission feature. Table 9-2 Process to set up the customer-specific spam submission feature Step Step 1 Task Enable the customer-specific spam submission feature. Description You must enable this feature for Symantec to create custom rules. This feature is disabled by default. Step 2 Either obtain a submitter ID or specify an existing submitter ID. The submitter ID ensures that the custom ruleset is available only to those Scanners that request the submitter ID. Step 3 Specify the submission aggressiveness level. You can specify whether you want all messages that are submitted to be considered for a custom rule. You can also specify whether a message must be submitted multiple times from different users before it should be considered for a custom rule. Step 4 Specify who may or may not submit messages for custom rules. Messaging Gateway for Service Providers lets you specify who can submit messages for custom rules. Alternatively, you can specify who cannot submit messages. Step 5 Enable the policies that use customer-specific rules. You must enable customer-specific policies for the customer-specific rules to be applied to incoming messages. Enabling or disabling customer-specific spam submissions Enable the customer-specific spam submissions feature to obtain customer-specific spam rules based on the messages that administrators and end users identify as missed spam or messages that are incorrectly identified as spam. Messages are still submitted to Symantec even when this feature is disabled; however, no custom rules are created. After you enable the feature, ensure that you complete the remainder of the steps that are required to fully set up this feature.

176 Filtering spam About submitting messages for customer-specific spam rules 176 If you no longer want to leverage customer-specific rules in your environment, you can disable this feature. You may also want to delete all of the related rules and data. To enable customer-specific spam submissions On the command line, type the following command: subm-config provisioning -enable -c <path>/bmiconfig.xml For example: subm-config provisioning -enable -c bmiconfig.xml After enabling customer-specific spam submissions, you must provision your submitter ID. To disable customer-specific spam submissions On the command line, type the following command: subm-config provisioning -disable -c <path>/bmiconfig.xml For example: subm-config provisioning -disable -c bmiconfig.xml Provisioning the submitter ID for customer-specific spam submissions Symantec requires that each Scanner that submits messages for custom rules has a submitter ID. Symantec creates custom rules based on the messages that are submitted from the Scanner with that ID. Those rules are then applied to any Scanners that the submitter ID manages. You can have a unique submitter ID for each Scanner or you can share submitter IDs among multiple Scanners. Scanners that share submitter IDs also share the same custom rules. Table 9-3 provides guidance as to whether Scanners should use unique submitter IDs or share submitter IDs. Table 9-3 Scenario A single Scanner Submitter ID usage recommendations Recommendation Obtain and use a unique submitter ID. (Typical configuration)

177 Filtering spam About submitting messages for customer-specific spam rules 177 Table 9-3 Scenario Submitter ID usage recommendations (continued) Recommendation Multiple Scanners in which you want to share rules (Typical configuration) Assume that you have two Scanners. You want both Scanners to use the same custom rules regardless of which Scanner submits the spam messages for ruleset creation. Obtain a unique submitter ID for one of the Scanners and apply that submitter ID to the remaining Scanners. Symantec creates rules based on all of the messages that are submitted from any of the Scanners. It applies the same rules across all the Scanners. Note: Currently subm-data.txt files are not created on any scanner but the first one provisioned when the same submitter ID is used across multiple scanners. You must copy the subm-data.txt file manually from the first scanner (after it is provisioned) to the rest of the scanners in the configuration. Multiple Scanners in which you want to have unique rules (Advanced configuration) Assume that you have two Scanners. One Scanner has a much different configuration and use than the other Scanner. So you want each Scanner to submit its own messages for their own custom rules. Obtain unique submitter IDs for each Scanner. Each Scanner receives its own custom ruleset based on the spam messages that are submitted from that Scanner. Note that the submitter ID is reported back to the administrator upon creation: subm-config provisioning -configure -c<path>/bmiconfig.xml Do you want to Provision the Submitter ID [y/n]: y New Submitter ID: c435e27c Administrators should make note of the submitter ID at this point so that it can be easily retrieved later. When you delete customer-specific spam data, you also delete the submitter ID. The submitter ID is also lost when you uninstall or reinstall the Scanner. To retain the submitter ID, ensure that you back up the bmiconfig.xml file before you uninstall or reinstall the Scanner. You must also have a valid production license to obtain a new submitter ID. Trial licenses are invalid. To provision a new submitter ID for customer-specific spam submissions In the command line, type the following command:

178 Filtering spam About submitting messages for customer-specific spam rules 178 subm-config provisioning -configure -c <path>/bmiconfig.xml For example: subm-config provisioning -configure -c bmiconfig.xml See subm-config provisioning on page 228. To specify an existing submitter ID for customer-specific spam submissions 1 On the command line, type the following command: subm-config provisioning -configure -id submitter-id -c <path>/bmiconfig.xml For example: subm-config provisioning -configure -id "84d9d39d" -c bmiconfig.xml 2 Repeat this procedure for each Scanner that you want to share custom rules. See subm-config provisioning on page 228. Checking and setting the customer-specific spam submission aggressiveness level Messaging Gateway for Service Providers creates custom rules based on the messages that administrators and end users submit. By default, Symantec only creates rules for the messages that administrators submit. Additionally, you can configure Messaging Gateway for Service Providers to create rules for the messages that end users submit. The default setting for end user submissions better ensures that you do not obtain any rules that are based on accidental submissions or erroneous ones. However, you can specify that all messages that end users submit are used to create custom rules. The aggressiveness levels are as follows: Conservative - Only messages with multiple submissions get rules Multiple end users must submit the same message before Symantec considers it for a new rule. Aggressive - Every submission gets a rule Instances in which some of the messages that are submitted do not result in a new ruleset. The default setting is Conservative.

179 Filtering spam About submitting messages for customer-specific spam rules 179 To check the customer-specific spam submission aggressiveness level In the command line, type the following command: subm-config submissionpolicy -get -c <path>/bmiconfig.xml For example: subm-config submissionpolicy -get -c bmiconfig.xml To set the customer-specific spam submission aggressiveness level In the command line, type the following command: subm-config submissionpolicy -configure conservative aggressive -c <path>/bmiconfig.xml For example: subm-config submissionpolicy -configure conservative -c bmiconfig.xml See subm-config submissionpolicy on page 240. Specifying and viewing who can submit messages for customer-specific rules Messaging Gateway for Service Providers lets you specify who can submit messages for custom rules. Alternatively, you can specify who cannot submit messages for custom rules. Blocked users' messages are submitted, but their messages are not considered for ruleset creation. Note: Wildcards are unsupported, and you must enter a valid address. You can have a maximum of 1,000 addresses in the file list. Messaging Gateway for Service Providers validates your entries to ensure that you use a valid address and that you do not have duplicate entries. The description to specify who can submit messages for customer-specific rules is as follows: allowedlist blockedlist Only the addresses that you specify can submit spam messages to Symantec. Everyone except the addresses that you specify can submit spam messages to Symantec.

180 Filtering spam About submitting messages for customer-specific spam rules 180 To specify who can submit messages for customer-specific rules In the command line, type the following command: subm-config {allowedlist blockedlist} -update [ addresses(s)] -c <path>/bmiconfig.xml For example: subm-config allowedlist -update -c bmiconfig.xml To provide addresses in a text file subm-data.txt, type the following command: subm-config blockedlist -update -f subm-data.txt -c bmiconfig.xml To view who can submit messages for customer-specific rules In the command line, type the following command: subm-config displaylist -c bmiconfig.xml See subm-config on page 218. See subm-config displaylist on page 225. Submitting spam messages through the command line for customer-specific rules Messaging Gateway for Service Providers lets you submit spam messages directly from the command line. Messages that you submit through the command line must contain both the headers and bodies and must be valid RFC5322 messages. Note: Outlook messages that are saved as.msg files are not RFC compliant and are not considered valid submissions. Submissions from administrators receive higher consideration for the creation of rules than those submitted by end users. To submit spam messages through the command line for customer-specific rules In the command line, type the following command: subm-config submitspam -f file1, [file2.. filen] -c <path>/bmiconfig.xml For example:

181 Filtering spam About submitting messages for customer-specific spam rules 181 subm-config submitspam -f abc.msg -c bmiconfig.xml The following message is displayed on the console: Submitting file: abc.msg Submitted: abc.msg See subm-config submitspam on page 236. Submitting messages that are incorrectly marked as spam through the command line for customer-specific rules Messaging Gateway for Service Providers lets you submit messages that are falsely identified as spam. After you submit the messages that are not spam, Symantec modifies the custom rules to identify the messages that are submitted as legitimate s. To submit messages that are incorrectly marked as spam through the command line for customer-specific rules In the command line, type the following command: subm-config submitnotspam -f file1, [file2.. filen] -c <path>/bmiconfig.xml For example: subm-config submitnotspam -f abc.msg -c bmiconfig.xml The output for this command is displayed as follows: Submitting file: Submitted: abc.msg abc.msg See subm-config submitnotspam on page 238. Deleting customer-specific spam data Messaging Gateway for Service Providers retains data about the messages that administrators and end users submit for ruleset creation along with the accompanying rules. You may want to delete customer-specific spam data to remove previous rules and create new rules. If you no longer want to leverage customer-specific rules in your environment, you can permanently delete all of customer-specific spam data. Afterwards, you should also disable the customer-specific spam submission feature. When you delete customer-specific spam data, you delete all of the following:

182 Filtering spam About submitting messages for customer-specific spam rules 182 All of the data that was submitted for the creation of rules All of the rules that Symantec created based on that data Data that is used in spam submission reports The submitter ID All of the addresses in subm-data.txt Warning: Once you delete the customer-specific spam data, it cannot be retrieved. In addition, the aggressiveness option returns to the default setting, and Messaging Gateway for Service Providers no longer takes the actions that you specify for the spam policy condition. To delete customer-specific spam data In the command line, type the following command: subm-config provisioning -delete -c <path>/bmiconfig.xml For example: subm-config provisioning -delete -c bmiconfig.xml The output for this command is displayed as follows: Warning: Deleting provisioning will delete all spam submission data from the scanner and the Symantec server. Are you sure you want to delete provisioning [y/n]?: Generating customer-specific spam submission report Messaging Gateway for Service Providers enables you to generate customer-specific spam submission reports in the XML format. You can generate either a summary report or a detailed report.

183 Filtering spam About submitting messages for customer-specific spam rules 183 To generate customer-specific spam submission report 1 Select one of the sample XML files that were created in the $loadpoint/etc directory as part of the product installation (sample_daily_detail.xml, sample_daily_summary.xml, sample_monthly_summary.xml, or sample_top5_summary.xml) to specify the type of information that you want to retrieve. 2 Based on your requirements, run either of the following commands: subm-config report {--detail --summary} -f <path>/sample_daily_detail.xml -c <path>/bmiconfig.xml For example: subm-config report --detail -f sample_daily_detail.xml -c bmiconfig.xml subm-config report --summary -f sample_daily_detail.xml -c bmiconfig.xml See subm-config report on page 231. See Spam submission XML inputs and description on page 242. See Sample XML file to provide inputs for customer-specific spam report generation on page 244.

184 Chapter 10 Using filters to protect your environment and block unwanted mail This chapter includes the following topics: About Messaging Gateway for Service Providers filters About specifying senders to permit or block How Messaging Gateway for Service Providers identifies senders and connections About the Allowed Senders List and the Blocked Senders List Use case scenarios to allow or block senders Adding senders to the Blocked Senders List Adding senders to the Allowed Senders List Deleting senders from the senders list Editing senders in the senders list Enabling or disabling senders from the senders list Importing sender information into a senders list Selecting reputation services to use About filtering for spam Adjusting spam scoring

185 Using filters to protect your environment and block unwanted mail About Messaging Gateway for Service Providers filters 185 Rejecting spam at the gateway Scanning text attachments Increasing the speed for processing messages About filtering for viruses Configuring antivirus filter settings About Messaging Gateway for Service Providers filters Most customers find that the filters that Symantec provides handle all their needs. If you want to supplement Symantec filtering, you can customize filtering at your site. For example, you can set up lists of allowed and blocked senders, adjust the criteria for suspected spam messages, and more. Policies control the corresponding actions for the filters that you create and modify in this section. Messaging Gateway for Service Providers provides the following filters, all of which you can customize: Blocking and permitting senders (Allowed Senders Lists, Blocked Senders Lists, and Reputation Lists) Spam filtering Antivirus filtering About specifying senders to permit or block Filtering based on the source of the message, whether it is the sender's domain, address or mail server IP connection, can be a powerful way to fine-tune mail processing at your site. The information in this section describes global blocked and allowed senders lists, which are applied at the server level. Messaging Gateway for Service Providers provides the following tools to let you specify which senders to permit and which senders to block:

186 Using filters to protect your environment and block unwanted mail About specifying senders to permit or block 186 Define an Allowed Senders List. Messaging Gateway for Service Providers treats the that comes from an address or connection in the Allowed Senders List as legitimate mail. As a result, you ensure that such mail is delivered immediately to the inbox and bypasses any other filtering. The Allowed Senders List reduces the small risk that the messages that are sent from trusted senders are treated as spam or filtered in any way. See Adding senders to the Allowed Senders List on page 191. Define a Blocked Senders List. Messaging Gateway for Service Providers supports a number of actions for mail from a sender or connection on your Blocked Senders List. As with spam verdicts, you can use policies to configure a variety of actions to perform on such mail. For example, actions include deletion, forwarding, and subject line modification. Use the Reputation Service. See Adding senders to the Blocked Senders List on page 190. By default, Messaging Gateway for Service Providers is configured to use the Reputation Service. Symantec monitors hundreds of thousands of sources to determine how much that is sent from these addresses is legitimate and how much is spam. The service currently includes the following lists of IP addresses, which are continuously compiled, updated, and incorporated into the Messaging Gateway for Service Providers filtering processes: Open Proxy List IP addresses that are open proxies that spammers use. Safe List IP addresses from which almost no outgoing is spam. Incorporate lists managed by other parties. No configuration is required for these lists. You can choose to disable the Open Proxy List and the Safe List. See Selecting reputation services to use on page 195. Third parties compile and manage lists of desirable or undesirable IP addresses. These lists are queried with DNS lookups. When you configure Messaging Gateway for Service Providers to use a third-party sender list, Messaging Gateway for Service Providers checks whether the sending mail server is on the list. If so, Messaging Gateway for Service Providers performs a configured action according to the policies in place. See Importing sender information into a senders list on page 193.

187 Using filters to protect your environment and block unwanted mail How Messaging Gateway for Service Providers identifies senders and connections 187 How Messaging Gateway for Service Providers identifies senders and connections Messaging Gateway for Service Providers uses the following methods to identify senders and connections: Supported methods for identifying senders You can use the following methods to identify senders for your Allowed Senders List and Blocked Senders List: Specify sender addresses or domain names. Messaging Gateway for Service Providers checks the following characteristics of inbound mail against those in your lists: MAIL FROM Address in the SMTP envelope. Specify a pattern that matches the value for localpart@domain in the address. You can use wildcards in the pattern to match any portion of the address. FROM Address in the message headers. Specify a pattern that matches the value for localpart@domain in the From header. You can use wildcards in the pattern to match any portion of this value. Specify IP connections. Messaging Gateway for Service Providers checks the IP address of the mail server that initiates the connection to verify if it is on your Allowed Senders Lists or Blocked Senders Lists. Wildcards are not supported. Although you can use network masks to indicate a range of addresses, you cannot use the subnet masks that define non-contiguous sets of IP addresses (for example, / ). Supported notations are as follows: Single host: IP address with subnet mask: / Supply the lookup domain of a third-party sender service. Messaging Gateway for Service Providers can check message sources against third-party DNS-based lists to which you subscribe. Automatic expansion of subdomains When Messaging Gateway for Service Providers evaluates domain name matches, it expands the specified domain to include subdomains. For example, Messaging Gateway for Service Providers expands symantecexample.com to include biz.symantecexample.com and, more generally, *@*.symantecexample.com. This evaluation ensures that any possible subdomains are allowed or blocked as appropriate.

188 Using filters to protect your environment and block unwanted mail About the Allowed Senders List and the Blocked Senders List 188 Logical connections and internal mail servers: non-gateway deployments When you deploy Messaging Gateway for Service Providers at the gateway, it can reliably obtain the physical or peer IP connection for an inbound message. It can then compare the connection to the connections that are specified in the Allowed Senders List and Blocked Senders List. If you deploy the product elsewhere in your network (for example, downstream from the gateway MTA), Messaging Gateway for Service Providers works with the logical IP connection. Messaging Gateway for Service Providers obtains the address that is provided when the message entered your network. Your network is based on the internal address ranges that you supply to Messaging Gateway for Service Providers when you setup your Scanners. Therefore, it is important that you identify all the internal mail hosts in your network. See Specifying internal mail hosts on page 208. About the Allowed Senders List and the Blocked Senders List Note the following considerations about the Allowed Senders List and Blocked Senders List: Overall filtering precedence Messaging Gateway for Service Providers keeps track of the different filters that trigger a violation to determine an overall verdict for a message. Preset precedence rules govern the ultimate verdict. For example, Messaging Gateway for Service Providers gives a higher precedence to matches against the Allowed Senders Lists and Blocked Senders Lists.

189 Using filters to protect your environment and block unwanted mail About the Allowed Senders List and the Blocked Senders List 189 Precedence within the multiple lists If a message source falls into both the Allowed Senders List and the Blocked Senders List, the Allowed Senders List has precedence. The message is delivered to the recipient's inbox. Within the lists, IP addresses are generally more reliable for source filtering than addresses, which are easily forged. In addition, lists that you create or ( -based and IP-based) have precedence over the lists that Symantec creates. Note that list information from third-party DNS blacklists that you specify does not have priority over Symantec lists. In the event of a conflict between the Safe List (part of the Reputation Service) and an entry from a DNS blacklist, the Symantec-propagated list takes precedence. The following list summarizes the precedence: Allowed Senders List (IP addresses) Allowed Senders List (third-party allowed senders services) Blocked Senders List (IP addresses) Allowed Senders List ( addresses) Blocked Senders List ( addresses) Safe List Open Proxy List Blocked Senders List (third-party blocked senders services) Duplicate entries Performance impact of third-party DNS lists Use Allowed Senders Lists for external IP addresses only You cannot have the exact same entry in both the Blocked Senders List and the Allowed Senders List. The entry may not appear in the list that you work with. To move from one list to the other, delete it from the first and add it to the second. If you have two entries such as [email protected] and *@b.com in the two different lists, the precedence in the previous bullet wins. Incorporating third-party lists adds additional steps to the filtering process. For example, in a DNS list scenario, for each incoming message, the IP address of the sending mail server is queried against the list, similar to a DNS query. If the sending mail server is on the list, the mail is flagged as spam. If your mail volume is high and you run inbound mail through a third-party database, you could hamper performance because of the requisite DNS lookups. Symantec recommends that you use the Reputation Service instead of enabling third-party lists. Messaging Gateway for Service Providers has default internal IP address ranges from which it ignores IP address data. The benefit is that your Scanner saves time and resources by not scanning messages from these trusted locations. Therefore, you need only use the Allowed Senders list for external IP addresses.

190 Using filters to protect your environment and block unwanted mail Use case scenarios to allow or block senders 190 Use case scenarios to allow or block senders Table 10-1 provides some examples of why you would employ lists of allowed or blocked senders along with an example of a pattern that you might use to match the sender. Table 10-1 Use cases for using Allowed Senders Lists and Blocked Senders Lists Problem Solution Pattern example Mail from an end user's colleague is occasionally flagged as spam. Add the colleague's address to the Allowed Senders List. [email protected] A newsletter that is wanted is flagged as spam. An individual sends unwanted mail to people in your organization. Numerous people from a specific range of IP addresses send unsolicited mail to people in your organization. Add the domain name that the newsletter uses to the Allowed Senders List. Add the specific address to the Blocked Senders List. After analyzing the received headers to determine the sender's network and IP address, add the IP address and netmask to the Blocked Senders List. newsletter.com Joe.doe*@symantecexample.com / Adding senders to the Blocked Senders List To prevent unwanted messages from being delivered, you can add specific addresses, domains, and connections to your Blocked Senders List. To add senders to the Blocked Senders List 1 Open the allowedblockedlist.txt file with a text editor. 2 Add the addresses, domains, or connections that you want to block. For example: RS: [email protected] RS: symantecexample.com

191 Using filters to protect your environment and block unwanted mail Adding senders to the Allowed Senders List 191 You can add multiple addresses from an existing blocked senders list. Import this list by running the policyconfig tool. To add multiple addresses to the Blocked Senders List 1 On the command line, type the following command: #policyconfig -i <path>/bmiconfig.xml -o <path>/bmiconfig.xml -s <path>/bmiconfig.xsd 2 Type 3 to select Import file to allowedblockedlist. 3 Enter the location of the file to be imported to the allowedblockedlist. For example: For Linux or Solaris systems: /root/allowedblockedlist.txt For Windows systems: D:\allowedblockedlist.txt for Windows The addresses that you import are appended to the allowedblockedlist.txt file. Adding senders to the Allowed Senders List To ensure that messages from specific addresses, domains, and connections are not treated as spam, you can add them to your Allowed Senders List. To add senders to the Allowed Senders List 1 Open the allowedblockedlist.txt file with a text editor. 2 Add the addresses, domains, or connections to ensure that messages from specific sources are not treated as spam. For example: AS: [email protected] AS: symantecexample.com 3 Save the file and exit. Deleting senders from the senders list You can remove senders from the senders list by manually editing the bmiconfig.xml file.

192 Using filters to protect your environment and block unwanted mail Editing senders in the senders list 192 To delete senders from the senders lists 1 Open the bmiconfig.xml file with a file editor. 2 Delete the addresses, domains, or connections that you want to remove from the senders list. Editing senders in the senders list You can edit senders from the senders list by manually editing the bmiconfig.xml file. To edit senders in the senders list 1 Open the bmiconfig.xml file with a file editor 2 Edit the addresses, domains, or connections that you want to edit from the senders list. Enabling or disabling senders from the senders list When you add a new sender to your Blocked Senders List or Allowed Senders List, Messaging Gateway for Service Providers automatically enables the filter when it scans inbound messages. You may need to periodically disable and then turn on senders from your list for troubleshooting or testing purposes or if your list is not up-to-date. Messaging Gateway for Service Providers treats an from a sender that you disabled as it would any other message. You can enable or disable senders from the senders list by manually editing the bmiconfig.xml file. To enable or disable senders from the senders list 1 Open the bmiconfig.xml file with a file editor. 2 Modify the addresses, domains, or connections that you want to enable or disable from the senders list. For example: AS: [email protected]: + RS: [email protected]: - A PLUS sign indicates that the entry is currently enabled. A MINUS sign indicates that the entry is currently disabled.

193 Using filters to protect your environment and block unwanted mail Importing sender information into a senders list 193 Importing sender information into a senders list To add sender information, patterns, and DNS zones, you need to modify a text file (allowedblockedlist.txt) that is provided with your Messaging Gateway for Service Providers software. The file is line-oriented and uses a format similar to Lightweight Directory Interchange Format (LDIF). It has the following restrictions and characteristics: The file must have the required LDIF header that is included upon installation. Each line contains exactly one attribute, along with a corresponding pattern. Empty lines or white spaces are not supported. Lines beginning with # are ignored. Entries terminating with the colon-dash pattern (:-) are disabled; entries terminating with the colon-plus pattern (:+) are enabled To populate the list, specify an attribute and follow it with a pattern. In the following example, a list of attributes and patterns follows the LDIF header. ## Permit List # dn: [email protected], ou=bmi objectclass: top objectclass: bmiblackwhitelist AC: / AS: [email protected] RC: / RS: [email protected] BL: spl.spamhaus.org # Example notations for disabled and enabled entries follow RS: [email protected]:- RS: [email protected]:+ AC: 2001:DB8::8:800:200C:417A:+ RC: 2001:DB7::1/64:+ Table 10-2 lists the attributes and the syntax to specify allowed and blocked senders.

194 Using filters to protect your environment and block unwanted mail Importing sender information into a senders list 194 Table 10-2 Syntax to prepare list to specify allowed and blocked senders Attribute Meaning Acceptable values Example AC: RC: Allowed connection or network Rejected or blocked connection/network Numerical IPv4 or IPv6 address, and network mask of host to allow or block using the format a.b.c.d/e.f.g.h. Classless Inter-Domain Routing (CIDR) ranges of contiguous IP addresses for allowed or blocked networks. Wildcards are not supported. Single IPv4 address: AC: / AC: Class C network: RC: / CIDR notation of above network: RC: /24 Single IPv6 address: AC: 2001:DB8::8:800:200C:417A:+ RC: 2001:DB7::1/64:+ AS: RS: Allowed sender Rejected or blocked sender All alphanumerics and special characters, except the plus sign (+). Use * to match multiple characters and? to match a single character. Single sender address: RS: [email protected] Fixed size noisy address: RS: [email protected] BL: WL: Third party blocked sender server Third party allowed sender service Numerical IPv4 or IPv6 address, or canonical name of a third-party whitelist or blacklist service. Wildcards are not supported. BL: spl. spamhaus.org To import sender information into a senders list 1 On the command-line, type the following command: policyconfig -i <path>/bmiconfig.xml -s <path>/bmiconfig.xsd On UNIX systems, sbin/policyconfig -i etc/bmiconfig.xml -s etc/bmiconfig.xsd On Windows system, policyconfig -i config/bmiconfig.xml -s etc/bmiconfig.xsd 2 Type 3 to select Import file to allowedblockedlist. 3 Type the name of the file to import. 4 When the message Do you want to go back appears, select No by typing 2. 5 When the message Do you want to save the changes appears, select Yes by typing 1.

195 Using filters to protect your environment and block unwanted mail Selecting reputation services to use 195 Selecting reputation services to use The reputation service is a service that Symantec manages which continuously compiles and updates the following lists of IP addresses: Open Proxy List Safe List IP addresses that are open proxies used by spammers. IP addresses from which almost no outgoing is spam. Symantec monitors hundreds of thousands of sources to determine how much that is sent from these addresses is legitimate and how much is spam. from given sources can then be blocked or allowed based on the source's reputation value as Symantec determines. By default, all of the reputation services are enabled. About filtering for spam Spam is unsolicited bulk , most often advertising messages for a product or service. It wastes productivity, time, and network bandwidth. You can define which messages are spam, suspected spam, or not spam based on the scores that Messaging Gateway for Service Providers assigns to messages. You can also configure how to dispose of spam and suspected spam messages. See Adjusting spam scoring on page 195. You can enable a feature to scan certain message text attachments. Messaging Gateway for Service Providers can search these text attachments for URLs, which may be an indicator that a message is spam. See Rejecting spam at the gateway on page 196. If you deploy Messaging Gateway for Service Providers at the gateway, you can save scanning resources by blocking spam at the gateway. See Rejecting spam at the gateway on page 196. Messaging Gateway for Service Providers also provides the Fastpass feature to improve performance. See Increasing the speed for processing messages on page 198. Adjusting spam scoring When Messaging Gateway for Service Providers evaluates whether messages are spam, it calculates a spam score from 1 to 100 for each message according to

196 Using filters to protect your environment and block unwanted mail Rejecting spam at the gateway 196 techniques such as pattern matching and heuristic analysis. An is defined as spam if it receives a score in the range of 90 to 100. For more aggressive filtering, you can optionally define a discrete range of scores The messages that score within this range are considered suspected spam. Suspected spam is a separate category that you set on the Spam Scoring page. You can use policies to specify different actions for the messages that are identified as suspected spam and the messages that Symantec identifies as spam. For example, assume that you configure your suspected spam scoring range to encompass scores from 80 and 89. If an incoming message receives a spam score of 89, Messaging Gateway for Service Providers considers this message as suspected spam. It applies the action that you have in place for suspected spam messages. Messages that score 90 or above are subject to the action that you have in place for spam messages. You can gradually move the threshold setting down 1 point to 5 points a week until the number of false positives is acceptable. To test the effects of spam scoring, set up a designated mailbox or user to receive false positive notifications. You can use this mailbox to monitor the effects of changes to the spam score threshold. By default, messages are classified as spam if they have a combined score of 90 or higher, and this value is defined in the bmiconfig.xml file as follows: <spamthreshold>90</spamthreshold> Rejecting spam at the gateway If you have Messaging Gateway for Service Providers deployed at the gateway, you can conserve spam scanning resources when you reject spammers at connection time. Messaging Gateway for Service Providers determines if the IP address is in the list of blocked senders. If the message is in the blocked senders list, it indicates a verdict (instruction on how to handle a message) before the message contents are sent across the network connection. If the message is blocked, your MTA does not need to continue through the remainder of the calls, thereby reducing scanning resources. Note: If Messaging Gateway for Service Providers is not at the gateway, no early verdict is generated, even if the logical IP is on the blocked senders list. The logical IP cannot be tested for reputation because it is not available. Messages that are blocked at connection cannot be quarantined. Nor can these messages be annotated as spam and eventually added to the Blocked Senders List or determined to be false positives.

197 Using filters to protect your environment and block unwanted mail Scanning text attachments 197 For more information about early verdicts work, see the Messaging Gateway for Service Providers Software Development Kit Development Guide. To reject spam at the gateway 1 Open the bmiconfig.xml file with a file editor. 2 To enable connection time verdicts, set the value of the early VerdictsIP attribute as true. This feature is disabled by default. <earlyverdictsip enabled="true"/> 3 Save the file and exit. Scanning text attachments Messaging Gateway for Service Providers can scan text attachments to determine if they contain URLs, which could indicate that the message is spam. Messaging Gateway for Service Providers can scan the following message text attachments based on their MIME type: Microsoft Word and Microsoft Works attachments, MIME types: application/doc application/ms-word application/msword application/msworks application/vnd.ms-word application/vnd.ms-works application/word RTF format attachments, MIME type: application/rtf HTML and XML attachments, MIME types: application/html application/phtml application/xhtml application/xhtml_xml Attachments whose file names end in any of the following extensions:.doc

198 Using filters to protect your environment and block unwanted mail Increasing the speed for processing messages 198.htm.html.rtf.txt.wps.xml Note: If you enable this feature, there can be an impact on memory and performance, depending on the number of message attachments that are scanned and their size. To scan text attachments 1 Open the bmiconfig.xml file with a file editor. 2 To enable the scanning of text attachments, set the value of the scanattachments attribute as true. This feature is disabled by default.. <scanattachments enabled="true"/> 3 Save the file and exit. Increasing the speed for processing messages The Fastpass feature improves performance by skipping a subset of antispam filters for IP addresses with a demonstrated history of sending no spam messages. You can also specify one or more ranges of IP addresses to exclude from Fastpass. All antispam processing is performed for the addresses that you exclude. You can specify individual IP addresses, or you can use the address, hostmask, or CIDR notation. To increase the speed for processing messages 1 Open the bmiconfig.xml file with a file editor. 2 Enable the Fastpass feature by setting the value as true. The Fastpass feature is disabled by default. <module xsi:type="fastpassmoduletye" name="libfastpass" enabled="true" critical="false" profiling="false">

199 Using filters to protect your environment and block unwanted mail About filtering for viruses Specify one or more ranges of IP addresses that you want to exclude from antispam processing in the following tag: <excluderanges> </excluderanges> 4 Save the file and exit. About filtering for viruses When you enable antivirus filtering, Messaging Gateway for Service Providers Scanners scans for and detects viruses in . When it detects a virus, it applies the actions that you specify in the antivirus policies. For example, you can instruct the Scanner to: Deliver the message normally. Delete the message. Clean the message with the AntiVirus Cleaner and then redeliver the message through an SMTP process. You can also set policies for mass-mailing worms and the potential virus messages that the Scanner cannot process (unscannable messages). After the Scanner processes messages, the AntiVirus Cleaner creates a configurable advisory text message. This message informs the user that the infected attachment is cleaned, deleted, or delivered without cleaning. If the message is delivered, the Cleaner inserts the original message as an attachment to the advisory message. The Cleaner also places a special identifying line in the message header so that the message is not filtered again for viruses. If your antivirus subscription lapses, virus filtering ceases. Contact your Symantec representative for instructions on how to purchase or renew a virus filtering license. See About registering your Scanner license on page 210. Configuring antivirus filter settings Configure antivirus filter settings to establish the policies that you want Messaging Gateway for Service Providers to take if a virus is detected or if a file cannot be scanned.

200 Using filters to protect your environment and block unwanted mail Configuring antivirus filter settings 200 To configure antivirus filter settings 1 Open the bmiconfig.xml file with a file editor. 2 Modify the antivirus tags in libantivirus as follows: <module xsi:type="avmoduletype" name="libantivirus" enabled="true" critical="false" profiling="false"> <heuristiclevel>2</heuristiclevel> <maxscantime>600</maxscantime> 3 Save the file and exit.

201 Chapter 11 Keeping your product up-to-date This chapter includes the following topics: About updating virus definitions About LiveUpdate About Rapid Release virus definitions Obtaining the virus definition updates Obtaining definitions when a new or emerging threat is discovered Setting a local mirror of the LiveUpdate server About updating virus definitions Messaging Gateway for Service Providers relies on up-to-date information to detect viruses and threats. One of the most common reasons that problems occur is that virus definition files are not up-to-date. Symantec regularly supplies the updated virus definition files that contain the necessary information about all newly discovered viruses and threats. Regular updates of virus definitions maximize security and guard your organization against infections and the downtime that is associated with an outbreak. The Brightmail LiveUpdate service on Windows platform and jlu-controller daemon on Solaris and Linux platforms are used to update antivirus definitions on Messaging Gateway for Service Providers. Table 11-1 lists the methods that you can use to obtain updated virus definitions from Symantec.

202 Keeping your product up-to-date About LiveUpdate 202 Table 11-1 Method LiveUpdate Methods to obtain updated virus definitions from Symantec Description LiveUpdate downloads and installs available definitions to update your protection. See About LiveUpdate on page 202. See Obtaining the virus definition updates on page 204. See Setting a local mirror of the LiveUpdate server on page 207. Rapid Release Rapid Release definitions are more frequently updated than the LiveUpdate definitions. These definitions can be used when you need quick response to emerging threats. Rapid Response is an alternative to LiveUpdate. See About Rapid Release virus definitions on page 204. See Obtaining definitions when a new or emerging threat is discovered on page 206. You must have a valid content license to install definition files. A content license is a grant by Symantec Corporation for you to update Symantec corporate software with the latest associated content, such as new definitions. When you do not have a content license or your license expires, your product does not receive the most current definitions. Your environment is vulnerable to attacks. About LiveUpdate LiveUpdate virus definitions undergo rigorous quality assurance testing before they are published. They are downloaded through HTTP communication from the Symantec LiveUpdate server through the Java LiveUpdate (JLU) client. The JLU client requires 32-bit Java Runtime Environment (JRE) v1.5 or later versions. On Linux and Solaris platforms, JRE is bundled with Messaging Gateway for Service Providers's installer. Whereas, on the Windows platform, you must install JRE before Messaging Gateway for Service Providers installation. Following are the installation locations of the JLU client: On Linux and Solaris platforms /opt/symantec/liveupdate On Windows platform <Program Files Folder>\Common Files\Symantec Shared\Java LiveUpdate The configuration file for the JLU client is liveupdate.conf. The liveupdate.conf is available in the following location:

203 Keeping your product up-to-date About LiveUpdate 203 On Linux and Solaris platforms /etc On Windows platform <Common Apps Folder>\Symantec\Java LiveUpdate Windows 2008 For example: C:\ProgramData\Symantec\Java LiveUpdate Windows 2003 For example: c:\documents and Settings\All Users\Application Data\Symantec\Java LiveUpdate Messaging Gateway for Service Providers uses the JLU client to download virus definitions and the JLU client uses liveupdate.conf file to read configuration information. The HTTP address of the LiveUpdate server is listed in this file. The JLU client creates liveupdt.log in the location: On Linux or Solaris platforms /opt/symantec/liveupdate On Windows platform <Common Apps Folder>\Symantec\Java LiveUpdate The liveupdt.log file contains entries of JLU client activities. The JLU client also uses a working directory to download antivirus definitions temporarily whose path is provided during the Messaging Gateway for Service Providers installation. The Messaging Gateway for Service Providers's LiveUpdate service entries are logged in the jlu_controller_log file. An additional log file liveupdate.log is created in the Messaging Gateway for Service Providers Scanner s log directory when the JLU client experiences any error. This log file is a copy of the JLU client s LiveUpdate log file at that point. If your organization has several Messaging Gateway for Service Providers servers, you can obtain definitions at a single place on an internal server. Then you can disseminate these definitions to all of your Messaging Gateway for Service Providers servers. This configuration lets you limit the amount of Internet traffic that accesses Symantec LiveUpdate. For setting up the internal server, you must set up a local mirror of the LiveUpdate server. See About updating virus definitions on page 201. See Obtaining the virus definition updates on page 204. See Setting a local mirror of the LiveUpdate server on page 207.

204 Keeping your product up-to-date About Rapid Release virus definitions 204 About Rapid Release virus definitions Rapid Release virus definitions are created when a new threat is discovered. They respond to high-level outbreaks and might be made available before the LiveUpdate definitions quality assurance process is complete. They can be augmented later on by more robust detection capabilities in certified definitions. Rapid Release virus definitions are published more frequently than LiveUpdate definitions. It is the default option to download antivirus definitions in Messaging Gateway for Service Providers. It is downloaded through HTTP communication from the Symantec Rapid Release server in every 150 minutes. The download interval of 150 minutes is fixed. Following are the URL entries in the bmiconfig.xml file for Rapid Release definitions downloads: <sequrl> version-info.txt</sequrl> <defsurl platformcontrol='linux'> rapidrelease/ennlu.lin</defsurl> You can change these URLs to point to a different Rapid Release server. Warning: Rapid Release definitions do not undergo the same rigorous quality assurance testing as LiveUpdate definitions. Symantec encourages you to rely on the full quality-assurance-tested definitions whenever possible. Ensure that you deploy Rapid Response definitions to a test environment before you install them on your network. See About updating virus definitions on page 201. See Obtaining definitions when a new or emerging threat is discovered on page 206. Obtaining the virus definition updates Platinum virus definitions and Rapid Release virus definitions are the two types of virus definitions that you can obtain for your product. Messaging Gateway for Service Providers is configured to obtain Rapid Release virus definitions by default. See Obtaining definitions when a new or emerging threat is discovered on page 206. You can specify the source from which you want to obtain Platinum virus definitions as follows:

205 Keeping your product up-to-date Obtaining the virus definition updates 205 Symantec Website Downloads the virus definitions directly from the Symantec LiveUpdate server. This is the default option. LAN host If your organization has several Messaging Gateway for Service Providers servers, you can obtain definitions on an internal server. Then you can disseminate the definitions to all of your Messaging Gateway for Service Providers servers. This configuration lets you limit the amount of Internet traffic that accesses Symantec LiveUpdate. In this scenario, you must specify the information for the LAN host and if required proxy. Note: The LAN host option is unavailable when you select the Rapid Release option. See About updating virus definitions on page 201. To obtain virus definition updates from Symantec LiveUpdate server You define the server or host from which you obtain virus definition updates by editng the URLs to which the LiveUpdate client points in the bmiconfig.xml file. To obtain Platinum definitions, edit the bmiconfig.xml file as follows: <platinumdefshost defaulturl=" <customserver enabled="false"> </customserver> </platinumdefshost> To obtain virus definition updates from a LAN host You obtain virus definitions from a LAN host instead of the LiveUpdate server, edit the bmiconfig.xml file as follows: <customserver enabled="true"> <address> <username>pqr</username><password plain="true">1234</password> <proxy enabled="true"> <server host=" " port="12"/> <username>xyz</username> <password plain="true">abc</password> </proxy> </customserver> For more information on setting up a LAN host, see the LiveUpdate Administrator's Guide.

206 Keeping your product up-to-date Obtaining definitions when a new or emerging threat is discovered 206 Note: LiveUpdate uses the proxy that you define for the Scanner to download virus definitions from Symantec. If you download virus definitions from a LAN host, LiveUpdate uses a proxy only if you have defined one. Obtaining definitions when a new or emerging threat is discovered You can use Rapid Release when you need quick responses to the emerging threats. Rapid Release definitions are the most useful for a perimeter defense to mitigate quickly spreading threats. Messaging Gateway for Service Providers is configured to obtain Rapid Release virus definitions by default. Warning: Rapid Release definitions do not undergo the same rigorous quality assurance testing as LiveUpdate definitions. Symantec encourages you to rely on the LiveUpdate definitions whenever possible. Ensure that you deploy Rapid Release definitions to a test environment before you install them on your network. When you enable Rapid Release virus definition updates, Messaging Gateway for Service Providers uses the Symantec Web site as the source for the definition updates. See Obtaining the virus definition updates on page 204. To obtain definitions when a new or emerging threat is discovered Edit the bmiconfig.xml file as follows: <rapidreleaseurls> <sequrl> rapidrelease/version-info.txt</sequrl> <defsurl platformcontrol="win64"> /defs/rapidrelease/symrapidreleasedefsi64.exe</defsurl> <defsurl platformcontrol="linux"> /defs/rapidrelease/ennlu.lin</defsurl> <defsurl platformcontrol="linux64"> /defs/rapidrelease/ennlu64.lin</defsurl> <defsurl platformcontrol="solaris">

207 Keeping your product up-to-date Setting a local mirror of the LiveUpdate server 207 /defs/rapidrelease/ennlu.sol</defsurl> <defsurl platformcontrol="solaris64"> /defs/rapidrelease/ennlu64.sol</defsurl> </rapidreleaseurls> <checkforcustomdefs enabled="false"/> See About updating virus definitions on page 201. Setting a local mirror of the LiveUpdate server A local mirror of LiveUpdate server can be set up to download antivirus definitions at a single place. Later these antivirus definitions can be downloaded by multiple Messaging Gateway for Service Providers installations. LiveUpdate Administrator downloads antivirus definitions periodically and then transfers these definitions to a distribution server (HTTP server). All other Messaging Gateway for Service Providers installations download definitions from this distribution server. To set a LiveUpdate Administrator server s address, you directly modify the following bmiconfig.xml entry: <platinumdefshost defaulturl= ' <customserver enabled='true'> <address>url of distribution server</address> <username></username> <password plain='true'></password> <proxy enabled='false'></proxy> </customserver> </platinumdefshost> For more information, see LiveUpdate Administrator User Guide. See About updating virus definitions on page 201. See About LiveUpdate on page 202. See Obtaining the virus definition updates on page 204.

208 Chapter 12 Managing Messaging Gateway for Service Providers Scanners, hosts, and components This chapter includes the following topics: Specifying internal mail hosts About registering your Scanner license Specifying internal mail hosts To provide accurate source-based filtering for the Allowed Senders List and the Blocked Senders List, Messaging Gateway for Service Providers needs to know which IP addresses are internal to your organization. Internal servers are typically internal relay servers or the mailbox servers that are located downstream from the gateway servers. A gateway server is usually deployed at or near the Internet and accepts incoming Internet messages and forwards these messages to the appropriate internal mailbox servers. If you deploy Messaging Gateway for Service Providers anywhere else but at the gateway, you need to provide information about your internal mail or MX network. With this information, Messaging Gateway for Service Providers can extract a message's logical connection address, which is the connection address obtained where the message entered your network. In non-gateway deployments, Messaging Gateway for Service Providers uses this logical connection to match against IP the

209 Managing Messaging Gateway for Service Providers Scanners, hosts, and components Specifying internal mail hosts 209 connections that are specified on your Allowed Senders List, Blocked Senders List, or the Safe List which the Reputation Service provides. See About adjusting MX records for Messaging Gateway for Service Providers software on page 37. Note: You can disregard this section if all your Scanners are deployed at the gateway. Note the following considerations about internal mail hosts: Messaging Gateway for Service Providers bases its view of your network on the specified internal address ranges and on the received headers that remain intact between the edge of your network and the computers on which the Scanners are deployed. If you choose to provide a hostname when you identify an internal host, ensure that the hostname resolves to a single address. The use of internal mail hosts settings to extract logical connections applies only to the Blocked Senders List, the Allowed Senders Lists, and the Safe List. It does not apply for reporting, custom filters, or other features that make use of IP connection addresses. In the latter cases, you should deploy Messaging Gateway for Service Providers at the gateway if you want to receive the most complete information about IP addresses. You do not need to specify any private address space (for example, /8 or other subnets that is defined as private in RFC 1918) in the internal address range. These addresses are automatically incorporated into the internal address range. Note: Instead of only identifying the address range for your MX/mail network, you can add your entire internal network range in one step (x.y.z.0/24). With this method, if you ever add new mail servers, new networks, or add IP addresses to your network, you do not need to adjust the settings on this page. If you choose this method, the Reputation Service does not apply to these addresses. (The consequences of this method are minimal since the addresses are from your own network.) To specify internal mail hosts To add or edit internal mail hosts, use a text editor to open bmiconfig.xml, and modify the internalranges tag to include the desired hosts.

210 Managing Messaging Gateway for Service Providers Scanners, hosts, and components About registering your Scanner license 210 About registering your Scanner license For Messaging Gateway for Service Providers to be fully functional, you must register two licenses. One license activates scanning. The other license lets you obtain updated filters from Symantec. For client-only Scanners, registration is not required. License registration involves the following process: Obtain a license file from Symantec. To request a license file, you must have the license serial number for each license that you want to activate. After you complete the registration process, Symantec sends you the appropriate license file by . Register the license file. You must register the license for the Scanner to scan messages and receive updated filters. Symantec issues a serial number for each type of license that you purchase. Each serial number must be registered (individually or at the same time) to receive a license key for the associated license. License keys are delivered in a Symantec license file (.slf). The serial number is provided on a license certificate, which is mailed separately and arrives in the same time frame as your software. For security reasons, the license certificate is not included in the software distribution. If you upgrade from a previous version of the product and you have an active maintenance contract, you might receive the serial number certificate with an upgrade insurance letter. Your license certificate should arrive within three to five business days of when you receive your software or subscribe to Symantec Premium AntiSpam. The license certificate contains the serial numbers for the licenses that you have purchased. If you do not receive the license certificate, contact Symantec Customer Service at or your reseller to check the status of your order. If you have lost your license certificate, contact Symantec License Administration. To request a license file, you must have the serial number that is required for activation. (Each license has a separate serial number.) The serial number is used to request a license file and to register for support. The serial number is printed on the license certificate that was mailed to you. The format of a serial number is a letter followed by 10 digits; for example, F The license file that Symantec sends to you is contained within a.zip file. The.slf file the.zip file contains is the actual license file. Ensure that your inbound environment permits.zip message attachments.

211 Managing Messaging Gateway for Service Providers Scanners, hosts, and components About registering your Scanner license 211 Warning: License files are digitally signed. If you attempt to edit a license file, you corrupt the file and render it invalid. To renew a license that has expired, contact your Symantec sales representative. See Where to get more information about Messaging Gateway for Service Providers on page 22. To obtain a license file 1 In a Web browser, type the following address: Your Web browser must use 128-bit encryption to view the site. 2 If a Security Alert dialog box appears, click OK. 3 Follow the instructions that are provided on the Web site to request a license file. 4 When you receive the message from Symantec that contains the license file, save the license file to a location that is easily accessible. The file is delivered as a.zip file. You must extract the file contents from the file. To register your Scanner for Linux and Solaris 1 As root user and from the /opt/symantec/smg-sp/scanner/sbin directory, run the registration script with the path to bmiconfig.xml and license file: $ su root # /opt/symantec/smg-sp/scanner/sbin register.sh -1 <path to license file> 2 Type the path of your license file. To register your Scanner for Windows 1 At the Windows Command prompt, navigate to the installation location of your Scanner files: C:\Program Files\Symantec\smg-sp\Scanner\Bin 2 Run the register.exe executable from the command line, providing the the license file and bmiconfig.xml paths as parameters: register.exe -l <path to license file> -c <path to bmiconfig.xml>

212 Chapter 13 Monitoring the Messaging Gateway for Service Providers status and events This chapter includes the following topics: About Logs Modifying Log settings Viewing and saving logs About tracking messages with the SMTP message ID About Logs Each Scanner maintains a database of log information. You can view these logs by navigating to the log location directory and using a text editor to view the log file. For example: vi /var/log/brightmail/bmserver_log. This information lets you diagnose error conditions and keep track of many aspects of your system during its operation. You can store the log data for the following Messaging Gateway for Service Providers components: Server Client Conduit

213 Monitoring the Messaging Gateway for Service Providers status and events About Logs 213 Harvester AntiVirus Cleaner LiveUpdate You can designate the severity of errors that you want written to the log files. Messaging Gateway for Service Providers provides several logging levels, with each successive level including all errors from the previous levels. The default log level for each Messaging Gateway for Service Providers software component is Warnings. You can choose from the following log levels: Errors Warnings Notices Information Debug Symantec Message Filter provides a message auditing component that lets you save the message audit logs to bmserver logs or system logs. The Message audit log provides you with a trail of detailed information about every message that the Scanner has processed. Auditing information is used to track the decisions that are made within a single Scanner framework. The Message audit log does not replace debug or information level logging. Unlike the standard Scanner log, the Message audit log provides information specifically associated with a message. Bmserver logs are saved in bmserver_log.txt file at the following locations: Windows scanner UNIX scanner Scanner\Logs\bmserver_log.txt /var/log/brightmail/bmserver_log The configuration of the facilities lets you direct messages to various local files. The specified facility logs all the information when you use the Syslog. The default facility is mail. You can configure Syslog for the following facilities: kern, mail, user, daemon, auth, lpr, news, uucp, cron, local0, local1, local2, local2, local3, local4, local5, local6, and local7. To limit the size of the database that stores log data, Messaging Gateway for Service Providers stores seven days of log data with a maximum storage allotment of 512 MB. If the database already has 512 MB of data or seven days of data, the oldest log data is deleted. To keep more log data for a longer period, you can change the default maximum log size and retention period settings.

214 Monitoring the Messaging Gateway for Service Providers status and events Modifying Log settings 214 See Modifying Log settings on page 214. See Viewing and saving logs on page 214. See About tracking messages with the SMTP message ID on page 214. Modifying Log settings You can modify the Log settings to specify Log levels for the Symantec Message Filter components and to specify the Log storage limits. To modify Log settings Use a text editor to modify the values for the component-specific XML tag for the log in the file /$loadpoint/etc/bmiconfig.xml: <log enabled="true" level="4" period="1" periodunits="day" numberretained="30" haltthreshold="500" reducethreshold="1024"> /var/log/brightmail/conduit_log </log> Viewing and saving logs You can view logs for Scanners by opening the desired log in a text editor and viewing the log's contents. About tracking messages with the SMTP message ID Messaging Gateway for Service Providers includes the SMTP message ID in the log entries. The SMTP message ID lets you trace a specific message across your infrastructure as it passes through the message flow. An example of a log entry that contains the SMTP message ID appears as follows:

215 Monitoring the Messaging Gateway for Service Providers status and events About tracking messages with the SMTP message ID 215 SMTP message ID 4 Aug :46:13 (DEBUG: ): [F28D B18B5D0C98FD5CDC79@symantecexp] [src/ module_api.c:823] envelope from: <[email protected]> 4 Aug :46:13 (DEBUG: ): [F28D B18B5D0C98FD5CDC79@symantecexp] [src/ module_api.c:831] helo from: symantecexp 4 Aug :46:13 (DEBUG: ): [F28D B18B5D0C98FD5CDC79@symantecexp] [src/ bmi_extractips.c:565] parsed ip as Aug :46:13 (NOTICE: ): [27166] [F28D B18B5D0C98FD5CDC79@symantecexp] Message For: <[email protected]> returned Disposition: <null>. Default destination will be returned for normal delivery. 4 Aug :46:13 (DEBUG: ): [F28D B18B5D0C98FD5CDC79@symantecexp] [src/ blt_mta_api.c:1150] Disposition Settings for:[email protected] Destination:[(null)] ActionType:[0] 4 Aug :46:13 (DEBUG: ): [F28D B18B5D0C98FD5CDC79@symantecexp] [src/ blt_mta_api.c:1236] ActionTable: 0 Unique Entry: 562A8F3EE4E5C94981E2259E3253BEB1 Recips: 1 4 Aug :46:13 (DEBUG: ): [F28D B18B5D0C98FD5CDC79@symantecexp] [src/ blt_mta_api.c:7089] bmiendmessage: UniqueActionEntries across all tables: 1

216 Appendix A Command line reference This appendix includes the following topics: policyconfig subm-config subm-config allowedlist subm-config blockedlist subm-config configuration subm-config displaylist subm-config msg subm-config msginfo subm-config provisioning subm-config rawmsg subm-config report subm-config rule subm-config ruleinfo subm-config servicestatus subm-config submitspam subm-config submitnotspam subm-config submissionpolicy

217 Command line reference policyconfig 217 policyconfig policyconfig Add a new disposition, update an existing disposition, set the destination for a message, change the order of message scanning, and import a local reputation list in to the allowedblockedlist. SYNOPSIS policyconfig -i path/bmiconfig.xml -s <path>/bmiconfig.xsd policyconfig -i path/bmiconfig.xml -s path/bmiconfig.xsd -v output file policyconfig -help DESCRIPTION The policyconfig command enables you to add a new disposition, update an existing disposition, set the destination for a message, change the order of message scanning, and import the allowedblockedlist with the local reputation list. OPTIONS -i path/bmiconfig.xml Specifies the bmiconfig.xml file. -s path/bmiconfig.xsd Specifies the bmiconfig.xsd file. -q Runs the policyconfig command in Quiet Mode. -v output file -help Specifies that the output of the command is stored in the output file instead of displaying it on the console. Displays this message.

218 Command line reference subm-config 218 subm-config subm-config Displays the commands, actions, and options for customer-specific spam submissions SYNOPSIS subm-config subm-config -help DESCRIPTION The subm-config command displays the commands, actions, and options for customer-specific spam submissions. COMMANDS Use the following commands for customer-specific spam submissions: provisioning Provisions the submitter ID for customer-specific spam submissions. See subm-config provisioning on page 228. servicestatus Displays the status of the customer-centric spam submission service. See subm-config servicestatus on page 235. submitspam Submits spam messages to Symantec to obtain customer-specific rules. See subm-config submitspam on page 236. submitnotspam Submits the messages that are incorrectly marked as spam to Symantec to obtain customer-specific rules. See subm-config submitnotspam on page 238. allowedlist Specifies the allowed list of users who can perform customer-specific submissions to Symantec. See subm-config allowedlist on page 222.

219 Command line reference subm-config 219 blockedlist Specifies the blocked list of users who cannot perform customer-specific submissions to Symantec. See subm-config blockedlist on page 223. displaylist Displays the allowed list of users or the blocked list of users for customer-specific spam submissions. See subm-config displaylist on page 225. submissionpolicy report Sets the customer-specific spam submission aggressiveness level. See subm-config submissionpolicy on page 240. Generates the XML file with submission data as specified in the path/report_input.xml file. msginfo rawmsg msg rule See subm-config report on page 231. Displays customer-specific spam submission status for a specified message. See subm-config msginfo on page 227. Displays the raw message that is submitted to Symantec in the RFC822 format. See subm-config rawmsg on page 230. Deletes or annotates the customer-specific spam submission message on the Symantec server. See subm-config msg on page 226. Deletes or annotates a rule that is applied to a message. See subm-config rule on page 233. ruleinfo Displays information about a specific rule. See subm-config ruleinfo on page 234. configuration Allows to reset the Scanner configuration.

220 Command line reference subm-config 220 ACTIONS -configure Gets a new submitter ID from Symantec. If a submitter ID already exists in the configuration file, this command re-provisions or verifies the existing submitter ID. If you re-provision, the existing submission rules are deleted. -enable See subm-config provisioning on page 228. Provisioning is enabled only locally. You must enable customer-specific rule downloads manually. See subm-config provisioning on page disable -get Provisioning is disabled locally. Ensures that the customer-specific rule downloads on the Scanner is disabled. If the submitter ID is shared across other Scanners, the other Scanners can continue to download the customer-specific rules. See subm-config provisioning on page 228. Obtains the raw message that is submitted to Symantec and displays it in the RFC822 format. See subm-config rawmsg on page 230. Or -update Gets the information for the rule that you specify and displays it. See subm-config ruleinfo on page 234. Updates the list of users who can submit customer-specific message submission to Symantec. See subm-config allowedlist on page 222. Or Updates the list of users who cannot submit customer-specific message submission to Symantec. See subm-config blockedlist on page summary Retrieves the summary for the customer-specific submission that is specified in the path/report_input.xml file.

221 Command line reference subm-config 221 See subm-config report on page detail Retrieves detailed information for the customer-specific submission that is specified in the path/report_input.xml file. See subm-config report on page annotate -help Deletes the rule that is applied to the message. See subm-config rule on page 233. Displays this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. -o output file Specify an output file to store the command output in a file instead of displaying it on the console. -id Submitter Id Specify the Submitter Id. -f Input file Specify the input file to generate a summary report or a detailed report.

222 Command line reference subm-config allowedlist 222 subm-config allowedlist subm-config allowedlist Specifies the list of users who can perform customer-specific spam submissions to Symantec SYNOPSIS subm-config allowedlist -update -c path/bmiconfig.xml subm-config allowedlist -update -c path/bmiconfig.xml address list subm-config allowedlist -update -c path/bmiconfig.xml -f path/filename subm-config allowedlist -help DESCRIPTION The subm-config allowedlist command lets you specify the users who can submit customer-specific spam messages to Symantec. ARGUMENTS -update Updates the list of users who can submit customer-specific spam messages to Symantec. address list Specifies the address or the list of addresses of users who can submit customer-specific spam messages to Symantec. The addresses must be separated by a comma. Filename -help Contains the list of addresses of users who can submit customer-specific spam messages to Symantec. The addresses in this file must be separated by a newline as follows, and must be in the below format: [email protected] [email protected] Displays this message.

223 Command line reference subm-config blockedlist 223 subm-config blockedlist subm-config blockedlist Specifies the user(s) who cannot perform customer-specific spam submissions to Symantec SYNOPSIS subm-config blockedlist -update -c path/bmiconfig.xml subm-config blockedlist -update -c path/bmiconfig.xml address list subm-config blockedlist -update -c path/bmiconfig.xml -f path/filename subm-config blockedlist -help DESCRIPTION The subm-config blockedlist command lets you specify the users who cannot submit customer-specific spam messages to Symantec. Arguments -update Updates the list of users who cannot submit customer-specific spam messages to Symantec. address list Specifies the address or an address list of users who cannot submit customer-specific spam messages to Symantec. The addresses must be separated by a comma. Filename -help Contains the list of addresses of users who cannot submit customer-specific spam messages to Symantec. The addresses in this file must be separated by a newline as follows, and must be in the below format: [email protected] [email protected] Displays this message.

224 Command line reference subm-config configuration 224 subm-config configuration subm-config configuration Allows to reset scanner configuration SYNOPSIS subm-config configuration -reset -c path/bmiconfig.xml subm-config configuration -help DESCRIPTION The subm-config configuration command lets you reset the scanner configuration. This command will remove the blocked users list if it exists and sets the aggressiveness level to conservative. It does not remove the customer-specific messages that are already submitted to Symantec from the Symantec server. ARGUMENTS -reset Resets the scanner configuration. -help Displays this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. -o output file Specify an output file to store the command output in a file instead of displaying it on the console.

225 Command line reference subm-config displaylist 225 subm-config displaylist subm-config displaylist Displays the allowed list of users or the blocked list of users for customer-specific spam submissions SYNOPSIS subm-config displaylist - c path/bmiconfig.xml subm-config displaylist -help DESCRIPTION The subm-config displaylist lets you obtain either the allowed list of users or the blocked list of users for customer-specific spam submissions. ARGUMENTS -help DisplayS this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. -o output file Specify an output file to store the command output in a file instead of displaying it on the console.

226 Command line reference subm-config msg 226 subm-config msg subm-config msg Deletes or annotates the customer-specific spam submission on the Symantec server. SYNOPSIS subm-config msg -delete gumid -c <path>/bmiconfig.xml subm-config msg -annotate gumid -c <path>/bmiconfig.xml "Annotaiton.." subm-config msg -help DESCRIPTION The subm-config msg command lets you delete or annotate the customer-specific spam submission on the Symantec server. ARGUMENTS -delete Deletes the customer-specific spam submission message on the Symantec server and inactivates the rule that is associated with the message. The message that is to be deleted is specified by providing the gumid. -annotate -help gumid Annotates a text that you provide to the specified customer-specific spam submission. The message that is to be annotated is specified by providing the gumid. Displays this message. Unique identification number generated by the Symantec server when a customer-specific spam message is submitted to Symantec. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. -o output file Specify an output file to store the command output in a file instead of displaying it on the console.

227 Command line reference subm-config msginfo 227 subm-config msginfo subm-config msginfo Displays the customer-specific spam submission status for a specified message. SYNOPSIS subm-config msginfo -get gumid -c path/bmiconfig.xml subm-config msginfo -help DESCRIPTION The subm-config msginfo command displays the customer-specific spam submission status for the specified message. ARGUMENTS -get -help Obtains the customer-specific spam submission status for the specified message and displays it. Displays this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. -o output file Specify an output file to store the command output in a file instead of displaying it on the console.

228 Command line reference subm-config provisioning 228 subm-config provisioning subm-config provisioning spam submissions Provisions the submitter ID for customer-specific SYNOPSIS subm-config provisioning -configure -c path/bmiconfig.xml subm-config provisioning -configure -id submitterid -c path/bmiconfig.xml subm-config provisioning -delete -c path/bmiconfig.xml subm-config provisioning -disable -c path/bmiconfig.xml subm-config provisioning -enable -c path/bmiconfig.xml subm-config provisioning -help DESCRIPTION The subm-config provisioning command enables you to provision a submitter ID for customer-specific spam submissions. Use this command to provision, re-provision, share a submitter ID across scanners, enable or disable provisioning locally, and delete provisioning. ARGUMENTS -configure Gets a new submitter ID from Symantec. If a submitter ID already exists in the configuration file, this command lets you to re-provision or verify the existing submitter ID. If you re-provision, the existing submission rules are deleted. -s submitterid -delete Specifies an existing submitter ID for customer-specific spam submissions. Deletes all customer-specific spam submissions from the Symantec database and Messaging Gateway for Service Providers. -disable Provisioning is disabled locally. Ensures that the customer-specific rule downloads on the Scanner is disabled. If the submitter ID is shared across other Scanners, the other Scanners can contine to download the customer-specific rule downloads.

229 Command line reference subm-config provisioning 229 -enable -help Provisioning is enabled only locally. You must enable customer-specific rule downloads manually. Displays this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. -o output file Specify an output file to store the command output in a file instead of displaying it on the console.

230 Command line reference subm-config rawmsg 230 subm-config rawmsg subm-config rawmsg in the RFC822 format. Displays the raw message that is submitted to Symantec SYNOPSIS subm-config rawmsg -get gumid -c path/bmiconfig.xml subm-config rawmsg -help DESCRIPTION The subm-config rawmsg command displays the raw message that is submitted to Symantec in the RFC822 format. ARGUMENTS -get -help Obtains the raw message that is submitted to Symantec and displays it in RFC822 format. Displays this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. -o output file Specify an output file to store the command output instead of displaying it on the console.

231 Command line reference subm-config report 231 subm-config report subm-config report Generates the XML file with submission data as specified in the path/report_input.xml file SYNOPSIS subm-config report --summary -f path/report_input.xml -c path/bmiconfig.xml subm-config report --detail -f path/report_input.xml -c path/bmiconfig.xml subm-config report -help DESCRIPTION The subm-config report command retrieves the submission information as specified in the path/report_input.xml file. In the path/report_input.xml file, you must select the appropriate XML tags as per your data requirements for report generation. Based on your requirements, you can set filtering values for summary report such as SubmmisionType, SubmitterType, TopSubmitterCount and so on. You can also set filtering values for detail report based on your requirements such as SummisionType, SubmitterType, subject, SubmitterAddress and so on. As part of the installation process, Symantec Messaging Gateway for Service Providers creates a folder called etc, which contains sample files that you use to generate reports. The etc folder contains the following sample files: File Name sample_daily_detail.xml sample_daily_summary.xml Description Helps generate detail daily report for submissions done using the CLI. Helps generate daily summary report for submissions done using the CLI. sample_monthly_summary.xml Helps generate monthly summary report for submissions done using the CLI. sample_top5_summary.xml Helps generate summary report for list of the top 5 submitters done using the CLI. submission_detail_request.xml Reference file for generating a customized detail report for a provisioned scanner.

232 Command line reference subm-config report 232 File Name Description submission_summary_request.xml Reference file for generating a customized summary report for a provisioned scanner. ARGUMENTS -summary Retrieves the summary of the submission data specified in the path/report_input.xml file. -detail -help Retrieves the detailed version of submission data specified in the path/report_input.xml file. Display this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. -f path/report_input.xml Specify the input XML file for report generation.

233 Command line reference subm-config rule 233 subm-config rule subm-config rule Deletes or annotates a rule applied to a message SYNOPSIS subm-config rule -delete rule_id -c path/bmiconfig.xml subm-config rule -annotate rule_id -c path/bmiconfig.xml annotaion.. subm-config ruleinfo -help DESCRIPTION The subm-config rule command lets you either delete a rule that is applied to a message or annotate a rule with a comment. ARGUMENTS -delete Deletes the rule that is applied to the message. -annotate Annotates the comment that you provide to the rule applied to the message. -help Displays this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. ruleid Specify the ruleid that you want to delete or annotate.

234 Command line reference subm-config ruleinfo 234 subm-config ruleinfo subm-config ruleinfo Displays information about a specific rule SYNOPSIS subm-config ruleinfo -get ruleid -c path/bmiconfig.xml subm-config ruleinfo -help DESCRIPTION The subm-config ruleinfo command displays information about a specific rule. ARGUMENTS -get Gets information about the rule that you specify and displays it. -help Displays this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. ruleid Specify the ruleid for which you want to get information.

235 Command line reference subm-config servicestatus 235 subm-config servicestatus subm-config servicestatus submission service Displays the status of the customer-centric spam SYNOPSIS subm-config servicestatus - c path/bmiconfig.xml subm-config servicestatus -help DESCRIPTION The subm-config servicestatus command lets you get the latest status of the customer-specific spam submission service. ARGUMENTS -help Displays this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. -o output file Specify an output file to store the command output instead of displaying it on the console.

236 Command line reference subm-config submitspam 236 subm-config submitspam subm-config submitspam customer-specific rules Submit spam messages to Symantec to obtain SYNOPSIS subm-config submitspam -f file1, [file2.. filen] -c path/bmiconfig.xml subm-config submitspam -d directory -c path/bmiconfig.xml subm-config submitspam -help DESCRIPTION The subm-config submitspam command lets you submit spam messages to Symantec. You can submit one or more message file(s) or a directory that contains spam message file(s). Ensure that you submit an RFC5322-compliant message to notify Symantec that the message must be marked as spam. Note: Outlook messages that are saved as.msg files are not RFC compliant and are not considered valid submissions. For more information about RFC5322 requirements, on the Internet, go to the following URL: ARGUMENTS -help Displays this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. -f file1, [file2.. filen] Specifies file(s) that are submitted as spam to Symantec.

237 Command line reference subm-config submitspam 237 -d directory Specifies the directory that contains spam message file(s).

238 Command line reference subm-config submitnotspam 238 subm-config submitnotspam subm-config submitnotspam Submit the messages that are not spam to Symantec to obtain customer-specific rules SYNOPSIS subm-config submitnotspam -f file1, [file2.. filen] -c path/bmiconfig.xml subm-config submitnotspam -d directory -c path/bmiconfig.xml subm-config submitnotspam -help DESCRIPTION The subm-config submitnotspam command lets you submit messages that are incorrectly marked as spam to Symantec. You can submit one or more message file(s) or a directory that contains message file(s) that are incorrectly marked as spam. Ensure that you submit an RFC5322-compliant message to notify Symantec that the message is not a spam. Note: Outlook messages that are saved as.msg files are not RFC compliant and are not considered valid submissions. For more information about RFC5322 requirements, on the Internet, go to the following URL: ARGUMENTS -help Displays this message. OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. -f file1, [file2.. filen] Specifies file(s) that are incorrectly marked as spam by Symantec.

239 Command line reference subm-config submitnotspam 239 -d directory Specifies the directory that contains the message file(s) that are incorrectly marked as spam by Symantec.

240 Command line reference subm-config submissionpolicy 240 subm-config submissionpolicy subm-config submissionpolicy aggressiveness level Sets the customer-specific spam submission SYNOPSIS subm-config submissionpolicy -get -c path/bmiconfig.xml subm-config submissionpolicy -configure {conservative} -c path/bmiconfig.xml subm-config submissionpolicy -configure {aggressive} -c path/bmiconfig.xml subm-config submissionpolicy -help DESCRIPTION The subm-config submissionpolicy command lets you set the customer-specific spam submission aggressiveness level based on end user submissions. The aggressiveness levels are as follows: Conservative Aggressive Only multiple submissions gets rules. Multiple end users must submit the same message before Symantec considers it for a new rule. Every submission gets a rule. This command does not affect submissions from the administrator. ARGUMENTS -get Displays the status of the customer-specific spam submission aggressiveness level that is set for the end users. -configure -help Configures the customer-specific spam submission aggressiveness level to the mentioned level. You can configure the customer-specific spam submission aggressiveness level to either conservative or aggressive. Displays this message.

241 Command line reference subm-config submissionpolicy 241 OPTIONS -c path/bmiconfig.xml Specify the bmiconfig file. This option is mandatory. -o output file Specify an output file to store the command output instead of displaying it on the console.

242 Appendix B Input XML file to generate customer-specific submission report This appendix includes the following topics: Spam submission XML inputs and description Sample XML file to provide inputs for customer-specific spam report generation Spam submission XML inputs and description You can generate reports for customer-specific spam submissions that are made from your organization. Messaging Gateway for Service Providers enables you to provide your inputs in an XML file. Table B-1 lists the XML elements, their possible values, and description. Table B-1 Description of XML elements to specify inputs for report generation XML tag submissiondetail Request type Values Not applicable SUBMISSION_ TYPE_SPAM SUBMISSION_TYPE_NOSPAM Description Specifies that the XML file is used to request a report for submission data in the XML format. Specifies the type of submission that must be retrieved in the report.

243 Input XML file to generate customer-specific submission report Spam submission XML inputs and description 243 Table B-1 Description of XML elements to specify inputs for report generation (continued) XML tag submitter_type period granularity top_submitter_count order offset number annotation_search subject recipient_address sender_address user_agent Values ADMIN END_USER BLOCKED Omission <date>t<time> For example: T00:00:00.0Z Duration type non negative integer value ASCENDING DESCENDING Nonnegative integer Nonnegative integer Any string Any string Any string Any string Any string Description Specifies that you want to fetch the submission report for a type of submitter. Specifies the time period to fetch submission reports in the YYYY-MM-DD T HH:MM:SS format. Specifies that the period data obtained can be ordered by the day, month, or year. The period data cannot be ordered by the hour. Specifies the top submitter along with the count. Specifies the order in which the submission reports are sorted. Specifies the starting point of the record from where you need the data. A value of 0 indicates that you can retrieve information from the first record. Specifies the maximum number of records to return in the submission report. Specifies the provision to report the annotated messages. Specfies the provision to report the message with a subject. Specfies the provision to report the message with a recepient address. Specfies the provision to report the message with a sender address. Specifies the client information, product name, product version, and platform details.

244 Input XML file to generate customer-specific submission report Sample XML file to provide inputs for customer-specific spam report generation 244 See Sample XML file to provide inputs for customer-specific spam report generation on page 244. Sample XML file to provide inputs for customer-specific spam report generation Messaging Gateway for Service Providers enables you to generate summary and detailed reports for customer-specific spam submission. To generate these reports, you must provide the inputs in the form of an XML file. You may use the sample XML text in this section and ensure that it complies with the XSD to generate the report. The sample XML file to generate a detailed report is as follows: <?xml version="1.0" encoding="utf-8"?> <submissiondetailrequest xmlns="ara" version="1.0"> <period duration="p0y1m0dt0h0m0s"> t00:00:00.0z</period> </submissiondetailrequest> The sample XML file to generate a summary report is as follows: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <submissionsummaryrequest xmlns="ara"> <period duration="p0y1m0dt0h0m0s"> t00:00:00.0z</period> <granularity>p0y0m1dt0h0m0s</granularity> </submissionsummaryrequest> See subm-config report on page 231. See Spam submission XML inputs and description on page 242.

245 Index A Add group policy 165 new member to group policy 165 senders to your allowed senders list 191 senders to your Blocked Senders List 190 Adjusting spam scoring 195 Allowed and Blocked Senders lists about 188 reasons to use Blocked Senders 190 Antivirus definitions 204 Automatic expansion of subdomains 187 B Brightmail AntiSpam identifies senders and connections 187 Brightmail Client 32 Brightmail Reputation Service 195 Brightmail Server 32 bulk mail 168 C commands policyconfig 217 subm-config 218 subm-config allowedlist 222 subm-config blockedlist 223 subm-config configuration 224 subm-config displaylist 225 subm-config msg 226 subm-config msginfo 227 subm-config provisioning 228 subm-config rawmsg 230 subm-config report 231 subm-config rule 233 subm-config ruleinfo 234 subm-config servicestatus 235 subm-config submissionpolicy 240 subm-config submitnotspam 238 commands (continued) subm-config submitspam 236 Configure anti-virus filtering 200 firewall 33 spam scoring 195 Configuring Sendmail for the Brightmail Filter via m4 153 via Sendmail Switch 150 via sendmail.cf 151 Create new group policy 165 customer-specific spam rules. See spam: custom rules Customizing Brightmail Reputation Service 195 filtering at your site 185 D Define filtering actions for new group policy 166 Definitions LiveUpdate 204 Delete group policy 166 group policy member 166 senders from lists 191 Deployment at server 31 gateway 24 Disable group policy 166 senders 192 Disposition new 127 update 128 DNS latency parameter 62 DNS IP reputation 62

246 Index 246 E Edit existing group policy 166 senders 192 Enable group policy 165 senders 192 F Filtering, third party 36 Firewall Settings 33 G Group policy add 165 delete 166 delete a member from 166 disable 166 edit existing 166 enable 165 managing 166 H http //docs.sun.com/app/docs/coll/ //docs.sun.com/source/ / index.html#wp // 66 // 66 I Import sender information 193 Internal IP address specification 208 IP address IPv6 53 J JLU 111 updating virus definitions 204 L LiveUpdate log 111 program elements 111 updating virus definitions 201, 204 Log LiveUpdate 111 modifying settings 214 saving 214 view for Brightmail Scanner 214 viewing 214 working with 212 Logical connections and internal mail servers, non-gateway Deployments 187 M Manage group policies 164, 166 Message audit log 212 bmserver log 214 event log 214 syslog 214 Message destination change 129 Message scan change 130 order 130 Modifying log settings 214 MX Records 37 N newsletter 168 P policyconfig 217 Ports 33 Procedure to add addresses, domains, and third-party lists to Allowed Senders list 191 add addresses, domains, and third-party lists to your Blocked Senders list 190 configure AntiVirus filtering 200 create a new group policy 165 define filtering actions for new group policy 166 delete a group policy 166 delete a group policy member 166 delete senders from your Blocked Senders list or Allowed Senders list 192 disable a group policy 166 edit an existing group policy 166 edit senders in Blocked or Allowed Senders list 192 enable a group policy 165

247 Index 247 Procedure to (continued) enable or disable senders from your lists 192 modify log settings for a Brightmail Scanner 214 R Rapid Release definitions 201, 206 Rapid Response updates 206 Reputation Service customization 195 rules. See spam S sender reputation service 54 Senders disabling 192 enabling 192 Sendmail configuring for Brightmail Filter with m4 153 configuring for Brightmail Filter with sendmail.cf 151 Sendmail Switch 149 Sendmail Switch, enable for Brightmail Filter 150 serial numbers, licensing 210 Settings, available 199 spam custom rules about 172, 174 configuring 175 deleting 181 enabling and disabling 175 submission aggressiveness 178 submitter ID 176 submitters 179 submitting messages 172, troubleshooting 174 Specifying Allowed and Blocked Senders 185 internal mail hosts 208 Subdomain expansion 187 subm-config allowedlist command 222 subm-config blockedlist command 223 subm-config command 218 subm-config configuration command 224 subm-config displaylist command 225 subm-config msg command 226 subm-config msginfo command 227 subm-config provisioning 228 subm-config rawmsg command 230 subm-config report command 231 subm-config rule command 233 subm-config ruleinfo command 234 subm-config servicestatus command 235 subm-config submissionpolicy command 240 subm-config submitnotspam command 238 subm-config submitspam command 236 Supported methods for identifying senders 187 suspicious URL 168 V View Brightmail Scanner logs 214 Viewing and saving logs 214 X X-Headers 36