Site Configuration Keyword Reference for LISTSERV 17.0

Platforms

All LISTSERV Classic/Classic HPO.

Abstract

Sets up blacklists and whitelists to help combat spam.

Examples

See below, in Details.

Requirements

This feature is not available in LISTSERV Lite.  A current L-Soft maintenance contract is also required for this feature in LISTSERV Classic and LISTSERV Classic HPO.

In order for LISTSERV to use the blacklists and whitelists, SPAM_EXIT must be enabled and pointed to an existing, external exit program. This is necessary because the white- and blacklisting feature is part of LISTSERV's overall anti-spam toolbox, which is only activated if SPAM_EXIT is enabled.

While you may of course use the exit program you write to submit inbound mail to an external spam filter for scanning, that is not mandatory. In that case, the exit program does not need to do anything other than exit immediately with a return code of zero.  For example:

Details

LISTSERV includes a whitelist/blacklist system that can be used either on its own, or in conjunction with the spam exit feature (please see the Developers Guide to LISTSERV for more information on the spam exit feature). This built-in whitelist/blacklist system is very efficient, which makes it advantageous to duplicate your spam filter’s whitelist/blacklist rules so that the spam filter is bypassed for messages whose disposition can be determined simply on the basis of the origin or target address.

There are four separate lists (or in reality, site configuration variables that contain the lists), called:

SPAM_BLACKLIST_FROM
SPAM_BLACKLIST_TO
SPAM_WHITELIST_FROM
SPAM_WHITELIST_TO

The lists are defined in the site configuration file in the usual space-separated manner. A restart of LISTSERV is required after updating any of the lists, also as usual.

The FROM lists are applied to all the origin fields in the RFC822 header – From:, Sender:, Resent-From: and Resent-Sender: (note that the SMTP-level MAIL FROM: is not used).

The TO lists are applied to the various recipient fields in the RFC822 header. Please note that LISTSERV does not work at the SMTP transaction level and does not have access to the RCPT TO: field.

The listing system is based on a score that LISTSERV maintains as it goes through the four lists in sequence. If the final score is zero, the message is neither white- nor blacklisted, and processing continues normally (to the external spam filter, if one has been configured). If the final score is positive, the message is whitelisted and accepted, bypassing any additional tests, including the external spam filter. If negative, the message is immediately rejected. A negative final score is a conclusive determination that makes any further tests unnecessary.

Being whitelisted normally gives one point, and being blacklisted costs one point. This can be changed by using the following syntax:

SPAM_WHITELIST_FROM=*@EXAMPLE.COM *@*.EXAMPLE.COM
SPAM_BLACKLIST_FROM=*@PUBLIC.EXAMPLE.COM >JAMES@EXAMPLE.COM

The first entry whitelists all EXAMPLE.COM addresses. The second entry acts as a cancellation of this whitelist for the fictitious machine PUBLIC.EXAMPLE.COM, which is not part of the Intranet. It also blacklists JAMES@EXAMPLE.COM, a notorious source of spam, with a score of 2 (every '>' sign gives another score point). JAMES@EXAMPLE.COM receives 1 point from the whitelist and -2 from the blacklist, so he will be effectively blacklisted. It is possible to load an entry with up to 254 extra score points, although it is not expected that anyone would need to go that far.

Every list gives score points at most once. So if we also had JAMES@EXAMPLE.COM and JAMES@* in the whitelist, he would still get only one point from the whitelist. But, when applicable, you do get the highest possible number of points that you have matched. If we had JAMES@EXAMPLE.COM and >>JAMES@* in the whitelist, he would get 3 points.

Again, all the whitelists and blacklists scores are added. If you use both FROM and TO, you need to use a point system that gives the desired results. It is much easier if you only use FROM or only TO.

What you would put in TO is defunct addresses (former employees, “honeypots”, etc.) that are guaranteed to have come out of spam listings. The message is then bounced for all recipients, not just the defunct address.

In most cases you will not want bounces to be blacklisted, since they are useful to LISTSERV and are processed automatically. In addition to the white/blacklists themselves, another site configuration variable, SPAM_WHITELIST_BOUNCE, is available. This value is an integer, defaulting to 1, and is the number to be added to the message's whitelist score if it is a bounce. Set to 0 to disable. You can also use a higher value.

Note that bounces may not be run through the spam filter at all. If LISTSERV can immediately determine what the bounce is for and process it, it will not scan it for spam.

SYNTAX:  The syntax for all of the white- and blacklists is identical, so we will use just one of them for the example.

White/Blacklisting example:

SPAM_WHITELIST_BOUNCE examples:

See Also

SPAM_EXIT