Specifying Actions to Perform on Spam Messages (Sun Java System Messaging Server 6 2005Q4 Administration Guide)

Sun Java System Messaging Server 6 2005Q4 Administration Guide

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–2. 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–2 MTA Spam Filter Options (option.dat)

MTA Options for Spam Assassin

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. The default value of 0 specifies that spam filtering problems 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. -2 and 2 can also be set. The 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.

Default: 0

LDAP_optinX

Specifies the name of the LDAP attribute used to activate filtering software X on a user basis. 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_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 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. spamfilterX_final specifies the sort of recipient address passed to the filtering library. A value of 0 results in an 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 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.)