|
| |
| Sun Java System Messaging Server 6 2004Q2 Administration Guide | |
Chapter 14
Integrating Anti-spam and Anti-virus ProgramsThis chapter describes how to integrate and configure the Brightmail and SpamAssassin anti-spam/anti-virus programs using the software hooks provided by Messaging Server.
Note
In this chapter, references to anti-spam features also mean, when applicable, anti-virus features. Brightmail offers both anti-spam and anti-virus features. SpamAssassin only offers anti-spam.
From the perspective of Messaging Server, most anti-spam solutions do much the same thing. Messaging Server sends copies of messages to the anti-spam software which analyzes a message and returns a verdict of spam, not spam. (SpamAssassin also returns a verdict along with a spam score, which is a numerical rating of the probability of a message being spam.) Messaging Server reads the verdict and takes some type of action using a Sieve script. This chapter describes the hooks provided by Messaging Server to use these commercial anti-spam programs as well as configuration examples.
This chapter is divided in to the following sections:
Deploying and Configuring Third Party Anti-spam ProgramsIn terms of deployment and configuration of third party anti-spam programs, there are only a few administrator decisions required. These decisions are as follows:
Specifying the Messages to Be Filtered
Messaging Server provides a number ways to specify which messages should be filtered. The system can be configured to filter messages by user, domain, or channel. This section contains the following sections:
To Specify User-level Filtering
It is possible to specify which users receive spam filtering. An example of this type of usage would be if anti-spam or anti-virus filtering was offered as a premium service to ISP customers. The general steps for specifying user-level filtering is as follows:
- Specify the LDAP attribute that activates spam filter processing on specified users with the LDAP_OPTIN in the option.dat file:
LDAP_OPTIN=mailAntiUBEService
- Set mailAntiUBEService in the user entries to receive spam filtering.
The values for mailAntiUBEService will depend on the server. For Brightmail, the valid values are spam (filter for spam) and virus (filter for viruses). For SpamAssassin, it can be any string, but spam is recommended for clarity. When used as a multi-valued attribute (Brightmail), each value requires a separate attribute value entry. For example:
mailAntiUBEService: spam
mailAntiUBEService: virusExample
This example assumes Brightmail is being used. It also assumes that LDAP_OPTIN was set to mailAntiUBEService in the option.dat file. The user, Otis Fanning, has the mailAntiUBEService attribute set to spam and virus in his user entry. His mail will be filtered for spam and viruses. Code Example 14-3 shows the Brightmail enabled user entry for Otis Fanning.
If SpamAssassin was used, the entry would be the same, but without mailAntiUBEService: virus. See the section in this chapter describing your third-party software for more examples and details.
To Specify Domain-level Filtering
It is possible to specify which domains receive spam filtering. An example of using this feature would be if anti-spam or anti-virus filtering was offered as a premium service to ISP domain customers. The general steps for specifying domain-level filtering is as follows:
- Specify the LDAP attribute that activates spam filter processing on specified domains with the LDAP_OPTIN in the option.dat file.
LDAP_DOMAIN_ATTR_OPTIN=mailAntiUBEService
- Set mailAntiUBEService in the domain entries to receive spam filtering.
Valid values for mailAntiUBEService depend on the server. For Brightmail, the valid values are spam (filter for spam) and virus (filter for viruses). For SpamAssassin, it can be any string, but spam is recommended for clarity. When used as a multi-valued attribute (Brightmail), each value requires a separate attribute value entry. For example:
mailAntiUBEService: spam
mailAntiUBEService: virusDomain-level Filtering Example
This example assumes Brightmail is being used. It also assumes that LDAP_DOMAIN_ATTR_OPTIN was set to mailAntiUBEService in the option.dat file. The mailAntiUBEService attribute is set to spam and virus in the sesta.com domain entry in the DC tree for Sun LDAP Schema 1. For Sun LDAP Schema 2 you would also set mailAntiUBEService in the domain entries to receive spam filtering.
All mail sent to sesta.com is filtered for spam and viruses by Brightmail. Code Example 14-4 shows the domain entry.
Code Example 14-2 Example LDAP Domain Entry for Brightmail
dn: dc=sesta,dc=com,o=internet
objectClass: domain
objectClass: inetDomain
objectClass: mailDomain
objectClass: nsManagedDomain
objectClass: icsCalendarDomain
description: DC node for sesta.com hosted domain
dc: sesta
inetDomainBaseDN: o=sesta.com,o=isp
inetDomainStatus: active
mailDomainStatus: active
mailDomainAllowedServiceAccess: +imap, pop3, http:*
mailRoutingHosts: manatee.siroe.com
preferredMailHost: manatee.siroe.com
mailDomainDiskQuota: 100000000
mailDomainMsgQuota: -1
mailClientAttachmentQuota: 5
mailAntiUBEService: spam
mailAntiUBEService: virus
If SpamAssassin was used, the entry would be the same, but without mailAntiUBEService: virus. See the section in this chapter describing your particular third-party software for more examples and details.
To Specify Channel-level Filtering
Specifying spam filtering by user or domain is an obvious criteria, but specifying by channel is less obvious. The reason to specify filtering by source or destination channel is to provide greater flexibility and granularity for spam filtering.
Messaging Server allows you to specify filtering by source or destination channel. The mechanism for doing this are the channel keywords described in Table 14-1. The following example demonstrates how to set up channel-level filtering.
- Add a rewrite rule in the imta.cnf file for all inbound SMTP servers that sends messages to a specific backend message store host. Example:
msg_store1.siroe.com $U@msg_store1.siroe.com
- Add a channel corresponding to the rewrite rule with the destinationspamfilteroptin keyword. Example:
tcp_msg_store1 subdirs 20 backoff “pt5m” “pt10” “pt30” “pt1h” \
“pt2h” “pt4h” maxjobs 1 pool IMS_POOL fileinto $U+$S@$D \
destinationspamfilteroptin spam
msg_store1.siroe.com
Table 14-1 MTA Channel Keywords for Spam Filters
Channel Keyword
Description
destinationspamfilteroptin
Specifies that all messages destined to this channel are filtered even if those services are not specified by the user or domain with the LDAP_OPTIN LDAP attribute. The filter parameters follow the keyword. The available parameters depend on the filtering program. For example, Brightmail parameters are spam or virus or spam,virus. The SpamAssassin parameter is spam..
In this example, all mail destined for the message store is scanned for spam and virus by Brightmail:ims-ms destinationspamfilteroptin spam,virus. . .
sourcespamfilteroptin
Specifies that all messages originating from this channel are filtered even if those services are not specified by the user or domain with the LDAP_OPTIN LDAP attribute.The system-wide default parameters follow the keyword, and the available parameters depend on the filtering program. For example, for Brightmail parameters are spam or virus or spam,virus. For SpamAssassin, the parameter is spam. If switchchannel is in effect, this keyword is placed on the switched-to channel.
Channel-level Filtering Examples
Example 1. Use Brightmail to filter all mail for spam and viruses from an MTA relay to a backend message store called siroemail. A rewrite rule is setup to send these messages through an MTA channel called tcp_siroemail:
- Add a rewrite rule in the imta.cnf file that sends messages to a backend message store host. Example:
msg_store1.siroe.com $U@msg_store1.siroe.com
- Add a channel corresponding to that rewrite rule with the destinationspamfilteroptin keyword. Example:
tcp_msg_store1 subdirs 20 backoff “pt5m” “pt10” “pt30” “pt1h” \
“pt2h” “pt4h” maxjobs 1 pool IMS_POOL fileinto $U+$S@$D \
destinationspamfilteroptin spam, virus
msg_store1.siroe.comExample 2. Filter all incoming mail passing through your MTA:
tcp_local smtp mx single_sys remotehost inner switchchannel \
identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL \
maytlsserver maysaslserver saslswitchchannel tcp_auth \ sourcespamfilteroptin spam
tcp-daemonExample 3. Filter all outgoing (to the internet) mail passing through your MTA:
tcp_local smtp mx single_sys remotehost inner switchchannel \
identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL \
maytlsserver maysaslserver saslswitchchannel tcp_auth \ destinationspamfilteroptin spam
tcp-daemonExample 4. Filter all incoming and outgoing mail passing through your MTA:
tcp_local smtp mx single_sys remotehost inner switchchannel \
identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL \
maytlsserver maysaslserver saslswitchchannel tcp_auth \ sourcespamfilteroptin spam destinationspamfilteroptin spam
tcp-daemonExample 5. Filter mail of users or domains with the mailAntiUBEService attribute destined to the local message store:
tcp_local smtp mx single_sys remotehost inner switchchannel \
identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL \
maytlsserver maysaslserver saslswitchchannel tcp_auth \
destinationspamfilteroptin spam
tcp-daemonExample 6. Filter all mail destined to the local message store in a two-tiered system without using per-user optin:
ims-ms smtp mx single_sys remotehost inner switchchannel \
identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL \
maytlsserver maysaslserver saslswitchchannel tcp_auth \
destinationspamfilteroptin spam
tcp-daemonExample 7. Use Brightmail to filter all incoming and outgoing mail for spam and viruses:
tcp_local smtp mx single_sys remotehost inner switchchannel \
identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL \
maytlsserver maysaslserver saslswitchchannel tcp_auth \
destinationspamfilteroptin spam,virus sourcespamfilteroptin \
spam,virus
tcp-daemonSpecifying Actions to Perform on Spam Messages
As discussed earlier, anti-spam programs analyze messages and return a verdict of spam or not spam to Messaging Server. Messaging Server then takes action on the message. Anti-spam programs typically return a string or a null value to the MTA to indicate that message is spam. Some programs also return a spam score—a number rating the probability of the message being spam or not. This score can be used as part of the action sequence.
Actions are specified using the Sieve mail filtering language. Possible Sieve actions are to discard the message, file it into a folder, add a header, add a tag to the subject line, and so on. Complex Sieve scripts with if-then-else statements are also possible. Refer to RFC 3028 for the complete Sieve syntax.
Sieve scripts are specified with the MTA spam filter options described in Table 14-2. The primary spam filter action options are Spamfilter_null_action, which specifies the Sieve rule to execute when a null value is returned as the spam verdict value, and Spamfilter_null_action, which specifies the Sieve rule to execute when a string is returned as the spam verdict. Both values must be stored in option.dat.
Example 1: This option line files spam messages with a null verdict value to the file SPAM_CAN.
spamfilter_null_action=data:,require "fileinto"; fileinto "SPAM_CAN”;
The same action can be performed on a spam message that returns a string:
spamfilter_string_action=data:,require "fileinto"; fileinto "SPAM_CAN”;
Example 2: This option line files spam messages with a string verdict into a file named after that verdict string returned to the MTA (this is what $U does). That is, if the verdict string returned is spam, the message is stored in a file called spam.
spamfilter_null_action=data:,require "fileinto"; fileinto "$U”;
Example 3: This line discards spam messages with a string verdict value.
spamfilter_string_action=data:,discard
Example 4. The line below adds the header Spam-test: FAIL to each message determined to be spam a string verdict value.
spamfilter_string_action=data:,require ["addheader"];addheader "Spam-test: FAIL”;
Example 5. The line below adds the string [PROBABLE SPAM] to the subject line of the spam messages.
spamfilter_string_action=data:,addtag “[PROBABLE SPAM]”;
Example 6. This line assumes a string verdict value and files a spam message in the mailbox testspam if the header contains resent-from and User-1. If it does not have that header, it simply files the message into spam.
spamfilter_string_action=data:,require "fileinto";\
if header :contains ["resent-from"] ["User-1"] {\
fileinto "testspam";\
} else {\
fileinto "spam";};
Because verdict strings are configurable with most spam filter software, you can specify different actions depending on the string returned. This can be done with the matched pairs spamfilter_verdict_n and spamfilter_action_n options.
Example 7. These matched pair options discard spam messages with the returned verdict string remove. Refer to the specific spam filter sections for instructions on how to specify the spam verdict string.
spamfilter_verdict_0=kill
spamfilter_action_0=data:,discard
Table 14-2 MTA Spam Filter Options (options.dat)
MTA Options for Spam Assassin
Description
Spamfilter_config_file
Full file path and name of the SpamAssassin configuration file.
Default: noneSpamfilter_library
Full file path and name of the SpamAssassin shared library.
Default: noneSpamfilter_optional
Controls whether certain failures reported by the filtering library are treated as a temporary processing failure or ignored. The default value of 0 specifies that spam filtering problems will cause a temporary processing failure. Changing the value to 1 causes spam filter processing to be skipped in the event of some, but possibly not all, filtering library failures. (In particular, if the system gets stuck without a return in the library code, some portion of the MTA may also get stuck.)
Default: 0
LDAP_optin
The name of the LDAP attribute used to activate SpamAssassin on a per-user basis. This should1 be an attribute in the inetMailUser objectclass. If you do not have predefined attribute, use mailAntiUBEService.
The attribute itself (example: mailAntiUBEService) can take multiple values and is case-sensitive. For SpamAssassin, its value should be spam in lowercase.
Default: none
LDAP_domain_attr_optin
The name of the LDAP attribute used to activate SpamAssassin on a per-domain basis. It applies to the destination domain. It is just like LDAP_optin, described above, except it should be in the objectclass mailDomain.
Default: none
Spamfilter_null_optin
Specifies a string, which if found as a value of the attribute mailantiUBEservice, causes the MTA to act as if the attribute wasn’t there. That is, it disables filtering for that entry. See Specifying Which Messages Will Be Filtered by SpamAssassin for usage details.
Default: The empty string. Empty optin attributes are ignored by default. (This is a change from iPlanet Messaging Server 5.2, where empty optin attributes triggered filtering with an empty optin list. The 5.2 behavior can be restored by setting SPAMFILTER_NULL_OPTIN to a string that never occurs in practice.)
Spamfilter_null_action
Sieve rule specifying what to do with the message when the SpamAssassin verdict returns as null. Sieve expressions can be stored externally using a file URL. For example: file:///var/opt/SUNWmsgsr/config/null_action.sieve. Also, do not reject spam using the Sieve reject action, as it tends to deliver a nondelivery notification to the innocent party whose server has been used to send the spam. that has been used to send the spam.
Default: data:,discard;Spamfilter_string_action
Sieve rule specifying what to do with the message if the verdict is a string. Sieve expressions can be stored externally using a file URL. For example: file:///var/opt/SUNWmsgsr/config/null_action.sieve. Also, do not reject spam using the Sieve reject action, as it tends to deliver a nondelivery notification to the innocent party whose server has been used to send the spam. that has been used to send the spam.
Default: data:,require "fileinto"; fileinto "$U;
where $U is the string that verdict returned.
spamfilter_verdict_n
spamfilter_verdict_n and spamfilter_action_n are matched pairs, where n is a number from 0 to 9. These options allow you to specify Sieve filters for arbitrary verdict strings. This is done by setting spamfilter_verdict_n and spamfilter_action_n to the verdict string and sieve filter, respectively, where n is an integer from 0 to 9. For example, a site could have the "reject" verdict cause a sieve reject action by specifying:
spamfilter_verdict_0=reject
spamfilter_action_0=data:,require "reject"; reject "Rejected by spam filter";The default values for all of the spamfilter_verdict_0 options and the corresponding action options are empty strings.
Default: none
spamfilter_action_n
See spamfilter_verdict_n.
Default: none
spamfilter_final
Some filtering libraries have the ability to perform a set of actions based on recipient addresses. spamfilter_final specifies the sort of recipient address passed to the filtering library. 0 results in a so-called intermediate address being used; 1 sends the final form of the recipient address.
Default: 0
optin_user_carryover
Forwarding is a challenge for spam filter processing. Consider a user entry that specifies the forward delivery option and specifies the forwarding address of another user. Additionally, the user entry opts in to some specific sort of filtering. Should the filtering be applied to the forwarded message or not? On the one hand, the correct filtering choice for one particular user may not be the correct choice for another. On the other hand, eliminating a filtering operation might be used as means of violating a site’s security policy.
No single answer is correct in all cases so OPTIN_USER_CARRYOVER, controls how the spam filtering optin list is carried from one user/alias entry to another when forwarding occurs. This is a bit-encoded value. The various bit values have the following meanings:
bit 0 (value 1). Each LDAP user entry override any previously active user/domain optins unconditionally.
bit 1 (value 2). If a user’s domain has an optin attribute, it overrides any previous user/domain/alias optins that were active.
bit 2 (value 4). If a user has an optin attribute, it overrides any previous user/domain/alias optins that were active.
bit 3 (value 8). An optin specified by an [optin] non-positional parameter overrides any previous user/domain/alias optins that were active.
Default: 0 (optins will accumulate if one user has a delivery option that forwards to another. The default insures that site security policies will be effective when forwarding; other settings may not.)
Using BrightmailBrightmail Inc. is a company that provides an anti-spam and anti-virus software solution for email servers. The Brightmail solution consists of the Brightmail server along with realtime anti-spam and anti-virus rule updates downloaded to email servers.
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 anti-spam 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 back 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 back 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:
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 implements both 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 per-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
This section describes how to deploy Brightmail for the following configurations:
Brightmail filtering is enabled in Messaging Server using the channel or an LDAP attribute. The method of filtering on the system is additive. That is, it is the combination of both keywords and the attribute.
To Activate Brightmail Processing for Users on a Destination or Source Channel
- Install and Configure Brightmail server.
To install Brightmail on your system, see your Brightmail representative.
- Set the Brightmail Library and Configuration File Parameters by adding the following two MTA options to the options.dat file:
spamfilter_Library=path_and_filename_of_libbmiclient.so
spamfilter_config_file=path_and_filename_of_brightmail_config_file- Specify the desired Brightmail options in the MTA options file (Table 14-2) and Brightmail configuration file (Table 14-3).
- Specify the channels and email direction (source or destination) on which Brightmail processing will occur.
Set the keyword sourcespamfilteroptin or destinationspamfilteroptin on a channel block (see To Specify Channel-level Filtering and The MTA Configuration File)
sourcespamfilteroptin specifies that every message coming from the channel be processed by Brightmail software.
destinationspamfilteroptin specifies that every message going to the channel be processed by Brightmail software.
Valid values for these attributes are as follows:
spam - filter for spam
virus - filter for viruses
spam,virus - filter for spam and virusesExamples
Example 1. Filter mail coming from an incoming MTA relay and going to a specific backend message store called siroe for spam and viruses. The messages will pass through the MTA channel called tcp_siroemail:
Example 2. Filter all incoming mail going through your MTA. from the tcp_local channel will be filtered by the Brightmail for spam:
To Activate Brightmail Processing for Selected Users
- Install and configure Brightmail software.
To install Brightmail on your system, see your Brightmail representative.
- Set the Brightmail library and configuration file parameters.
Use the following two MTA options in the options.dat file:
spamfilter_Library=path_and_filename_of_libbmiclient.so
spamfilter_config_file=path_and_filename_of_brightmail_config_file- Specify the desired Brightmail options in the MTA options file (Table 14-2) and Brightmail configuration file (Table 14-3).
- Specify the LDAP attribute that will be used to activate Brightmail processing on specified users.
Set LDAP_OPTIN=mailAntiUBEService in the option.dat file. It is possible to specify an LDAP attribute other than mailAntiUBEService, but we recommend using this name.
- Set LDAP attribute mailAntiUBEService in the user entries to receive Brightmail processing.
Valid values for mailAntiUBEService are spam (filter for spam) and virus (filter for viruses).
Example
Assume that LDAP_OPTIN was set to mailAntiUBEService in the option.dat file. If the user, Otis Fanning, has the mailAntiUBEService attribute set to spam and virus in his user entry, then his mail will be filtered by Brightmail for spam and viruses. Code Example 14-3 shows the Brightmail enabled user entry for Otis Fanning.
Code Example 14-3 Example LDAP User Entry for Brightmail
dn: uid=fanning,ou=people,o=sesta.com,o=ISP
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: inetUser
objectClass: ipUser
objectClass: inetMailUser
objectClass: inetLocalMailRecipient
objectClass: nsManagedPerson
objectClass: userPresenceProfile
cn: Otis Fanning
sn: fanning
initials: OTF
givenName: Otis
pabURI: ldap://ldap.siroe.com:389/ou=fanning,ou=people,o=sesta.com,o=isp,o=pab
mail: Otis.Fanning@sesta.com
mailAlternateAddress: ofanning@sesta.com
mailDeliveryOption: mailbox
mailHost: manatee.siroe.com
uid: fanning
dataSource: iMS 5.0 @(#)ims50users.sh 1.5a 02/3/00
userPassword: password
inetUserStatus: active
mailUserStatus: active
mailQuota: -1
mailMsgQuota: 100
mailAntiUBEService: virus
mailAntiUBEService: spam
To Activate Brightmail Processing for Selected Domains on a System
- Install and configure Brightmail software.
To install Brightmail on your system, see with your Brightmail representative.
- Set the Brightmail library and configuration file parameters.
Set the following two MTA options in the options.dat file:
spamfilter_Library=path_and_filename_of_libbmiclient.so
spamfilter_config_file=path_and_filename_of_brightmail_config_file- Specify the desired Brightmail options in the MTA options file (Table 14-2) and Brightmail configuration file (Table 14-3).
- Specify the LDAP attribute that will be used to activate Brightmail processing on specified domains.
Set LDAP_DOMAIN_ATTR_OPTIN=mailAntiUBEService in the option.dat file. It is possible to specify a different LDAP attribute name, but we recommend using this name so that the Messaging Server schema remains consistent.
- Set the LDAP attribute mailAntiUBEService in the domain entries (in the DC tree) whose email will receive Brightmail processing.
Valid values for mailAntiUBEService are spam (filter for spam) and virus (filter for viruses).
Example
Assume that LDAP_DOMAIN_ATTR_OPTIN was set to mailAntiUBEService in the option.dat file. The mailAntiUBEService attribute is set to spam and virus in the example.com domain entry in the DC tree. Code Example 14-4 shows the Brightmail-enabled domain entry.
Code Example 14-4 Example LDAP Domain Entry for Brightmail
dn: dc=sesta,dc=com,o=internet
objectClass: domain
objectClass: inetDomain
objectClass: mailDomain
objectClass: nsManagedDomain
objectClass: icsCalendarDomain
description: DC node for sesta.com hosted domain
dc: sesta
inetDomainBaseDN: o=sesta.com,o=isp
inetDomainStatus: active
mailDomainStatus: active
mailDomainAllowedServiceAccess: +imap, pop3, http:*
mailRoutingHosts: manatee.siroe.com
preferredMailHost: manatee.siroe.com
mailDomainDiskQuota: 100000000
mailDomainMsgQuota: -1
mailClientAttachmentQuota: 5
mailAntiUBEService: spam
mailAntiUBEService: virus
Example Brightmail Deployment Scenarios
There are several common deployment Brightmail scenarios that are discussed in this section. In each case you will do the standard Brightmail configuration procedures like install Brightmail and specify the library and configuration files, (see previous sections). This section describes the following deployment scenarios:
Brightmail Processing on Local Incoming Messages
You may wish to configure your system so that all mail delivered locally is screened for spam and viruses. To set up Brightmail processing of all incoming messages to the local message store (that is, to the ims-ms channel in imta.cnf), add the destinationspamfilteroptin keyword to the ims-ms channel definition. Example:
ims-ms defragment subdirs 20 backoff “pt5m” “pt10” “pt30” “pt1h” \
“pt2h” “pt4h” maxjobs 1 pool IMS_POOL fileinto $U+$S@$D filter \
ssrd:$A ims-ms-daemon destinationspamfilteroptin spam,virus
ims-ms-daemonBrightmail Processing on Incoming Messages from the Internet
You may wish to configure your system so that all mail coming from the internet is screened for spam. To set up Brightmail processing of all incoming messages from the internet, add the sourcespamfilteroptin keyword to the tcp-local channel definition. Example:
tcp_local smtp mx single_sys remotehost inner switchchannel \
identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver \
maysaslserver saslswitchchannel tcp_auth sourcespamfilteroptin spam
tcp-daemon
Note
Brightmail allows you to either discard spam messages, or save them in a designated spam folder. If the ability to designate a spam folder is not available for the receiving system, then the address syntax for the spam folder will be meaningless to that system.
Brightmail Processing on Outgoing Messages to the Internet
You may wish to configure your system so that all mail going to the internet is screened for spam. To set up Brightmail processing of all outgoing messages to the internet, add the destinationspamfilteroptin keyword to the tcp-local channel definition on the outgoing MTA. Example:
tcp_local smtp mx single_sys remotehost inner switchchannel \
identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver \
maysaslserver saslswitchchannel tcp_auth \
destinationspamfilteroptin spam
tcp-daemonBrightmail Processing on Incoming Messages to a Specific Backend Message Store Host
To configure your system so that all mail coming into a specific backend message store host is screened for virus and spam, do the following:
- Add a rewrite rule in the imta.cnf file of all inbound SMTP servers that will send messages to the backend message store host. Example:
msg_store1.siroe.com $U@msg_store1.siroe.com
- Add a channel corresponding to that rewrite rule with the destinationspamfilteroptin keyword. Example:
tcp_msg_store1 subdirs 20 backoff “pt5m” “pt10” “pt30” “pt1h” \
“pt2h” “pt4h” maxjobs 1 pool IMS_POOL fileinto $U+$S@$D \
destinationspamfilteroptin spam,virus
msg_store1.siroe.comAdding a Header to Spam Messages
You can add an arbitrary header to a spam message. To add the header spam-result: Brightmail says this is spam to a message caught by Brightmail software, add the following to option.dat:
spamfilter_string_action=data:,require ["addheader" "spamtest"];addheader "spam-result: Brightmail says this is spam";
Only the text after "spamtest"]; are customizable.
Brightmail Configuration Options
Selected Brightmail configuration file options are shown in Table 14-3. The latest and complete listing of Brightmail configuration file options can be obtained from Brightmail.
Table 14-3 Selected Brightmail Configuration File Options
Brightmail Option (Not Case-sensitive)
Description (value of the attributes are case-sensitive)
blSWPrecedence
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.
blSWClientDestinationDefault
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.
blSWLocalDomain
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
blSWClientDestinationLocal
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/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.
blSWClientDesintationForeign
Same format and interpretation as blSWClientDestinationLocal above, except this applies to users in the domain which are NOT local.
blSWUseClientOptin
Always set this to TRUE when used with Sun Java System Messaging Server.
blswcServerAddress
Is of the form ip:port[,ip:port,...] to specify one or more Brightmail server’s IP address and port numbers
Using SpamAssassinThis section consists of the following subsections:
SpamAssassin Overview
Messaging Server supports the use of SpamAssassin, a freeware mail filter used to identify spam. SpamAssassin consists of a library written in Perl and a set of applications and utilities that can be used to integrate SpamAssassin into messaging systems.
SpamAssassin calculates a score for every message. Scores are calculated by performing a series of tests on message header and body information. Each test either succeeds or fails, and a verdict of true (spam) or false (not spam) is rendered. Scores are real numbers that can be positive or negative. Scores that exceed a specified threshold, typically 5.0, are considered to be spam. An example of a SpamAssassin result string would be as follows:
True ; 18.3 / 5.0
True indicates the message is spam. 18.3 is the SpamAssassin score. 5.0 is the threshold.
SpamAssassin is highly configurable. Tests may be added or removed at any time, and the scores of existing tests can be adjusted. This is all done through various configuration files. Further information on SpamAssassin can be found on the SpamAssassin web site.
The same mechanism used for calling out to the Brightmail spam and virus scanning library can be used to connect to the SpamAssassin spamd server. The module provided in Sun Java System Messaging Server is called libspamass.so.
Note
In previous versions of Messaging Server, option names and channel keywords contained the word brightmail, for example, sourcebrightmail or brightmail_library. The word brightmail is now replaced with the more general spamfilter, although the old names are still valid for backwards compatibility.
SpamAssassin/Messaging Server Theory of Operations
spamd is the daemon version of SpamAssassin and can be invoked from the MTA. spamd listens on a socket for requests and spawns a child process to test the message. The child process dies after processing the message and sending back a result. In theory, the forking should be an efficient process, because the code itself is shared among the children processes.
The client portion, spamc from the SpamAssassin installation, is not used. Instead, its function is done by a shared library called libspamass.so, which is part of the Messaging Server. libspamass.so is loaded the same way that the Brightmail SDK is loaded.
From the MTA’s point of view, you can almost transparently switch between SpamAssassin and Brightmail for spam filtering. It’s not completely transparent, because they do not have same functions. For example, Brightmail can also filter for viruses, but SpamAssassin is only used to filter for spam. The result, or verdict, returned by the two software packages are also different. SpamAssassin provides a score, while Brightmail provides just the verdict name, so the configuration would also have some differences.
When using SpamAssassin integrated with the MTA, only a score and verdict is returned from SpamAssassin. The message itself is not modified by SpamAssassin. That is, options such as adding headers and modifying subject lines must be done by Sieve scripts.
SpamAssassin Requirements and Usage Considerations
- SpamAssassin is free. Go to http://www.spamassassin.org for software and documentation.
- SpamAssassin can be tuned and configured to provide very accurate detection of spam. The tuning of SpamAssassin is up to you and the SpamAssassin community. Messaging Server does not provide or enhance what SpamAssassin can do.
- While no specific numbers are available, SpamAssassin seems to reduce throughput more than Brightmail.
- SpamAssassin integrated with the MTA can be enabled for a user, for a domain, or for a channel.
- SpamAssassin can be configured to use other online databases such as Vipul’s Razor or Distributed checksum clearinghouse (DCC).
- Messaging Server does not supply an Secure Socket Layer (SSL) version of libspamass.so, however, it is possible to build SpamAssassin to use openSSL.
- Perl 5.6 or later is required.
Where Should You Run SpamAssassin?
SpamAssassin can run on a separate system of its own, on the same system as the Messaging Server in a single system deployment, or on the same system as the MTA in a two-tier deployment. If Local Mail Transfer Protocol (LMTP) is used between the MTA and the message store, the filtering must be invoked from the MTA. It cannot be invoked from the message store. When SMTP is used between the MTA and the message store, it can be invoked from either one, and it can run on either system or a separate third system.
If you want to use a farm of servers running SpamAssassin, you would have to use a load balancer in front of them. The MTA is configured with only one address for the SpamAssassin server.
Configuring SpamAssassin
This section describes how to configure SpamAssassin on Messaging Server. It assumes that Perl 5.6 or later and SpamAssassin are installed. Configuring SpamAssassin involves two things:
Specifying Which Messages Will Be Filtered by SpamAssassin
The first part of configuring SpamAssassin is to specify which messages to filter. Filtering can be specified as follows:
To Filter All Messages to the Local Message Store
You may wish to configure your system so that all mail delivered locally be filtered by SpamAssassin. To filter incoming messages to the local message store add destinationspamfilteroptin spam to the ims-ms channel. For example:
ims-ms defragment subdirs 20 backoff “pt5m” “pt10” “pt30” “pt1h” \
“pt2h” “pt4h” maxjobs 1 pool IMS_POOL fileinto $U+$S@$D filter \
ssrd:$A ims-ms-daemon destinationspamfilteroptin spam
ims-ms-daemonTo Filter All Messages Coming from the Internet
To filter all messages coming into your system from the internet, add the sourcespamfilteroptin keyword to the tcp-local channel. For example:
tcp_local smtp mx single_sys remotehost inner switchchannel \
identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver \
maysaslserver saslswitchchannel tcp_auth sourcespamfilteroptin spam
tcp-daemonTo Filter All Messages Going Out to the Internet
To filter all messages from your system going out to the internet, add the destinationspamfilteroptin keyword to the tcp_local channel definition on the outgoing MTA. For example:
tcp_local smtp mx single_sys remotehost inner switchchannel \
identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver \
maysaslserver saslswitchchannel tcp_auth \
destinationspamfilteroptin spam
tcp-daemonTo Filter Messages to a Specific Message Store
To configure your system so that all mail coming into a backend message store host is filtered for spam, do the following:
- Add a rewrite rule in the imta.cnf file for all inbound SMTP servers that will send messages to a specific backend message store host. Example:
msg_store1.siroe.com $U@msg_store1.siroe.com
- Add a channel corresponding to that rewrite rule with the destinationspamfilteroptin keyword. Example:
tcp_msg_store1 subdirs 20 backoff “pt5m” “pt10” “pt30” “pt1h” \
“pt2h” “pt4h” maxjobs 1 pool IMS_POOL fileinto $U+$S@$D \
destinationspamfilteroptin spam
msg_store1.siroe.comTo Filter to a Specific User or Domain
To filter messages for a user or domain, add the following attribute-value pair to the user and domain LDAP entry:
MailAntiUBEService: spam
Also specify the appropriate LDAP_optin value in the option.dat file. For user-level filtering, add the following:
LDAP_optin=mailantiUBEservice
For domain-level filtering add the following:
LDAP_domain_attr_optin=mailAntiUBEService
When activating SpamAssassin in this manner, there is no need to put destinationspamfilter on the channel definition. The attribute name is case-insensitive.
Note
MailAntiUBEService requires any string value to enable filtering. The value spam is used for consistency and clarity. Some deployments may require that all entries have the same set of attributes and a value for each attribute. In this type of deployment, all entries have spam filtering enabled. You can, however, set the MTA option SPAMFILTER_NULL_OPTIN to a string which when set as the value of MailAntiUBEService, will disable filtering.
Specifying What to Do with Spam Messages
The second part of configuring SpamAssassin is to decide what to do with spam messages. Spam can be discarded, rejected, filed, or tagged with a header. This is controlled by a Sieve script specified by the MTA options spamfilter_null_action and spamfilter_string_action. In addition, the SpamAssassin options mode, verdict, and field can be used to specify folder names, header tags and so on. This is described in detail in the following sections.
Note
Sieve is a computer language that can be used to create filters for electronic mail. The examples shown in this section can be used to create your own custom Sieve scripts. Refer to the Sieve specifications that can be found on-line for complete syntax information. A good start is http://www.cyrusoft.com/sieve/
SpamAssassin Configuration Examples
This section describes some common SpamAssassin configuration examples:
- To Add the SpamAssassin Result String to the Subject Line
Note
These examples use a number of options and keywords. Refer to "MTA Channel Keywords for Spam Filters" on page 422 and "MTA Spam Filter Options (options.dat)" on page 426 for details.
To File Spam to a Separate Folder
This example tests messages arriving at the local message store and files spam into a folder called spam. Note that the first three steps can be done in any order.
- Specify the messages to be filtered.
To filter all messages coming into the local message store, change the imta.cnf file by adding the destinationspamfilteroptin spam keywords on the ims-ms channel:
!
! ims-ms
ims-ms defragment subdirs 20 notices 1 7 14 21 28 backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" maxjobs 4 pool IMS_POOL fileinto
$U+$S@$D destinationspamfilteroptin spam
ims-ms-daemon- Create the SpamAssassin configuration file.
The name and location of this file is specified in Step 3. A good name is spamassassin.opt. This file contains the following lines:
host and port specify the name of the system where spamd is running and the port on which spamd listens for incoming requests. mode=0 specifies that a string, specified by verdict (in this case the word spam), will be returned if the message is perceived as spam. debug=1 turns on debugging in the SpamAssassin library.
- Add the following lines to the option.dat file:
spamfilter_config_files specifies the SpamAssassin configuration file.
spamfilter_library specifies the SpamAssassin shared library.
spamfilter_optional=1 specifies that the MTA continue operation if there is a failure by spamd.
spamfilter_string_action specifies the Sieve action to take for a spam messages.
Note that in this example, spamfilter_string_action is not necessary because the default value already is data:,require "fileinto"; fileinto "$U;. This line specifies that spam messages are sent to a folder. The name of the folder is the spam verdict value returned by SpamAssassin. The value returned by SpamAssassin is specified by the verdict option in spamassassin.opt. (See Step 2.) In this case, the folder name is spam.
- Recompile the configuration and restart the server. Only the MTA needs to be restarted. You do not need to execute stop-msg.
spamd -d
spamd defaults to only accepting connections from the local system. If SpamAssassin and Messaging Server are running on different systems, this syntax is required:
spamd -d -i <listen_ip_address> -A <allowed_hosts>
where listen_ip_address is the address on which to listen and allowed_hosts is a list of authorized hosts or networks (using IP addresses) which can connect to this spamd instance.
To Discard Spam
To discard spam instead of filing it into a folder, follow Step 1 and Step 2 as described in "To File Spam to a Separate Folder" on page 444, but change the Spamfilter_string_action option in option.dat as follows:
! for Spamassassin
spamfilter_config_file=/opt/SUNWmsgsr/config/spamassassin.opt
spamfilter_library=/opt/SUNWmsgsr/lib/libspamass.so
spamfilter_optional=1
spamfilter_string_action=data:,discard;
After doing this, recompile the configuration and restart the server. (See Step 4 in "To File Spam to a Separate Folder" on page 444.)
To Add a Simple Header to Spam
This example adds the header Spam-test: spam to each message determined to be spam. Use the same instructions described in Step 1 and Step 2 in "To File Spam to a Separate Folder" on page 444, but add the Spamfilter_string_action in option.dat as follows:
! for Spamassassin
spamfilter_config_file=/opt/SUNWmsgsr/config/spamassassin.opt
spamfilter_library=/opt/SUNWmsgsr/lib/libspamass.so
spamfilter_optional=1
spamfilter_string_action=data:,require ["addheader"];addheader "Spam-test: $U";
The first three options listed above specify the SpamAssassin configuration file (spamfilter_config_file), the SpamAssassin shared library (spamfilter_library), and to continued MTA operation if there is a failure by the shared library (spamfilter_optional=1). The following line specifies that a header of the form Spam-test: spam be added to the message:
spamfilter_string_action=data:,require ["addheader"];addheader "Spam-test: $U";
data:,require ["addheader"];addheader is Sieve sytax for adding headers to messages.
"Spam-test: $U" is the header string. Where “Spam-test: “ is a literal, and $U specifies the string value returned by SpamAssassin. (This is specified by the verdict option in spammassassin.opt, in this case, spam.)
After doing this, recompile the configuration and restart the server. (See Step 4 in "To File Spam to a Separate Folder" on page 444.)
To Add a Header Containing SpamAssassin Score to Spam Messages
This example adds the header Spam-test: result string to messages determined to be spam by SpamAssassin. An example header might be:
Spam-test: True ; 7.3 / 5.0
where Spam-test; is a literal and everything after that is the result string. True means that it is spam (false would be not spam). 7.3 is the SpamAssassin score. 5.0 is the threshold. This result is useful for setting up a Sieve filter that can file or discard mail above or between a certain score.
In addition, setting USE_CHECK to 0will return the list of SpamAssassin tests that matched along with the verdict string. See USE_CHECK in Table 14-4.
- Specify the messages to be filtered. This is described in Step 1 in "To File Spam to a Separate Folder" on page 444
- Create the SpamAssassin configuration file.
The name and location of this file is specified in Step 3. A good name is spamassassin.opt. This file will contain the following lines:
host and port specify the name of the system where spamd is running and the port on which spamd listens for incoming requests. mode=1 specifies that the SpamAssassin result string is returned if the message is found to be spam. field= specifies a string prefix for the SpamAssasin result string. In this example, a prefix is not desired because we are specifying it in the Sieve script. debug=1 turns on the debugging in the SpamAssassin library.
- Add the following lines to the option.dat file:
As in previous examples, the first three options specify the SpamAssassin configuration file, shared library, and to continue MTA operation if there is a failure by the shared library. The following line
spamfilter_string_action=data:,require ["addheader"];addheader "Spam-test: $U";
specifies that a header be added to spam messages. The header will have the literal prefix Spam-text: followed by the string returned by SpamAssassin. Because we specified mode=1 in Step 2, the SpamAssassin result string is returned. For example: True; 7.3/5.0
- Recompile the configuration and restart the server. Only the MTA needs to be restarted, so you don’t need to execute stop-msg.
# imsimta cnbuild
# imsimta restart- Start the spamd daemon. See Step 5 in "To File Spam to a Separate Folder" on page 444.
To Add the SpamAssassin Result String to the Subject Line
By adding the SpamAssassin result string to the Subject line, users can determine whether they wish to read a message with a SpamAssassin score. For example:
Subject: [SPAM True ; 99.3 / 5.0] Free Money At Home with Prescription Xanirex!
Note that setting USE_CHECK to 0 will return the list of SpamAssassin tests that matched along with the verdict string (see USE_CHECK in Table 14-4). This list can be very long, so we recommend setting USE_CHECK to 1.
- Specify the messages to be filtered. See Step 1 in "To File Spam to a Separate Folder" on page 444.
- Create the SpamAssassin configuration file.
The name and location of this file is specified in Step 3. A good name is spamassassin.opt. This file contains the following lines:
host and port specify the name of the system where spamd is running and the port on which spamd listens for incoming requests. mode=1 specifies that the SpamAssassin result string is returned if the message is found to be spam. debug=1 turns on the debugging in the SpamAssassin library.
- Add the following lines to the option.dat file:
As in previous examples, the first three options specify the SpamAssassin configuration file, shared library, and to continue MTA operation if there is a failure by the shared library. The following line
spamfilter_string_action=data:,addtag “[SPAM detected $U]”;
specifies that a tag be added to the Subject: line. It has the literal prefix SPAM detected followed by the field string (default: Spam-Test) followed by “[result string]” returned by SpamAssassin. Because you specified mode=1 in Step 2, the SpamAssassin result string is returned. Thus, a subject line looks something like this:
Subject: [SPAM detected Spam-Test: True ; 11.3 / 5.0] Make Money at Home!
You can also use addheader and addtag together:
spamfilter_string_action=data:,require ["addheader"];addtag "[SPAM detected $U]";addheader "Spamscore: $U";
to get a message like this:
Subject: [SPAM detected Spam-Test: True ; 12.3 / 5.0] Vigara Now!
Spamscore: Spam-Test: True ; 12.3 / 5.0Set field= in spamassassin.opt to remove the default value of Spam-Test. A cleaner message is returned:
Subject: [SPAM True ; 91.3 / 5.0] Viagra again!
Spamscore: True ; 91.3 / 5.0- Recompile the configuration and restart the server. Only the MTA needs to be restarted, so you don’t need to do stop-msg.
# imsimta cnbuild
# imsimta restart- Start the spamd daemon. See Step 5 in "To File Spam to a Separate Folder" on page 444.
Support for Sieve Extensions spamtest and spamadjust
Messaging Server provides support for the spamtest and spamadjust which can be used by SpamAssassin. spamtest is described in ftp://ftp.isi.edu/in-notes/rfc3685.txt. spamadjust is a non-standard action. These extensions give administrators the ability to set a different threshold values as well as the ability to set up white lists that override SpamAssassin verdicts. The two can even be combined to have different thresholds depending on who sent a particular message.
spamtest can be used to compare SpamAssassin scores to specific values using the Sieve [RELATIONAL] extension with the "i;ascii-numeric" comparator. The SpamAssassin score is typically a real number, but spamtest forces the score into an integer value between 0 an 10 by first rounding the score to the nearest integer. Values below 0 are forced up to 0 while values above 10 are forced down to 10. Finally, the text string maintained by Messaging Server is appended to produce the test string the spamtest test sees.
spamadjust is used to adjust the current spam score. This action takes a single string argument which is scanned for a real numeric value. This value is used to adjust the current spam score. The entire string is also appended to the current score text string as well. In the example shown below, the string would be “undisclosed recipients.” Multiple spamadjust actions are allowed; each one is added to the current score. Again, the score value always starts at 0. Signed numeric values are allowed, making it possible to lower the current score as well as raise it. There is no require clause for spamadjust; the spamtest extension should be listed instead.
For example, a possible use of the spamadjust with a SpamAssassin MODE setting of 2 might be:
SPAMFILTER_STRING_ACTION=data:,require ["spamtest"];spamadjust "$U";
A system-level Sieve filter could then modify the SpamAssassin score by checking for a particular type of header and, if found, adding 5 to the SpamAssassin score:
spamfilter_string_action=require "spamtest";
if header :contains ["to", "cc", "bcc", "resent-to", "resent-cc", "resent-bcc"]
["<undisclosed recipients>", "undisclosed.recipients"]
{spamadjust "+5 undisclosed recipients";}
Finally, a user-level Sieve script could test the resulting value, discard messages certain to be spam, file messages likely to be spam, and allow messages from addresses in the local domain to pass through:
spamfilter_string_action=require ["spamtest", "relational", \
"comparator-i;ascii-numeric", "fileinto"]; \
if anyof (address :matches "from" ["*@siroe.com", \
"*@*.siroe.com"]) \
{keep;} \
elsif spamtest :value "ge" :comparator "i;ascii-numeric" "8" \
{discard;} \
elsif spamtest :value "ge" :comparator "i;ascii-numeric" "5" \
{fileinfo "spam-likely";} \
else \
{keep;} \
Testing SpamAssassin
To test SpamAssassin, first set debug=1 in the spamassassion.opt file. You do not have to turn on the channel-specific master_debug or slave_debug in the imta.cnf. Then send a test message to a test user. The msg_svr_base/data/tcp_local_slave.log* file should have lines similar to these:
15:15:45.44: SpamAssassin callout debugging enabled; config /opt/SUNWmsgsr/config/spamassassin.opt
15:15:45.44: IP address 127.0.0.1 specified
15:15:45.44: Port 2000 selected
15:15:45.44: Mode 0 selected
15:15:45.44: Field "Spam-Test: " selected
15:15:45.44: Verdict "spam" selected
15:15:45.44: Using CHECK rather than SYMBOLS
15:15:45.44: Initializing SpamAssassin message context
...
15:15:51.42: Creating socket to connect to SpamAssassin
15:15:51.42: Binding SpamAssassin socket
15:15:51.42: Connecting to SpamAssassin
15:15:51.42: Sending SpamAssassin announcement
15:15:51.42: Sending SpamAssassin the message
15:15:51.42: Performing SpamAssassin half close
15:15:51.42: Reading SpamAssassin status
15:15:51.67: Status line: SPAMD/1.1 0 EX_OK
15:15:51.67: Reading SpamAssassin result
15:15:51.67: Result line: Spam: False ; 1.3 / 5.0
15:15:51.67: Verdict line: Spam-Test: False ; 1.3 / 5.0
15:15:51.67: Closing connection to SpamAssassin
15:15:51.73: Freeing SpamAssassin message context
If your log file does not contain lines similar to these, or if spamd is not running, the following error message will be returned in your SMTP dialog after the last “.” is sent to the SMTP server.
452 4.4.5 Error writing message temporaries - Temporary scan failure: End message status = -1
In addition, if spamfilter_optional=1 (highly recommended) is set in options.dat, the message is accepted, but not filtered. It is as if spam filtering was not enabled, and the following lines appear in tcp_local_slave.log*:
15:35:15.69: Creating socket to connect to SpamAssassin
15:35:15.69: Binding SpamAssassin socket
15:35:15.69: Connecting to SpamAssassin
15:35:15.69: Error connecting socket: Connection refused
15:35:15.72: Freeing SpamAssassin message context
The call out to SpamAssassin happens after the SMTP server received the entire message (that is, after the last “.” is sent to the SMTP server), but before the SMTP server acknowledges to the sender that it accepted the message.
Another test is to send a sample spam message using sample-spam.txt from, for example, the Mail-SpamAssassin-2.60 directory. This message has the following special text string in it:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
The corresponding tcp_local_slave.log* contains something like this:
16:00:08.15: Creating socket to connect to SpamAssassin
16:00:08.15: Binding SpamAssassin socket
16:00:08.15: Connecting to SpamAssassin
16:00:08.15: Sending SpamAssassin announcement
16:00:08.15: Sending SpamAssassin the message
16:00:08.15: Performing SpamAssassin half close
16:00:08.15: Reading SpamAssassin status
16:00:08.43: Status line: SPAMD/1.1 0 EX_OK
16:00:08.43: Reading SpamAssassin result
16:00:08.43: Result line: Spam: True ; 1002.9 / 5.0
16:00:08.43: Verdict line: Spam-Test: True ; 1002.9 / 5.0
16:00:08.43: Closing connection to SpamAssassin
16:00:08.43: Mode 0 verdict of spam
16:00:08.43: Mode 0 verdict of spam
16:00:08.47: Freeing SpamAssassin message context
A corresponding entry in the mail.log_current file would look as follows. Note the +spam part of the destination address, which means the message is filed in the folder called spam:
15-Dec-2003 15:32:17.44 tcp_intranet ims-ms E 1 morchia@siroe.com rfc822;morchia
morchia+spam@ims-ms-daemon
15-Dec-2003 15:32:18.53 ims-ms D 1 morchia@siroe.com rfc822;morchia morchia+spam@ims-ms-daemon
SpamAssassin Options
This section contains the SpamAssassin option table.
Table 14-4 SpamAssassin Options (spamassassin.opt)
Options
Description
Default
debug
0 or 1. Specifies whether to turn on debugging in the libspamass.so. Debugging of spamd itself is controlled by the command line invoking spamd.
0
field
A string specifying the prefix for the SpamAssasin result string. SpamAssassin results string look like this:
Spam-Test: False ; 0.0 / 5.0
Spam-Test: True ; 27.7 / 5.0The FIELD option provides the means for changing the "Spam-Test: " part of the result. Note that the “: “ will also be removed if an empty field value is specified.
If USE_CHECK is set to 0, then the result string will look similar to this:
Spam-test: False ; 0.3 / 4.5 ; HTML_MESSAGE,NO_REAL_NAME
Spam-test: True ; 8.8 / 4.5 ; NIGERIAN_BODY, NO_REAL_NAME,PLING_PLING,RCVD_IN_SBL,SUBJ_ALL_CAPS
“Spam-test”
host
The name of the system where spamd is running
localhost
port
Port number where spamd listens for incoming requests.
783
mode
Controls what SpamAssassin verdict information is returned after processing a message. Three modes are available:
0 - Returns a verdict string (which is specified by the verdict option described below), if the message is spam. Returns a SpamAssassin default verdict string if it is not spam. (A default verdict always means to take no action and deliver as normal.) Returns a null verdict if the verdict option (defined below) is empty or unspecified. (The MTA option spamfilter_null_action specifies what to do if a null verdict is returned.)
1 - Returns the SpamAssassin result string if the message is found to be spam. A SpamAssassin result string looks something like this: True; 6.5 / 7.3
2- Same as mode 1 except that the SpamAssassin result string is returned regardless of whether the message is spam.
0
USE_CHECK
Set to 1, the spamd CHECK command is used to return the SpamAssassin score. Setting to 0 enables use of the SYMBOLS command which returns a score and a list of the SpamAssassin tests that matched. The system may hang or have other problems with this option in pre-2.55 versions of SpamAssassin. See field above.
verdict
Specifies the verdict string used for MODE 0.
“”
