Sun Java System Messaging Server 6.3 Administration Guide

14.2.3 Specifying Actions to Perform on Spam Messages

Spam filtering programs analyze messages and return a verdict of spam or not spam to current version of Messaging Server. Messaging Server then takes action on the message. Actions are specified using the Sieve mail filtering language. Possible 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.


Note –

Refer to the Sieve specification 3028 for the complete Sieve syntax. Also see http//www.cyrusoft.com/sievettp://www.cyrusoft.com/sieve/


Sieve scripts are specified with the MTA spam filter options (option.dat) described in Table 14–1. The primary spam filter action options are SpamfilterX_null_action, which specifies the Sieve rule to execute when a null value is returned as the spam verdict value, and SpamfilterX_string_action, which specifies the Sieve rule to execute when a string is returned as the spam verdict.

Spam filtering 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. The following examples show how to specify actions on filtered messages. Each example assumes a filtering program specified by the number 1.

Example 1: File spam messages with a null verdict value to the file SPAM_CAN.

spamfilter1_null_action=data:,require "fileinto"; fileinto "SPAM_CAN”;

The same action can be performed on a spam message that returns a string:

spamfilter1_string_action=data:,require "fileinto"; fileinto "SPAM_CAN”;

Example 2: File spam messages with a returned verdict string into a file named after the returned verdict string (this is what $U does). That is, if the verdict string returned is spam, the message is stored in a file called spam.

spamfilter1_null_action=data:,require "fileinto"; fileinto "$U”;

Example 3: Discard spam messages with a string verdict value.

spamfilter1_string_action=data:,discard

The same action can be performed on a spam message that returns a null value:

spamfilter1_null_action=data:,require "fileinto"; fileinto "SPAM_CAN”;

Example 4. This line adds the header Spam-test: FAIL to each message determined to be spam by a string verdict value:

spamfilter1_string_action=data:,require ["addheader"];addheader "Spam-test: FAIL”;

Example 5. This line adds the string [PROBABLE SPAM] to the subject line of the spam messages returning a string:

spamfilter1_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 the message does not have that header, it files the message into spam.

spamfilter1_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 returned string. This can be done with the matched pairs spamfilterX_verdict_n and spamfilterX_action_n options.

Example 7. These matched pair options discard spam messages with the returned verdict string of remove.


spamfilter1_verdict_0=remove
spamfilter1_action_0=data:,discard

Refer to the specific spam filtering software sections for instructions on how to specify the spam verdict string.

Table 14–1 MTA Spam Filter Options (option.dat)

MTA Options  

Description  

SpamfilterX_config_file

Specifies the full file path and name of the filtering software X configuration file. Default: none 

SpamfilterX_library

Specifies the full file path and name of the filtering software X shared library. Default: none 

SpamfilterX_optional

Controls whether certain failures reported by the filtering library X are treated as a temporary processing failure or ignored. 0 specifies that spam filtering problems cause a temporary processing failure. 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. -2 and 2 are the same as 0 and 1 respectively except that they also cause a syslog message to be sent in the event of a problem reported by the spam filter plugin. 3 causes spam filter failures to accept the message, but queue it to the reprocess channel for later processing. 4 does the same as 3 but also logs the spam filter temporary failure to syslog.

Default: 0

LDAP_optinX

Specifies the name of the LDAP attribute used to activate filtering software X on a per-user basis. Filtering is based on destination addresses. That is, messages directed to users with this attribute will be filtered for spam. This should be an attribute in the inetMailUser objectclass.

The attribute itself can take multiple values and is case-sensitive. For SpamAssassin, its value should be spam in lowercase.

Default: none 

LDAP_SOURCE_OPTINX

LDAP_SOURCE_OPTIN1 through LDAP_SOURCE_OPTIN8 provide originator-address-based per-user spam filter optins values comparable to LDAP_optinX. This is, mail originating from this user will be filtered for spam.

LDAP_domain_attr_optinX

Specifies the name of the LDAP attribute used to activate filtering software X on a domain basis. It applies to the destination domain. It is just like LDAP_optin, except it should be in the objectclass mailDomain.

Default: none 

SpamfilterX_null_optin

Specifies a string which, if found, as a value of the attribute defined by LDAP_optinX or LDAP_domain_attr_optinX, causes the MTA to act as if the attribute wasn’t there. That is, it disables filtering for that entry. See 14.2.2 Specifying the Messages to Be Filtered

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 spamfilterX_null_optin to a string that never occurs in practice.)

SpamfilterX_null_action

Defines a Sieve rule specifying what to do with the message when the filtering software X 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 address was used to send the spam. Default: data:,discard;

SpamfilterX_string_action

Defines 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 was used to send the spam.

Default: data:,require "fileinto"; fileinto "$U;

where $U is the string that verdict returned.

spamfilterX_verdict_n

The options spamfilterX_verdict_n and spamfilterX_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 spamfilterX_verdict_n and spamfilterX_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:


spamfilter1_verdict_0=reject
spamfilter1_action_0=data:,require "reject";
reject "Rejected by spam filter";

The default values for all the spamfilterX_verdict_n options and the corresponding action options are empty strings.

Default: none 

spamfilterX_action_n

See spamfilterX_verdict_n. Default: none

spamfilterX_final

Some filtering libraries have the ability to perform a set of actions based on recipient addresses. What sort of recipient address is passed to the filtering library depends on the setting of the spamfilterX_final. The default value of 0 results in a so-called intermediate address being passed to the filtering library. This address is suitable for use in delivery status notifications and for directory lookups. If bit 0 (value 1) of spamfilterX_final is set, however, the final form of the recipient address is passed. This form may not be suitable for presentation but is more appropriate for subsequent forwarding operations.

The spamfilterX_final option is only available in Messaging Server 6.0; Messaging Server 5.2 behaves as if the option had the default value of 0.

In 6.2 and later bit 1 (value 2) of spamfilterX_final controls whether or not source routes are stripped from the address that's passed to the filtering interface. Setting the bit enables source route stripping.

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 is set to opt 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 or 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 overrides 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 accumulate if one user has a delivery option that forwards to another. The default insures that site security policies are effective when forwarding; other settings may not.)