Content filtering

his feature requires LISTSERV 1.8e or later. It is not available in LISTSERV Lite.

ity will most likely rove to be futile in the long run and are not recommended by L-Soft.

filtering rules, one rule r line, empty lines ignored. Each rule has the following format:

prefix:] pattern

e futile attempts at (for instance) decoding Word cuments to look for obscene words.

is no sterisk in the pattern, it is replaced with "*pattern*" much like the SCAN command.

p

The only situation in which a list password MUST be defined explicitly in a list header is in the case of peere

v

LISTSERV 1.8d kits starting in May 2000 contain a new MIME attachment-filtering feature which is configured by setting the n

n

•

•

•

In addition, you can configure specific MIME types to reject or filter while allowing other types through (for instance, you can block

p

For information on the various settings k

T

This feature is intended primarily to filter out-of-office messages and the like. It is not intended as a profanity filter. Attempts to configure it to filter profan

p

The CONTENT_FILTER mail template form, if present, contains pe

[

The prefix, if present, can be a mail header tag (eg "Subject:"); "Header:" to check the whole header; or "Text:" to search the message text. The latter is the default if no prefix is supplied, it is provided in case the pattern contains a colon in the first word. If there are multiple mail header tags with the specified name (eg "Received:"), each such tag is searched and it is enough for one of them to match the pattern. If the requested tag is not present in the header, there is (surprise!) no match. A text search will search every line of the first text/plain part in the message. If there is no text/plain part, there is no match.

Again, this is designed to filter read receipts, loops, chain letters, spam, you name it.

There was no attempt on the developers' part to make this a profanity filter, and future versions will not be "enhanced" to mak

do

Regular comparisons such as those described above are not case sensitive. Patterns are standard LISTSERV patterns, that is, the asterisk is the wildcard character. If there a

The content filter also supports "exact match" comparisons, which are triggered by a ouble colon. For instance:

ubject::

here are two significant differences between exact and regular match:

re und. Thus, an exact match is the only way to make a comparison without wildcards.

ltering actions if the the header is not present. This is not possible with a gular match.

ifferentiate a header with an empty KABOOM field from a eader with no KABOOM field.

is to be able to write a rule to ject messages with blank subject lines. For instance:

ction: REJECT Please resubmit your message with a non-blank subject.

ery rule can, optionally, be followed by an action rule. This has the following format:

mment tion: MODERATE

lable actions are the same for both regular and exact comparisons.) For stance,

s are not allowed on this list.

nerated:

ECT Buzz off, spammer.

e resubmit with a non-blank subject.

ction: DISCARD This guy is a spammer

g; any text following DISCARD is echoed to d

S T

a. You must supply your own wildcard characters in an exact match (if you want to use wildcards, that is). A regular match will insert leading and trailing wildcards if none a fo

b. You can make an exact match for the empty string. Empty regular matches are ignored since they map to a wildcard comparison for **, which would be always true.

This also makes it possible to apply an exact match to a message that does not contain a specified header. For instance, if you want all messages to contain a (mythical) KABOOM: RFC822 header, with an exact match you can tell LISTSERV to perform one of the content-fi

re

Note however that you cannot d h

One of the most handy uses for the exact match syntax re

Text: Click here to be removed Action: REJ

The default is "Action: REJECT" with no specified reason. REJECT means that the message is rejected. MODERATE means that the message is to be forwarded to the list editor to be manually approved or rejected. DISCARD means that the message is to be dropped on the floor without further processin

the LISTSERV console (and is thus logged).

sed in moderated lists to allow the list moderator to bypass certain filters, for stance:

ages are not allowed on this list.

LE.COM

ction: REJECT Buzz off, spammer.

k here to be removed" are also rejected NLESS they come from [email protected] .

e ason supplied as a variable called &COMMENT. The rejection message looks like this:

AMPLE.COM (1.8e)"

TSERV.EXAMPLE.COM : Joe User <[email protected]>

ejected by the content filter. OOO essages are not allowed on this list.

e body of the essage contained the text "out of office" and the rule above was applied.)

ners do not prefer to provide their own custom versions in their stname.MAILTPL files.

ALLOW means that the message is allowed and all remaining rules are ignored. This could be u

in

>>> CONTENT_FILTER Subject: Out of office Action: REJECT OOO mess From: JOE@EXAMP

Action: ALLOW

Text: Click here to be removed A

In the example above, messages with Subject: lines containing "Out of office" are rejected. Messages containing the text "Clic

U

The text of the rejection is fetched from the BAD_CONTENT mail template form, with th re

Date: Tue, 4 Dec 2001 22:03:42 -0500 From: "L-Soft list server at LISTSERV.EX <[email protected]>

Subject: Rejected posting to TEST@LIS To

Your posting to the TEST list has been r m

followed by the text of the posting including all mail headers. (In this case th m

A default site-wide CONTENT_FILTER template form may be defined in $SITE$.MAILTPL for use by lists whose ow

li

3. Advertising Your Public Mailing Lists