Using Symantec Brightmail Anti-Spam
The Brightmail solution consists of the Brightmail server along with realtime anti-spam and anti-virus rule updates downloaded to email servers. In addition to the sections below, refer to .
How Brightmail Works
The Brightmail server is deployed at a customer site. Brightmail has email probes set around the Internet for detection of new spam. Brightmail technicians create custom rules to block this spam in realtime. These rules are downloaded to Brightmail servers, also in realtime. The Brightmail database is updated and Brightmail server runs this database filter against the email for the specified users or domains.
Brightmail Architecture
Figure 14–1 depicts the Brightmail architecture.
Figure 14–1 Brightmail and Messaging Server Architecture
When the Brightmail Logistics and Operations Center (BLOC) receives spam from email probes, operators immediately create appropriate spam filtering rules, which are downloaded to Brightmail customer machines. Similarly, the Symantec Security Response realtime virus rules are also sent from Brightmail. These rules are used by customer’s Brightmail servers to catch spam and viruses.
The MTA uses the Brightmail SDK to communicate with the Brightmail Server. The MTA dispatches messages based on the response from Brightmail. After the mail (1a) or (1b) is received by the MTA, the MTA sends the message to the Brightmail server (2). The Brightmail server uses its rules and data to determine if the message is a spam or virus (3), and returns a verdict to the MTA. Based on the verdict, the MTA either (4a) discards the message or files the message into a folder, or (4b) delivers it normally to the destination.
Since the Brightmail SDK is third party software, we do not include it in our installation kit. The Brightmail SDK and server software must be obtained from Brightmail Inc. The MTA has configuration settings to tell it whether and where to load the Brightmail SDK to enable Brightmail integration.
Once the SDK is loaded, Brightmail message processing is determined by several factors and levels of granularity (the term used by Brightmail to specify active processing is optin). This is specified by the following criteria:
-
Whether the source or destination channel is enabled for Brightmail (imta.cnf)
-
Whether there is a channel default for the services opted in (imta.cnf)
-
Whether there is a per domain optin (LDAP)
-
Whether there is per-user optin (LDAP)
For any particular message recipient, the optins and defaults above are combined, which means, if the channel default is already specified for both spam and virus, then there is no reason to bother with per-user optin. That is, if the system administrator decides to do spam and virus filtering for everyone, then there is no reason to expose to the user the ability to optin for spam or virus. There is no way to opt out of processing, that is, you can not say you do not want the service if a user is already optin via a system or domain optin. This also means that if you are optin for a service, and you have forwarded your mail to another address, that address would get the mail after the filtering has been performed on your behalf.
There are only two services offered, virus or spam detection. Brightmail also provides “content-filtering” service, but this functionality is provided using Sieve, so there is no added value to have Brightmail do the Sieve filtering.
When a message is determined to contain a virus, the Brightmail server can be configured to clean the virus and resubmit the cleaned message back to the MTA. (Due to some undesirable side effects caused by loss of information about the original message in a resubmitted cleaned message, we recommend you do not configure Brightmail to resubmit the cleaned message back to the MTA.) When the message is spam, the verdict back from the Brightmail along with the configuration in Brightmail allows the MTA to determine what happens to the message. The message can be discarded, filed into a folder, tagged as spam or virus on the subject line, passed to a Sieve rule, delivered normally in the INBOX, and so on.
The Brightmail servers can be located on the same system as the MTA, or it can be on a separate system. In fact, you can have a farm of Brightmail servers serving one or more MTAs. The Brightmail SDK uses the Brightmail configuration file to determine which Brightmail servers to use.
Brightmail Requirements and Performance Considerations
-
Brightmail servers must run on the Solaris Operating System.
-
If Brightmail does spam and virus checking, MTA message throughput can be reduced by as much 50%. To keep up with MTA throughput, you may need two Brightmail servers for each MTA.
-
While SpamAssassin has the ability to perform different sorts of filtering on a user basis, it is unable to apply two different sets of filtering criteria to the same message at the same time. Thus, SpamAssassin only allows system-wide filtering. Customized filtering for individual users is not possible.
Deploying Brightmail
Perform the following steps to deploy Brightmail.
-
Install and Configure Brightmail. Refer to the Brightmail software documentation or representative for installation and configuration information. Selected Brightmail configuration options are shown in Brightmail Configuration Options, however the most complete and up-to-date information is in the Brightmail documentation.
-
Load and Configure the Brightmail Client Library. This involves specifying the Brightmail client library, libbmiclient.so, and configuration, config, file to the MTA. See Loading and Configuring the Spam Filtering Software Client Library
-
Specify what messages to filter for spam. Messages can be filtered by user, domain, or channel. See Specifying the Messages to Be Filtered
-
Specify what actions to take on spam messages. Spam can be discarded, filed into a folder, tagged on the subject line, and so on. See Specifying Actions to Perform on Spam Messages
-
Set miscellaneous MTA filter configuration parameters as desired. See Table 14–2.
Brightmail Configuration Options
Selected Brightmail configuration file options are shown in Table 14–3. The most complete listing of Brightmail configuration file options can be obtained from Brightmail. Options and values are not case-sensitive.
Table 14–3 Selected Brightmail Configuration File Options|
Brightmail Option |
Description |
|---|---|
|
A given message can have multiple verdicts. This specifies the precedence order. So if a message is processed for virus first, then for spam if you specified this option as virus-spam the verdicts are separated by hyphens (-). This is the recommended setting when using Brightmail with Sun Java System Messaging Server. |
|
|
Specifies how to deliver normal messages, that is, not a spam or virus, and thus have no verdict. Usually you want to deliver this message normally, so you would specify inbox as the value. There is no default. |
|
|
This attribute specifies what domain(s) are considered to be local. There can be multiple lines of this attribute specifying several domains which are all considered local. Local versus foreign domain is used to specify two different handling for a verdict. See below blSWClientDestinationLocal and blSWClientDestinationForeign. For example, you can specify blSWLocalDomain=siroe.com |
|
|
This specifies the verdict and action pair for the local domain. You would normally have two lines for this, one for spam and one for virus. The value is of the form verdict|action, For example, blSWClientDestinationLocal=spam|spambox blSWClientDestinationLocal=virus| The default Brightmail interpretation for the “null” action, meaning nothing to the right of the |, is to discard the message. So the example above discards the message if it has a verdict of virus. And if the verdict is spam, the above example files the message into the folder called spambox. If the message is not spam or virus, then the verdicts do not match, and the mail is delivered normally based on what’s set in the blSWClientDestinationDefault setting above. When using a separate Brightmail server or servers from the MTA, you can customize the actions taken by each MTA by using the Brightmail_verdict_n, Brightmail_action_n, Brightmail_null_action, and Brightmail_string_action MTA options to override the actions and verdicts returned by the Brightmail server. In this example, you can use different Brightmail_null_action on the MTA to override the Virus action (which would be to discard it) or to use Brightmail_verdict_0=spambox, and Brightmail_action_0=data:,require "fileinto";fileinto "Junk"; to file into a folder called Junk instead of spambox. |
|
|
Same format and interpretation as blSWClientDestinationLocal above, except this applies to users in the domain which are NOT local. |
|
|
Always set this to TRUE when used with Sun Java System Messaging Server. |
|
|
Is of the form ip:port[,ip:port,...] to specify one or more Brightmail server’s IP address and port numbers |
- © 2010, Oracle Corporation and/or its affiliates