[ Table of Contents ] [ Previous Chapter ] [ Next Chapter ] [ Index ]



SMTP Filters

SMTP Message Filters provide a powerful and efficient way to pre-screen incoming messages and discard unwanted messages or re-route messages to a specified address or list of addresses. SMTP filters were primarily developed to prevent known Internet message sources from sending SPAM mail to local users and to prevent the use of the Message Transfer Agent as a forwarding agent of SPAM mail to unsuspecting remote users. These filters provide a significant first line of defense against Internet junk mail.

 

SMTP Message Filters can also be used for other purposes. They can be used to intercept and forward messages to users that have moved their mail to other systems or for users that wish to filter their mail into separate destination mailboxes. This is especially useful when a user is a member of several Internet mail groups and wishes to have mail from the different groups segregated into different local mail accounts leaving a primary mail account uncluttered by background or group mailings.

 

See the Post.Office (available online from the NetTen Post.Office home page) manual for more information about the various types of Post.Office filters, aliases (Alias Addresses, Alias Accounts, and Channel Aliases).

 

 

SMTP Filters Form

 

Adding SMTP Message Filter Entries

 

SMTP Message Filters are composed of fields specifying different content templates that might match an incoming message and an action that is executed if a template matches a message. Content templates are composed of Source, Destination, Header and Body filter segments. Each segment may have multiple elements specifying several possible ways a segment may match an incoming message. For example, the Body segment specification might contain

"*adult*" AND "*dirty*" looking for a message has the word 'adult' and the word 'dirty' in it.

 

Each message segment must match the corresponding message, so logically speaking, the results of each message segment are logically `And'ed with the results of other segments.

SMTP Message Filter Actions

 

There are two alternative actions: Discard and Copy To. If Discard is selected, it will make a entry in the Post.Office log and discard the message. If Copy To is selected, the entry in Mail Addr. will make a copy of the message and send it to an alternate mail address or list of addresses. Alternatively, if Copy To is selected, File Name specifies a file that contains a list of e-mail addresses that the message is forwarded to.

 

Both Discard and Copy To may be selected at the same time. This configuration prevents the message from being delivered to it's original destination and, instead, redirects the message to the specified alternate e-mail address(es).

SMTP Message Filter Specifications

 

SMTP Message Filters are specified by filling out a new Message Filter template. Each template has segment fields for name, description, source, destination, header and body filter specifications. The name and description specifications are used to identify a Message Filter and to reference it for modification. Source, destination, header and body segments are used to specify prototype templates that can be matched against incoming messages. When a match occurs on all four segments, the given action is executed. Source, destination, header and body fields contain text strings and other specifications that are used to match all or part of the corresponding field of all incoming messages.

 

Basic Filter Example #1

 

Notice the use of '*' wild card characters to match zero or more occurrences of text. The first example above will match messages from the source of 'Bad.ISP.COM' with an exact match. The destination will be applied to anyone in the domain 'tenon.com'. The Subject will include any text containing the word 'SPAM'. A second example might match occurrences of a source of 'kahuna@sex.org' a destination of 'williams@tenon.com' with any subject and any type

of message text.

Multi-Faceted Fields

 

Each of the elements in a filter template segment contain an entry type, entry data or parameter field and an opcode field. The opcode field provides for the specification of no operation, NOT, AND, OR, NOT AND and NOT OR operations. Each of the multi-faceted segments has an empty element at the end. To turn a filter into a multi-faceted filter, set the 'op' field of the existing filter element to NOT, AND etc. and set the 'type', 'data' and 'op' fields of the next filter element. Submit the filter for processing. Then next time the filter specification is displayed, it will have three fields, the previously existing filter element, the newly created filter element and another empty filter for future extension.

 

The NOT specification is used to negate the result of a filter specified by the entry type and data fields. If someone wished to match everything but '*tenon.com', the type field would be set to 'addr', the data field would contain '*tenon.com' and the opcode field would be set to NOT.

 

Multi-Faceted Filter Specification

 

While the NOT operator applies to the current filter element, the AND, OR, NOT AND and NOT OR opcode specifications refer to the succeeding and current elements. The AND specification means that the current element and the next element both have to be positively satisfied for the filter segment to contribute to an execution of the action. The OR specification means that either the current element or the next element must be true for the filter segment to cause the action to trigger. This might be used to specify possible 'Subject:' fields such as 'Subject: *BAD*' OR 'Subject: *TOGOODTOBETRUE*'. The NOT AND and NOT OR are means to combine the NOT specification and either the AND operation or the OR operation in one opcode. Specifying NOT AND means that the current element must evaluate negatively (e.g. *tenon.com NOT) and the next element must evaluate positively. Note that this may mean that the next specification may simply evaluate to true with a match between the message and the data field, or if the NOT specification is part of the next specification it too needs to evaluate negatively and then have the NOT opcode applied for a positive result.

 

Multi-Faceted fields are particularly useful when creating a filter to block "SPAM" e-mail from taking advantage of open message relay. A typical "anti-SPAM" filter is logically configured to reject e-mail that is neither to or from any address on one of the local domains. Figure 41 is an example of an anti-SPAM filter that blocks e-mail to or from addresses in domain1.com, domain2.com, or domain3.com.

 

Anti-SPAM filter example

 

File-based Specifications

Each of the source, destination and action filter segments contain a 'type' field setting for specifying a file name. When the 'type' field is set to 'File Name', the data field is set to the name of the file to be used in the filter element. The contents of filter files are organized as an entry per line. So each line contains an e-mail address, IP address or IP address range depending on the usage of the file.

 

There are two important considerations about specifying files. First, the path name component of a file name needs to be set so that NetTen can find the file within its file hierarchy. While other path names will work, it is suggested that the path '//' be inserted at the beginning of each file name so that the file may be located in the directory logically above the directory that contains NetTen. For example, if the main NetTen directory is located in SOMEVOLUME:FirstFolder:NetTen v1.4, specifying //My.File in a file name specification would cause NetTen to search the SOMEVOLUME:FirstFolder directory for the file 'My.File'.

 

The second file consideration relates to the Macintosh file creator and file type. For NetTen to properly view the contents of a file, it must have the proper Macintosh creator 'MUMM' and the proper Macintosh file type 'TEXT'. If either of these specifications are improper, the file may be correctly located, but automatic data translations will be applied to the data within the file as it is read causing filters to mis-fire or trigger inappropriately. You can set the Macintosh creator and type information with a readily available Macintosh utility program called 'ResEdit' or one of many other file type changing utilities. You can also use the NetTen utility 'Unix<->Text' to translate any file to the proper creator and type simply by dragging the file to the 'Unix<->Text' icon for processing. We recommend using a Macintosh text editor to create a file. The BBEdit editor can be configured to create files with the correct maker and type set.

Mail Abuse Prevention System Realtime Blackhole List

The Mail Abuse Prevention System (MAPS) - http://maps.vix.com/rbl - has been organized by a group of people interested in limiting the spread of unwanted e-mail or SPAM. The MAPS has a number of features but the principal one of interest to NetTen is the Realtime Blackhole List (RBL). The RBL is a list of addresses that have previously sent SPAM on a large scale basis. Clients of the RBL dynamically send the IP addresses of mail sources or destinations to an RBL host which looks in its database of active "blackholed" IP addresses and returns a positive or negative response.

 

In NetTen, you can specify that a source or destination filter element contains an RBL request. When an RBL is specified, the IP address of each of the components of a message source or destination is used to ask the specified RBL server whether that address is in the RBL. If it is, the filter element evaluates positively and contributes toward the execution of the filter action. In specifying an RBL-based filter element, the data field specifies one or more (comma separated) host names that are to be used as RBL servers for that filter. If the field is left blank, a default server is used. The host "rbl.maps.vix.com" is an example and is not the only RBL.

 

MAPS RBL message filter

Case Sensitivity

The source, destination, and header filter segments all specify filter elements that are case insensitive. That means that 'TO: SOMEUSER' and 'To: SomeUser' and 'to: someuser' all match the specification of 'to: *someuser*'.

 

Message Body segment filter specification are, however, case sensitive so '*adult*' will not match 'Adults for you'. Be certain that you take this into account when you are specifying Message body filter segments.

Source and Destination Field Entries

The source and destination fields are multi-faceted fields that can specify source or destination e-mail addresses, lists of e-mail addresses or an Internet host address where a message source or destination can be dynamically filtered using the Mail Abuse Prevention System (MAPS) Realtime Blackhole List (RBL).

 

Each field can have multiple facets or elements that provide for the specification of complex filters with components that are logically connected. A filter might be developed that is looking for a message from host A OR host B or a filter might be developed that is NOT from e-mail address A AND NOT from e-mail address B. Please see section 7.4 for a more complete discussion of multi-faceted filter fields.

Source and Destination e-mail Addresses

Source and destination filter fields specify fully qualified e-mail addresses or partially qualified e-mail addresses using the '*' character (e.g. *tenon.com). These fields are useful for filtering e-mail from individual users or entire domains. The below example shows how to use source and destination e-mail addresses in SMTP filters. The example shows a filter that would discard all e-mail to joe@domain.com that was not from another e-mail address in domain.com.

 

Source and Destination e-mail Addresses

 

Each of the fields can specify lists of entries by separating multiple elements with a comma (e.g. badhost.nowhere.com, badhost1.nowhere.com).

 

In addition to specifying e-mail addresses in traditional username@host.domain form, source and destination filter entries can specify lists of internet IP addresses or IP address ranges using dotted-decimal formats. IP address specifiers use a dotted-decimal format. A dotted-decimal number contains four fields each field is an integer number from 0-255 separated from the other integers by a period. For example, 127.0.0.1 specifies the dotted-decimal address that, by convention, is used to refer to the local host. The IP address 198.137.240.91 is one of the White House web server addresses. An address range is two IP addresses separated by a dash. This provides for the specification of a range of numbers. The IP address range 127.0.0.1-127.0.0.10 specifies ten IP addresses from 127.0.0.1 through 127.0.0.10 inclusive. IP addresses can also be specified as a comma separated list where each entry simply refers to a possible IP address that might match an incoming e-mail. The IP address list 127.0.0.1, 127.0.0.5, 127.0.0.2 specifies three IP address that might match an incoming message. Lastly, host names or domains may be inter-mixed with IP addresses in IP address lists to specify IP addresses that might match an incoming message. The IP address list 127.0.0.23, www.whitehouse.gov, 205.180.86.93 matches three addresses. Two of the addresses are numeric. The middle address is translated into its dotted-decimal equivalent using the Domain Name System and then treated like any other address specification.

Source and Destination File Name Specification

Instead of specifying names or addresses directly within a filter, source and destination filter elements may specify a file name. The file specified by the name contains text defining one or more e-mail addresses, partially qualified e-mail addresses, IP addresses or IP address ranges. Please see File-based Specifications for important considerations about file path specification and file format.

Source and Destination Dynamic Host Filtering

In addition to the other alternatives to specifying a filter, a source or destination filter can specify a host name or list of host names to be used as a server or list of servers which will be used to check each e-mail address against the MAPS Realtime Blackhole List (RBL). If the source or destination e-mail address is found in the RBL, it will be considered as a partial filter match contributing to the potential execution of the action field. Please see Mail Abuse Prevention System Realtime Blackhole List (http://www.maps.vix.com) for more details about how this exceptional SPAM filter works

Header Field Entries

The header is a multi-faceted specification that supports the matching of any header field in an incoming e-mail message to text defined in an SMTP filter. Header fields are composed of headername and headervalue fields separated by a colon. Typical header fields include To: or From: or Subject: . These fields and others can be matched by filling in a filter header field with a headername:headervalue. The headername contains the header field that the filter is to match. The headervalue field contains text or a regular expression defining the specific headervalue that is to be matched against. For example the header specification To: *tenon.com matches anyone with an address that ends in the string 'tenon.com'. The subject field is used extensively in filters to search for e-mail with inappropriate subject matter (e.g. Subject:*To good to be true*).

 

Like source and destination filter field specifications, header fields can be multi-dimensional logical statements combining different possible headers with AND, OR and NOT boolean operations. Therefore, filters of the form From: KnownSpammer@spam.COM AND Subject: *money* are easily specified. One could also set a filter to discard mail that has no "from:" header field by specifying the logical NOT with a "from: *". A filter like this would discard all mail that doesn't have the from header filed and could be use with any type of header field.

Other Header Fields

There are a number of other defined header fields that are listed in: RFC 822 "Standard for the Format of ARPA Network Text Messages" and as updated by RFC1123, RFC1138, RFC1148, RFC1327 and RFC2156. Specified header fields include:

 

Return-path: 'route addr',

Received From: 'domain',

Received by: 'domain',

Received id: 'id',

Received for: 'address spec',

Reply-To: 'address',

From: 'mailbox',

Sender:'mailbox',

Resent-Reply-To: 'address spec',

Resent-From: 'mailbox',

Resent-Sender: 'mailbox',

Date: 'date and time',

Resent-Date: 'date and time',

To: 'mailbox',

Resent-To: 'mailbox',

cc: 'mailbox',

Resent-cc: 'mailbox',

bcc: 'mailbox',

Resent-bcc: 'mailbox',

Message-ID: 'id',

Resent-Message-ID: 'id',

In-Reply-To: 'phrase',

References: 'phrase',

Keywords: 'phrase',

Subject: 'text',

Comments: 'text' and,

Encrypted: 'word'.

 

To specify a subject headername that is not on the drop down menu of header fields, specify "other:" and complete the filter. Then reference the filter in the Existing Filters section of the Filters page and modify the "other" field by inputting the specific header specification required.

 

Message Body Entries

The Message Body specification supports the regular expression search of mail text for key words or expressions. Like Source, Destination and header fields, the message body field is a multi-faceted field that supports complex boolean matches to filter templates with subtle differences.

Modifying Existing Entries

Previously defined filters are displayed in the Existing Filters section of the Filter page. Select the Filter Name and display its specification. It will present a list of source, destination, header, body and action filter segments. To modify an existing entry simply edit the field you wish to change and submit the filter request for processing.

 

Each of the multi-faceted fields include an empty entry at the end of each field. To add a new field component, edit the empty entry and relate it to the previous entries by modifying the Op field of the previous entry.

Deleting SMTP Message Filter Entries

You can delete an SMTP Message Filter by changing the name of the filter to 'delete' and submitting the filter for processing.

 

You can delete a filter segment of a multi-faceted filter by clearing the data parameter of the filter segment and submitting it for processing.

 

By default, Dynamic Host specifications may contain an empty data parameter. To delete a filter segment specifying a dynamic host, reset the type of the field to either 'file' or 'address' and clear the data parameter.

 

When making changes to your filters, always use reload on your browser to make sure you see the changes, otherwise your browser may just display an old version of the page that has been stored in your cache which could be confusing.

 



[ Table of Contents ] [ Previous Chapter ] [ Next Chapter ] [ Index ]