Chapter 17 Mail Filtering and Access Control

This chapter discusses how to filter mail based on its source (sender, IP address and so on) or header strings. Two mail filtering mechanisms are used, controlling access to the MTA using mapping tables and Sieve server-side rules (SSR).

Limiting access to the MTA using the mapping tables allows messages to be filtered based on From: and To: addresses, IP address, port numbers and source or destination channels. Mapping tables allow SMTP relaying to be enabled or disabled. Sieve is a mail filtering script that allows messages to be filtered based on strings found in headers. (It doesn’t work on the message body.)

If envelope-level controls are desired, use mapping tables to filter mail. If header-based controls are desired, use Sieve server-side rules.

PART 1. MAPPING TABLES. Allows the administrator to control access to MTA services by configuring certain mapping tables. The administrator can control who can or cannot send mail, receive mail through Messaging Server.

PART 2. MAILBOX FILTERS. Allows users and administrators to filter messages and specify actions on those filtered messages based on a string found in the message header. Uses the Sieve filter language and can filter at the channel, MTA or user level.

PART 1. MAPPING TABLES

Controlling Access with Mapping Tables

You can control access to your mail services by configuring certain mapping tables. These mapping tables allow you to control who can or cannot send mail, receive mail, or both. Table 17-1 lists the mapping tables described in this section. The application information string supplied to the FROM_ACCESS, MAIL_ACCESS, and ORIG_MAIL_ACCESS mappings includes the system name claimed in the HELO/EHLO SMTP command. This name appears at the end of the string and is separated from the rest of the string (normally “SMTP”) by a slash. The claimed system name can be useful in blocking some worms and viruses.

Access Control Mapping Tables—Operation

Like all mapping tables, access control mapping tables have the same general format (see Mappings File). They consist of a mapping table name, followed by a line break, followed by one or more mapping entries. Mapping entries consist of a search pattern on the left side and a template on the right side. The search pattern filters specific messages and the template specifies actions to take on the message. For example:

SEND_ACCESS

*|Elvis1@sesta.com|*|*      $Y
*|Nelson7@sesta.com|*|*     $Y
*|AkiraK@sesta.com|*|*      $Y
*|*@sesta.com|*|*              $NMail$ Blocked

In this example all email from the domain sesta.com except those of Elvis1, Nelson, AkiraK are blocked.

The search pattern for access control mapping entries consist of a number of search criteria separated by vertical bars (|). The order of the search criteria depends on the access mapping table and is described in subsequent sections. But as an example, the SEND_ACCESS mapping table has the following search form:

where src-channel is the channel queueing the message; from-address is the address of the message's originator; dst-channel is the channel to which the message will be queued; and to-address is the address to which the message is addressed. Use of an asterisk in any of these four fields causes that field to match any channel or address, as appropriate.


Note	Whenever the mappings file is modified, you must recompile the configuration (see the imsimta refresh command in the Sun Java System Messaging Server Administration Reference).

Table 17-1 Access Control Mapping Tables
Mapping Table	Description
SEND_ACCESS (See (more...) .)	Used to block incoming connections based on envelope From address, envelope To address, source and destination channels. The To address is checked after rewriting, alias expansion, and so on, have been performed.
ORIG_SEND_ACCESS (See (more...) .)	Used to block incoming connections based on envelope From address, envelope To address, source and destination channels. The To address is checked after rewriting but before alias expansion.
MAIL_ACCESS (See (more...) .)	Used to block incoming connections based on combined information found in SEND_ACCESS and PORT_ACCESS tables: that is, the channel and address information found in SEND_ACCESS combined with the IP address and port number information found in PORT_ACCESS.
ORIG_MAIL_ACCESS (See (more...) .)	Used to block incoming connections based on combined information found in ORIG_SEND_ACCESS and PORT_ACCESS tables: that is, the channel and address information found in ORIG_SEND_ACCESS combined with the IP address and port number information found in PORT_ACCESS.
FROM_ACCESS (See (more...) .)	Used to filter mail based on envelope From addresses. Use this table if the To address is irrelevant.
PORT_ACCESS (See (more...) .)	Used to block incoming connections based on IP number.

The MAIL_ACCESS and ORIG_MAIL_ACCESS mappings are the most general, having available not only the address and channel information available to SEND_ACCESS and ORIG_SEND_ACCESS, but also any information that would be available via the PORT_ACCESS mapping table, including IP address and port number information.

Access Control Mapping Table Flags

Table 17-2 shows the access mapping flags relevant for the SEND_ACCESS, ORIG_SEND_ACCESS, MAIL_ACCESS, ORIG_MAIL_ACCESS, and FROM_ACCESS mapping tables. Note that the PORT_ACCESS mapping table, supports a somewhat different set of flags (see Table 17-3).

Flags with arguments must have those arguments arranged in the reading order shown in the table. For example:

In this case, the proper order is the delay period followed by the rejection string. Note that the flags themselves can be in any order. So the following entries have identical results:

30|Relaying$ not$ allowed$D$N
$N30|Relaying$ not$ allowed$D
30|$N$DRelaying$ not$ allowed

Table 17-2 Access Mapping Flags
Flag	Description
$A	Set if SASL has been used. See Check for Special Flags.
$B	Redirect the message to the bitbucket.
$D	Set if delay delivery receipts requests (not available in FROM_ACCESS). See Check for Special Flags.
$F	Set if failure delivery receipts requested (not available in FROM_ACCESS. See Check for Special Flags.
$H	Hold the message as a .HELD file.
$S	Set if success delivery receipts requested (not available in FROM_ACCESS). See Check for Special Flags.
$T	Set if TLS has been used. See Check for Special Flags.
$U	If used in ORIG_SEND_ACCESS, SEND_ACCESS, ORIG_MAIL_ACCESS, and MAIL_ACCESS, takes a single integer argument from the beginning of the mapping and sets the value of MM_DEBUG accordingly. Additionally, channel-level debugging is also enabled if possible. The result is that you enable debugging based on items such as source IP address, original address, recipient address, and so on.
$Y	Allow access.
$V	Causes a forced discard to be performed for all recipient(s).
$Z	Causes a forced jettison to be performed for all recipient(s).
Flags with Arguments, in Argument Reading Order+ (DO NOT ALPHABETIZE THIS LIST!)
$Uinteger	Takes a single integer argument from the beginning of the mapping and sets MM_DEBUG accordingly. Additionally, channel-level debugging is also enabled if possible. The result is that debugging can now be enabled based on things like source IP address, original address, recipient address, and so on.
$Jaddress	* Replace original envelope From: address with specified address.
$Kaddress	* ++ Replace original Sender: address with specified address.
$Iuser\|identifier	Check specified user for group ID.
$<string	+++ Send string to syslog (UNIX, user.notice facility and severity) or to the event log (NT) if probe matches.
$>string	+++ Send string to syslog (UNIX, user.notice facility and severity) or to the event log (NT) if access is rejected.
$Ddelay	Delay response for an interval of delay hundredths of seconds; a positive value causes the delay to be imposed on each command in the transaction; a negative value causes the delay to be imposed only on the address handover (SMTP MAIL FROM: command for the FROM_ACCESS table; SMTP RCPT TO: command for the other tables).
$Ttag	Prefix with tag.
$Aheader	Add the header line header to the message.
$Gconversion_tag	If used in ORIG_SEND_ACCESS, SEND_ACCESS, ORIG_MAIL_ACCESS, and MAIL_ACCESS, it reads a value from the mapping result and treats it as a set of conversion tags to be applied to the current recipient. If used with FROM_ACCESS, conversion tags are applied to all recipients. $G is positioned after $A (header address) in the sequence of arguments read from the mappings. See Mail Conversion Tags.
$Sx,y,z	* Causes an additional \| separated argument to be read from the mapping result. This argument consists of one to three integer values separated by commas. The first value establishes a new minimum blocklimit for the transaction, the second establishes a new minimum recipientlimit, and the third a new minimum recipientcutoff. The argument is read from the mapping result after any capture argument has been read. See Specifying Absolute Message Size Limits for details.
$Xerror-code	Issue the specified error-code extended SMTP error code if rejecting the message.
$,spamadjust_arg	Allows you to perform a sieve spamadjust operation from the access mapping tables. Argument takes the same form as a spamadjust argument. Note also that some of these mappings are applied on a per-recipient basis. Any spamadjust operation that is done applies to all recipients.
$Nstring	Reject access with the optional error text string.
$Fstring	Synonym for $N string; that is, reject access with the optional error text string.
* Available for FROM_ACCESS table only. + To use multiple flags with arguments, separate the arguments with the vertical bar character, \|, placing the arguments in the order listed in this table. ++ For the $K flag to take effect in the FROM_ACCESS mapping table, the source channel must include the authrewrite keyword. +++ It is a good idea to use the $D flag when dealing with problem senders, to prevent a denial of service attack. In particular, it is a good idea to use $D in any $> entry or $< entry rejecting access.

SEND_ACCESS and ORIG_SEND_ACCESS Tables

You can use the SEND_ACCESS and ORIG_SEND_ACCESS mapping tables to control who can or cannot send mail, receive mail, or both. The access checks have available a message’s envelope From: address and envelope To: addresses, and knowledge of what channel the message came in, and what channel it would attempt to go out.

If a SEND_ACCESS or ORIG_SEND_ACCESS mapping table exists, then for each recipient of every message passing through the MTA, the MTA will scan the table with a string of the following form (note the use of the vertical bar character, |):

The src-channel is the channel queueing the message; from-address is the address of the message's originator; dst-channel is the channel to which the message will be queued; and to-address is the address to which the message is addressed. Use of an asterisk in any of these four fields causes that field to match any channel or address, as appropriate.

The addresses here are envelope addresses; that is, envelope From: address and envelope To: address. In the case of SEND_ACCESS, the envelope To: address is checked after rewriting, alias expansion, etc., have been performed; in the case of ORIG_SEND_ACCESS the originally specified envelope To: address is checked after rewriting, but before alias expansion.

If the search string matches a pattern (that is, the left-hand side of an entry in the table), then the resulting output of the mapping is checked. If the output contains the flags $Y or $y, then the enqueue for that particular To: address is permitted. If the output contains any of the flags $N, $n, $F, or $f, then the enqueue to that particular address is rejected. In the case of a rejection, optional rejection text may be supplied in the mapping output. This string will be included in the rejection error the MTA issues. If no string is output (other than the $N, $n, $F, or $f flag), then default rejection text will be used. For descriptions of additional flags, see Access Control Mapping Table Flags.

Setting the MTA option ACCESS_ORCPT to 1 adds an additional vertical bar delimited field to the probe value passed to the SEND_ACCESS, ORIG_SEND_ACCESS, MAIL_ACCESS, and ORIG_MAIL_ACCESS mapping tables that contains the original recipient (ORCPT) address. If the message doesn't have an ORCPT address, the original unmodified RCPT TO: address is used instead. The default is 0, and the probe value is at the end:

In the following example, mail sent from UNIX user agents such as mail, Pine, and so on, originates from the local, l, channel and messages to the Internet go out a TCP/IP channel of some sort. Suppose that local users, with the exception of the postmaster, are not allowed to send mail to the Internet but can receive mail from there. Then the SEND_ACCESS mapping table shown in the example below is one possible way to enforce this restriction. In the mapping table, the local host name is assumed to be sesta.com. In the channel name “tcp_*”, a wild card is used so as to match any possible TCP/IP channel name (for example, tcp_local).

In the rejection message, dollar signs are used to quote spaces in the message. Without those dollar signs, the rejection would be ended prematurely and only read “Internet” instead of “Internet postings are not permitted.” Note that this example ignores other possible sources of “local” postings such as from PC-based mail systems or from POP or IMAP clients.

MAIL_ACCESS and ORIG_MAIL_ACCESS Mapping Tables


Note	The client attempting to send the message determines whether the MTA rejection error text is actually presented to the user who attempted to send the message. If SEND_ACCESS is used to reject an incoming SMTP message, the MTA merely issues an SMTP rejection code including the optional rejection text; it is up to the sending SMTP client to use that information to construct a bounce message to send back to the original sender.

The MAIL_ACCESS mapping table is a superset of the SEND_ACCESS and PORT_ACCESS mapping tables. It combines both the channel and address information of SEND_ACCESS with the IP address and port number information of PORT_ACCESS. Similarly, the ORIG_MAIL_ACCESS mapping table is a superset of the ORIG_SEND_ACCESS and PORT_ACCESS mapping tables. The format for the probe string for MAIL_ACCESS is:

Here port-access-probe-info consists of all the information usually included in a PORT_ACCESS mapping table probe in the case of incoming SMTP messages; otherwise, it is blank. app-info includes the system name claimed in the HELO/EHLO SMTP command. This name appears at the end of the string and is separated from the rest of the string (normally “SMTP”) by a slash. The claimed system name can be useful in blocking some worms and viruses. submit-type may be one of MAIL, SEND, SAML, or SOML, corresponding to how the message was submitted into Messaging Server. Normally the value is MAIL, meaning it was submitted as a message; SEND, SAML, or SOML can occur in the case of broadcast requests (or combined broadcast/message requests) submitted to the SMTP server. And for the MAIL_ACCESS mapping, send-access-probe-info consists of all the information usually included in a SEND_ACCESS mapping table probe. Similarly for the ORIG_MAIL_ACCESS mapping, orig-send-access-probe-info consists of all the information usually included in an ORIG_SEND_ACCESS mapping table probe.

port-access-probe-info|app-info|submit-type|send_access-probe-info|ORCPT_address

Having the incoming TCP/IP connection information available in the same mapping table as the channel and address information makes it more convenient to impose certain sorts of controls, such as enforcing what envelope From: addresses are allowed to appear in messages from particular IP addresses. This can be desirable to limit cases of email forgery, or to encourage users to configure their POP and IMAP clients’ From: address appropriately. For example, a site that wishes to allow the envelope From: address vip@siroe.com to appear only on messages coming from the IP address 1.2.3.1 and 1.2.3.2, and to ensure that the envelope From: addresses on messages from any systems in the 1.2.0.0 subnet are from siroe.com, might use a MAIL_ACCESS mapping table as shown in the example below.

FROM_ACCESS Mapping Table

The FROM_ACCESS mapping table may be used to control who can send mail, or to override purported From: addresses with authenticated addresses, or both.

The input probe string to the FROM_ACCESS mapping table is similar to that for a MAIL_ACCESS mapping table, minus the destination channel and address, and with the addition of authenticated sender information, if available. Thus, if a FROM_ACCESS mapping table exists, then for each attempted message submission, Messaging Server will search the table with a string of the form (note the use of the vertical bar character, |):

Here port-access-probe-info consists of all the information usually included in a PORT_ACCESS mapping table probe in the case of incoming SMTP messages; otherwise, it is blank. app-info includes the system name claimed in the HELO/EHLO SMTP command. This name appears at the end of the string and is separated from the rest of the string (normally “SMTP”) by a slash. The claimed system name can be useful in blocking some worms and viruses. submit-type may be one of MAIL, SEND, SAML, or SOML, corresponding to how the message was submitted into the MTA. Normally the value is MAIL, meaning it was submitted as a message; SEND, SAML, or SOML can occur in the case of broadcast requests (or combined broadcast/message requests) submitted to the SMTP server. src-channel is the channel originating the message (that is, queueing the message); from-address is the address of the message's purported originator; and auth-from is the authenticated originator address, if such information is available, or blank if no authenticated information is available.

If the probe string matches a pattern (that is, the left-hand side of an entry in the table), the resulting output of the mapping is checked. If the output contains the flags $Y or $y, then the enqueue for that particular To: address is permitted. If the output contains any of the flags $N, $n, $F, or $f, then the enqueue to that particular address is rejected. In the case of a rejection, optional rejection text may be supplied in the mapping output. This string will be included in the rejection error Messaging Server issues. If no string is output (other than the $N, $n, $F, or $f flag), then default rejection text will be used. For descriptions of additional flags, see Access Control Mapping Table Flags.

Besides determining whether to allow a message to be submitted based on the originator, FROM_ACCESS can also be used to alter the envelope From: address via the $J flag, or to modify the effect of the authrewrite channel keyword (adding a Sender: header address on an accepted message) via the $K flag. For instance, this mapping table can be used to cause the original envelope From: address to simply be replaced by the authenticated address.

When using the FROM_ACCESS mapping table to modify the effect on having authrewrite set to a nonzero value on some source channel, it is not necessary to use FROM_ACCESS if the authenticated address is going to be used verbatim.

For example, with authrewrite 2 set on the tcp_local channel, the following FROM_ACCESS mapping table would not be necessary because authrewrite alone is sufficient to get this effect (adding the authenticated address verbatim):

However, the real purpose of FROM_ACCESS is to permit more complex and subtle alterations, as shown in the example below. The authrewrite keyword alone is appropriate if you want to add a Sender: header line (showing the SMTP AUTH authenticated submitter address) to incoming messages. However, suppose you want to force the addition of such a Sender: header line to incoming messages only if the SMTP AUTH authenticated submitter address differs from the envelope From: address (that is, not bother to add a Sender: header line if the addresses match), and suppose further that you wish the SMTP AUTH and envelope From: addresses will not be considered to differ merely because the envelope From: includes optional subaddress information.

PORT_ACCESS Mapping Table

The Dispatcher is able to selectively accept or reject incoming connections based on IP address and port number. At Dispatcher startup time, the Dispatcher will look for a mapping table named PORT_ACCESS. If present, the Dispatcher will format connection information in the following form:

The Dispatcher tries to match against all PORT_ACCESS mapping entries. If the result of the mapping contains $N or $F, the connection will be immediately closed. Any other result of the mapping indicates that the connection is to be accepted. $N or $F may optionally be followed by a rejection message. If present, the message will be sent back down the connection just prior to closure. Note that a CRLF terminator will be appended to the string before it is sent back down the connection.


Note	The MMP does not make use of the PORT_ACCESS mapping table. If you wish to reject SMTP connections from certain IP addresses and you are using the MMP, you must use the TCPAccess option. See To Configure Mail Access with MMP. If you want to control SMTP connections using mapping tables, use the INTERNAL_IP mapping table (see Allowing SMTP Relaying for External Sites).

The flag $< followed by an optional string causes Messaging Server to send the string to syslog (UNIX) or to the event log (NT) if the mapping probe matches. The flag $> followed by an optional string causes Messaging Server to send the string as to syslog (UNIX) or to the event log (NT) if access is rejected. If bit 1 of the LOG_CONNECTION MTA option is set and the $N flag is set so that the connection is rejected, then also specifying the $T flag will cause a “T” entry to be written to the connection log. If bit 4 of the LOG_CONNECTION MTA option is set, then site-supplied text may be provided in the PORT_ACCESS entry to include in the “C” connection log entries. To specify such text, include two vertical bar characters in the right-hand side of the entry, followed by the desired text. Table 17-3 lists the available flags.

Table 17-3 PORT_ACCESS Mapping Flags
Flag	Description
$Y	Allow access.
Flags with arguments, in argument reading order+
$< string	Send string to syslog (UNIX) or to the event log (NT) if probe matches.
$> string	Send string to syslog (UNIX) or to the event log (NT) if access is rejected.
$N string	Reject access with the optional error text string
$F string	Synonym for $N string; that is, reject access with the optional error text string
$T text	If bit 1 of the LOG_CONNECTION MTA option is set and the $N flag is set so that the connection is rejected, then $T causes a “T” entry to be written to the connection log; the optional text (which must appear subsequent to two vertical bar characters) may be included in the connection log entry.
+To use multiple flags with arguments, separate the arguments with the vertical bar character, \|, placing the arguments in the order listed in this table.

For example, the following mapping will only accept SMTP connections (to port 25, the normal SMTP port) from a single network, except for a particular host singled out for rejection without explanatory text:

Note that you will need to restart the Dispatcher after making any changes to the PORT_ACCESS mapping table so that the Dispatcher will see the changes. (If you are using a compiled MTA configuration, you will first need to recompile your configuration to get the change incorporated into the compiled configuration.)

The PORT_ACCESS mapping table is specifically intended for performing IP-based rejections. For more general control at the email address level, the SEND_ACCESS or MAIL_ACCESS mapping table, might be more appropriate.

To Limit Specified IP Address Connections to the MTA

A particular IP address can be limited to how often it connects to the MTA by using the shared library, conn_throttle.so in the Port Access mapping table. Limiting connections by particular IP addresses may be useful for preventing excessive connections used in denial-of-service attacks.

conn_throttle.so is a shared library used in a PORT_ACCESS mapping table to limit MTA connections made too frequently from particular IP addresses. All configuration options are specified as parameters to the connection throttle shared library as follows:

IP-address is the dotted-decimal address of the remote system. max-rate is the connections per minute that shall be the enforced maximum rate for this IP-address.

The routine name throttle_p may be used instead of throttle for a penalizing version of the routine. throttle_p will deny connections in the future if they’ve connected too many times in the past. If the maximum rate is 100, and 250 connections have been attempted in the past minute, not only will the remote site be blocked after the first 100 connections in that minute, but they’ll also be blocked during the second minute. In other words, after each minute, max-rate is deducted from the total number of connections attempted and the remote system is blocked as long as the total number of connections is greater than the maximum rate.

If the IP-address specified has not exceeded the maximum connections per minute rate, the shared library callout will fail.

If the rate has been exceeded, the callout will succeed, but will return nothing. This is done in a $C/$E combination as in the example:

PORT_ACCESS

TCP|*|25|*|* \
$C$[msg_svr_base/lib/conn_throttle.so,throttle,$1,10] \
$N421$ Connection$ not$ accepted$ at$ this$ time$E

$C continues the mapping process starting with the next table entry; uses the output string of this entry as the new input string for the mapping process.

$[msg_svr_base/lib/conn_throttle.so,throttle,$1,10] is the library call with throttle as the library routine, $1 as the server IP Address, and 10 the connections per minute threshold.

$N421$ Connection$ not$ accepted$ at$ this$ time rejects access and returns the 421 SMTP code (transient negative completion) along with the message “Connection not accepted at this time.”

$E ends the mapping process now. It uses the output string from this entry as the final result of the mapping process.

When Access Controls Are Applied

Messaging Server checks access control mappings as early as possible. Exactly when this happens depends upon the email protocol in use—when the information that must be checked becomes available.

For the SMTP protocol, a FROM_ACCESS rejection occurs in response to the MAIL FROM: command, before the sending side can send the recipient information or the message data. A SEND_ACCESS or MAIL_ACCESS rejection occurs in response to the RCPT TO: command, before the sending side gets to send the message data. If an SMTP message is rejected, Messaging Server never accepts or sees the message data, thus minimizing the overhead of performing such rejections.

If multiple access control mapping tables exist, Messaging Server checks them all. That is, a FROM_ACCESS, a SEND_ACCESS, an ORIG_SEND_ACCESS, a MAIL_ACCESS, and ORIG_MAIL_ACCESS mapping tables may all be in effect.

To Test Access Control Mappings

The imsimta test -rewrite utility—particularly with the -from, -source_channel, -sender and -destination_channel options—can be useful in testing access control mappings. See the Sun Java System Messaging Server Administration Reference (http://docs.sun.com/doc/819-0106) for details. The example below shows a sample SEND_ACCESS mapping table and the resulting probe.

To Add SMTP Relaying

The Messaging Server is, by default, configured to block attempted SMTP relays; that is, it rejects attempted message submissions to external addresses from unauthenticated external sources (external systems are any other system than the host on which the server itself resides). This default configuration is quite aggressive in blocking SMTP relaying in that it considers all other systems to be external systems.

IMAP and POP clients that attempt to submit messages via the Messaging Server system’s SMTP server destined for external addresses, and who do not authenticate using SMTP AUTH (SASL), will find their submission attempts rejected. Thus, you will likely want to modify your configuration so that it recognizes your own internal systems and subnets from which relaying should always be accepted.

Which systems and subnets are recognized as internal is normally controlled by the INTERNAL_IP mapping table, which may be found in msg_svr_base/config/mappings

For instance, on an Messaging Server system whose IP address is 123.45.67.89, the default INTERNAL_IP mapping table would appear as follows:

Here the initial entry, using the $(IP-pattern/signicant-prefix-bits) syntax, is specifying that any IP address that matches all 32 bits of 123.45.67.89 should match and be considered internal. The second entry recognizes the loopback IP address 127.0.0.1 as internal. The final entry specifies that all other IP addresses should not be considered internal. Note that all entries must be preceded by at least one space.

You may add additional entries by specifying additional IP addresses or subnets before the final $N entry. These entries must specify an IP address or subnet (using the $(.../...) syntax to specify a subnet) on the left side and $Y on the right side. Or you may modify the existing $(.../...) entry to accept a more general subnet.

For instance, if this same sample site has a class-C network, that is, it owns all of the 123.45.67.0 subnet, then the site would want to modify the initial entry by changing the number of bits used in matching the address. In the mapping table below, we change from 32 bits to 24 bits. This allows all clients on the class-C network to relay mail through this SMTP relay server.

Or if the site owns only those IP addresses in the range 123.45.67.80-123.45.67.99, then the site would want to use:

Note that the imsimta test -match utility can be useful for checking whether an IP address matches a particular $(.../...) test condition. The imsimta test -mapping utility can be more generally useful in checking that your INTERNAL_IP mapping table returns the desired results for various IP address inputs.

After modifying your INTERNAL_IP mapping table, be sure to issue the imsimta restart command (if you are not running with a compiled configuration) or the imsimta refresh command (if you are running with a compiled configuration) so that the changes take effect.

Further information on the mapping file and general mapping table format, as well as information on imsimta command line utilities, can be found in the Messaging Server Reference Manual.

Allowing SMTP Relaying for External Sites

All internal IP addresses should be added to the INTERNAL_IP mapping table as discussed above. If you have friendly or companion systems/sites from which you wish to allow SMTP relaying, the simplest approach is to include them along with your true internal IP addresses in your INTERNAL_IP mapping table.

If you don’t wish to consider these as true internal systems/sites, (for instance, if for logging or other control purposes you wish to distinguish between true internal systems versus the friendly non-internal systems with relay privileges), there are other ways to configure the system.

One approach is to set up a special channel for receiving messages from such friendly systems. Do this by creating a tcp_friendly channel akin to your existing tcp_internal channel with official host name tcp_friendly-daemon, and a FRIENDLY_IP mapping table akin to your INTERNAL_IP mapping table that lists the friendly system IP addresses. Then right after the current rewrite rule:

! Do mapping lookup for internal IP addresses
[] $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon

! Do mapping lookup for "friendly", non-internal IP addresses []
$E$R${FRIENDLY_IP,$L}$U%[$L]@tcp_friendly-daemon

An alternate approach is to add to your ORIG_SEND_ACCESS mapping table above the final $N entry, new entries of the form

where siroe.com is the name of a friendly domain, and to add an ORIG_MAIL_ACCESS mapping table of the form:

ORIG_MAIL_ACCESS

   TCP|*|25|$(match-siroe.com-IP-addresses)|*|SMTP|MAIL|    \
tcp_local|*@siroe.com|tcp_local|*     $Y
   TCP|*|*|*|*|SMTP|MAIL|tcp_local|*|tcp_local|*    $N

table, where the $(...) IP address syntax is the same syntax described in the previous section. The ORIG_SEND_ACCESS check will succeed as long as the address is ok, so we can go ahead and also do the ORIG_MAIL_ACCESS check which is more stringent and will only succeed if the IP address also corresponds to an siroe.com IP address.

Configuring SMTP Relay Blocking

You can use access control mappings to prevent people from relaying SMTP mail through your Messaging Server system. For example, you can prevent people from using your mail system to relay junk mail to hundreds or thousands of Internet mailboxes.

By default, Messaging Server prevents all SMTP relaying activity, including relaying by local POP and IMAP users.

Blocking unauthorized relaying while allowing it for legitimate local users requires configuring Messaging Server to know how to distinguish between the two classes of users. For example, local users using POP or IMAP depend upon Messaging Server to act as an SMTP relay.

To enable SMTP relay by internal hosts and clients, you must add your “internal” IP addresses or subnets to the INTERNAL_IP mapping table.

How the MTA Differentiates Between Internal and External Mail

In order to block mail relaying activities, the MTA must first be able to differentiate between internal mail originated at your site and external mail originated out on the Internet and passing through your system back out to the Internet. The former class of mail you want to permit; the latter class you want to block. This differentiation is achieved using the switchchannel keyword on your inbound SMTP channel, usually the tcp_local channel, and is set by default.

The switchchannel keyword works by causing the SMTP server to look at the actual IP address associated with the incoming SMTP connection. Messaging Server uses that IP address, in conjunction with your rewrite rules, to differentiate between an SMTP connection originated within your domain and a connection from outside of your domain. This information can then be used to segregate the message traffic between internal and external traffic.

The MTA configuration described below is setup by default so that the server can differentiate between your internal and external message traffic.

With the above configuration settings, SMTP mail generated within your domain will come in via the tcp_intranet channel. All other SMTP mail will come in via the tcp_local channel. Mail is distinguished between internal and external based upon which channel it comes in on.

How does this work? The key is the switchchannel keyword. The keyword is applied to the tcp_local channel. When a message comes in your SMTP server, that keyword causes the server to look at the source IP address associated with the incoming connection. The server attempts a reverse-pointing envelope rewrite of the literal IP address of the incoming connection, looking for an associated channel. If the source IP address matches an IP address or subnet in your INTERNAL_IP mapping table, the rewrite rule which calls out to that mapping table causes the address to rewrite to the tcp_intranet channel.

Since the tcp_intranet channel is marked with the allowswitchchannel keyword, the message is switched to the tcp_intranet channel and comes in on that channel. If the message comes in from a system whose IP address is not in the INTERNAL_IP mapping table, the reverse-pointing envelope rewrite will either rewrite to the tcp_local or, perhaps to some other channel. However, it will not rewrite to the tcp_intranet channel and since all other channels are marked noswitchchannel by default, the message will not switch to another channel and will remain with the tcp_local channel.

Differentiate Authenticated Users' Mail


Note	Note that any mapping table or conversion file entries which use the string “tcp_local” may need to be changed to either “tcp_*” or “tcp_intranet” depending upon the usage.

Your site might have “local” client users who are not part of your physical network. When these users submit mail, the message submissions come in from an external IP address—for instance, arbitrary Internet Service Providers. If your users use mail clients that can perform SASL authentication, then their authenticated connections can be distinguished from arbitrary other external connections. The authenticated submissions you can then permit, while denying non-authenticated relay submission attempts. Differentiating between authenticated and non-authenticated connections is achieved using the saslswitchchannel keyword on your inbound SMTP channel, usually the tcp_local channel.

The saslswitchchannel keyword takes an argument specifying the channel to switch to; if an SMTP sender succeeds in authenticating, then their submitted messages are considered to come in the specified switched to channel.

With this configuration, SMTP mail sent by users who can authenticate with a local password will now come in the tcp_auth channel. Unauthenticated SMTP mail sent from internal hosts will still come in tcp_internal. All other SMTP mail will come in tcp_local.

Prevent Mail Relay

Now to the point of this example: preventing unauthorized people from relaying SMTP mail through your system. First, keep in mind that you want to allow local users to relay SMTP mail. For instance, POP and IMAP users rely upon using Messaging Server to send their mail. Note that local users may either be physically local, in which case their messages come in from an internal IP address, or may be physically remote but able to authenticate themselves as local users.

You want to prevent random people out on the Internet from using your server as a relay. With the configuration described in the following sections, you can differentiate between these classes of users and block the correct class. Specifically, you want to block mail from coming in your tcp_local channel and going back out that same channel. To that end, an ORIG_SEND_ACCESS mapping table is used.

An ORIG_SEND_ACCESS mapping table may be used to block traffic based upon the source and destination channel. In this case, traffic from and back to the tcp_local channel is to be blocked. This is realized with the following ORIG_SEND_ACCESS mapping table:

In this example, the entry states that messages cannot come in the tcp_local channel and go right back out it. That is, this entry disallows external mail from coming in your SMTP server and being relayed right back out to the Internet.

An ORIG_SEND_ACCESS mapping table is used rather than a SEND_ACCESS mapping table so that the blocking will not apply to addresses that originally match the ims-ms channel (but which may expand via an alias or mailing list definition back to an external address). With a SEND_ACCESS mapping table one would have to go to extra lengths to allow outsiders to send to mailing lists that expand back out to external users, or to send to users who forward their messages back out to external addresses.

To Use DNS Lookups Including RBL Checking for SMTP Relay Blocking

In the Messaging Server, there are a number of different ways to ensure that all mail accepted for delivery or forwarding comes from an address with a valid DNS name. The simplest way is to put the mailfromdnsverify channel keyword on the tcp_local channel.

Messaging Server also provides the dns_verify program which allows you to ensure that all mail accepted for delivery or forwarding comes from an address with a valid DNS name using the following rule in ORIG_MAIL_ACCESS:

The line breaks in the above example are syntactically significant in such mapping entries. The backslash character is a way of legally continuing on to the next line.

The dns_verify image can also be used to check incoming connections against things like the RBL (Realtime Blackhole List), MAPS (Mail Abuse Prevention System, DUL (Dial-up User List), or ORBS (Open Relay Behavior-modification System) lists as another attempt to protect against UBE. As with the new mailfromdnsverify keyword, there’s also a separate “simpler to configure” approach one can use for such checks rather than doing the dns_verify callout. The simpler approach is to use the DNS_VERIFY_DOMAIN option in the dispatcher.cnf file. For example, in the [SERVICE=SMTP] section, set instances of the option to the various lists you want to check against:

[SERVICE=SMTP]
PORT=25
! ...rest of normal options...
DNS_VERIFY_DOMAIN=rbl.maps.vix.com
DNS_VERIFY_DOMAIN=dul.maps.vix.com
!...etc...

In this case, messages are rejected at the SMTP level, that is, the messages are rejected during the SMTP dialogue and thus never sent to the MTA. The disadvantage of this simpler approach is that it does the checks for all normal incoming SMTP messages including those from internal users. This is less efficient and potentially problematic if your Internet connectivity goes down. An alternative is to call out to dns_verify from a PORT_ACCESS mapping table or ORIG_MAIL_ACCESS mapping table. In the PORT_ACCESS mapping table, you can have an initial entry or entries that don’t check for local internal IP addresses or message submitters and a later entry that does the desired check for everyone else. Or, in an ORIG_MAIL_ACCESS mapping table, if you only apply the check on messages coming in the tcp_local channel then you’re skipping it for messages coming from your internal systems/clients. Examples using the entry points to dns_verify are shown below.

PORT_ACCESS

! Allow internal connections in unconditionally
*|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E
! Check other connections against RBL list
TCP|*|25|*|* \
$C$[msg_svr_base/lib/dns_verify.so, \
dns_verify_domain_port,$1,rbl.maps.vix.com.]EXTERNAL$E

ORIG_MAIL_ACCESS

TCP|*|25|*|*|SMTP|*|tcp_local|*@*|*|* \
$C$[msg_svr_base/lib/dns_verify.so, \
dns_verify_domain,$1,rbl.maps.vix.com.]$E

Support for DNS-based Databases

The dns_verify program supports DNS-based databases used to determine incoming SMTP connections that might send unsolicited bulk mail. Some of the publicly available DNS databases do not contain TXT records that are typically used for this purpose. Instead, they only contain A records.

In a typical setup, the TXT record found in the DNS for a particular IP address contains an error message suitable to return to the SMTP client when refusing a message. But, if a TXT record is not found and an A record is found, then versions of dns_verify prior to Messaging Server 5.2 returned the message “No error text available.”

dns_verify now supports an option that specifies a default text that is used in the event that no TXT record is available. For example, the following PORT_ACCESS mapping table shows how to enable this option:

PORT_ACCESS

    *|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E \
    TCP|*|25|*|* \
$C$[<msg_svr_base/lib/dns_verify.so \
,dns_verify_domain_port,$1,dnsblock.siroe.com,Your$ host$ ($1)$ \
found$ on$ dnsblock$ list]$E
    * $YEXTERNAL

In this example, if the remote system is found in a query in the domain dnsblock.siroe.com, but no TXT record is available, then the following message is returned, “Your host a.b.c.d found on dnsblock list.”

Handling Large Numbers of Access Entries

Sites that use very large numbers of entries in mapping tables should consider organizing their mapping tables to have a few general wildcarded entries that call out to the general database for the specific lookups. It is much more efficient to have a few mapping table entries calling out to the general database for specific lookups than to have huge numbers of entries directly in the mapping table.

One case in particular is that some sites like to have per user controls on who can send and receive Internet email. Such controls are conveniently implemented using an access mapping table such as ORIG_SEND_ACCESS. For such uses, efficiency and performance can be greatly improved by storing the bulk of the specific information (e.g., specific addresses) in the general database with mapping table entries structured to call out appropriately to the general database.

Rather than using such a mapping table with each user individually entered into the table, a more efficient setup (much more efficient if hundreds or thousands of user entries are involved) is shown in the example below, which shows sample source text file for a general database and a sample ORIG_SEND_ACCESS mapping table. To compile this source file into database format run the imsimta crdb command:

for detailed information about the imsimta crdb utility, refer to the Sun Java System Messaging Server Administration Reference.

In this example, the use of the arbitrary strings SEND| and RECV| in the general database left-hand sides (and hence in the general database probes generated by the mapping table) provides a way to distinguish between the two sorts of probes being made. The wrapping of the general database probes with the $C and $E flags, as shown, is typical of mapping table callouts to the general database.

The above example showed a case of simple mapping table probes getting checked against general database entries. Mapping tables with much more complex probes can also benefit from use of the general database.

PART 2. MAILBOX FILTERS

Mailbox filters, also called Sieve filters, filter messages containing specified strings found in the message headers and apply specified actions to these mail message. Adminstrators can filter mail streams going to a user, through a channel, or through an MTA. Messaging Server filters are stored on the server and evaluated by the server, hence, they are sometimes called server-side rules (SSR).

Sieve Filter Support

Messaging Server filters are based on the Sieve filtering language, Draft 9 of the Sieve Internet Draft. See RFC3028 for more information about Sieve syntax and semantics. In addition, Messaging Server also supports the following Sieve extensions:

Sieve Filtering Overview

A Sieve filter consists of one or more conditional actions to apply to a mail message depending upon a string found in the message header. As an administrator, you can create channel-level filters and MTA-wide filters to prevent delivery of unwanted mail. Users can create per-user filters for their own mailboxes using Messenger Express. Specific instructions for this are described in the Messenger Express on-line help.

By default, each user has no mailbox filter. When a user uses the Messenger Express interface to create one or more filters, then their filters are stored in the Directory and retrieved by the MTA during the directory synchronization process.

To Create User-level Filters

Per-user mail filters apply to messages destined for a particular user’s mailbox. Per-user mail filters can only be created using Messenger Express.

To Create Channel-level Filters

Channel-level filters apply to each message enqueued to a channel. A typical use for this type of filter is to block messages going through a specific channel.

The destinationfilter channel keyword enables message filtering on messages enqueued to the channel to which it is applied. The sourcefilter channel keyword enables message filtering on messages enqueued by (from) the channel to which it is applied. These keywords each have one required parameter which specifies the path to the corresponding channel filter file associated with the channel.

where URL-pattern is a URL specifying the path to the filter file for the channel in question. In the following example, channel-name is the name of the channel.

The filter channel keyword enables message filtering on the channels to which it is applied. The keyword has one required parameter which specifies the path to the filter files associated with each envelope recipient who receives mail via the channel.

URL-pattern is a URL that, after processing special substitution sequences, yields the path to the filter file for a given recipient address. URL-pattern can contain special substitution sequences that, when encountered, are replaced with strings derived from the recipient address, local-part@host.domain in question. These substitution sequences are shown in Table 17-4.

The fileinto keyword specifies how to alter an address when a mailbox filter fileinto operator is applied. The following example specifies that the folder name should be inserted as a subaddress into the original address, replacing any originally present subaddress:

Table 17-4 filter Channel Keyword *URL-pattern* Substitution Tags (Case-insensitive)
Tag	Meaning
*	Perform group expansion.
**	Expand the attribute mailForwardingAddress. This can be a multivalued attribute resulting in several delivery addresses being produced.
$$	Substitute in the $ character
$\	Force subsequent text to lower case
$^	Force subsequent text to upper case
$_	Perform no case conversion on subsequent text
$~	Substitute in the file path for the home directory associated with the local part of the address
$1S	As $S, but if no subaddress is available just insert nothing
$2S	As $S, but if no subaddress is available insert nothing and delete the preceding character
$3S	As $S, but if no subaddress is available insert nothing and ignore the following character
$A	Substitute in the address, local-part@ host.domain
$D	Substitute in host.domain
$E	Insert the value of the second spare attribute, LDAP_SPARE_1
$F	Insert the name of the delivery file (mailDeliveryFileURL attribute)
$G	Insert the value of the second spare attribute, LDAP_SPARE_2
$H	Substitute in host
$I	Insert the hosted domain (part of UID to the right of the separator specified by domainUidSeparator). Fail if no hosted domain is available
$1I	As $I, but if no hosted domain is available just insert nothing
$2I	As $I, but if no hosted domain is available insert nothing and delete the preceding character
$3I	As $I, but if no hosted domain is available insert nothing and ignore the following character
$L	Substitute in local-part
$M	Insert the UID, stripped of any hosted domain
$P	Insert the method name (mailProgramDeliveryInfo attribute)
$S	Insert the subaddress associated with the current address. The subaddress is that part of the user part of the original address after the subaddress separator, usually +, but can be specified by the MTA option SUBADDRESS_CHAR. Fail if no subaddress is given
$U	Insert the mailbox part of the current address. This is either the whole of the address to the left of the @ sign, or that part of the left hand side of the address before the subaddress separator, +.

To Create MTA-Wide Filters

MTA-wide filters apply to all messages enqueued to the MTA. A typical use for this type of filter is to block unsolicited bulk email or other unwanted messages regardless of the messages’ destinations. To create an MTA-wide filter:

When using a compiled configuration, the MTA-wide filter file is incorporated into the compiled configuration.

Routing Discarded Messages Out the FILTER_DISCARD Channel

By default, messages discarded via a mailbox filter are immediately discarded (deleted) from the system. However, when users are first setting up mailbox filters (and perhaps making mistakes), or for debugging purposes, it can be useful to have the deletion operation delayed for a period.

To have mailbox filter discarded messages temporarily retained on the system for later deletion, first add a filter_discard channel to your MTA configuration with the notices channel keyword specifying the length of time (normally number of days) to retain the messages before deleting them, as shown in the following example:

Then set the option FILTER_DISCARD=2 in the MTA option file. Messages in the filter_discard queue area should be considered to be in an extension of users’ personal wastebasket folders. As such, note that warning messages are never sent for messages in the filter_discard queue area, nor are such messages returned to their senders when a bounce or return is requested. Rather, the only action taken for such messages is to eventually silently delete them, either when the final notices value expires, or if a manual bounce is requested using a utility such as imsimta return.

Prior to Messaging Server 6 2004Q2, the use of the filter_discard channel by the jettison Sieve action was controlled by the FILTER_DISCARD MTA option. This is now controlled by the option FILTER_JETTISON, which takes its default from the FILTER_DISCARD setting. FILTER_DISCARD in turn defaults to 1 (discards go to the bitbucket channel).

To Debug User-level Filters

If a user complains that a Sieve filter is not behaving as expected, there are a number of steps you can take to debug the filters. These are described here.

For fileinto filtering to work, check that in the imta.cnf file that the ims-ms channel is marked as follows:

fileinto $u+$s@$d

Get the user level filters from the user’s LDAP entry.

User level filters are stored in their LDAP entry under the MailSieveRuleSource attribute(s). To retrieve this with a ldapsearch command, remember they are base64 encoded so you will need to decode the output by using the -Bo switch.

./ldapsearch -D "cn=directory manager" -w password -b "o=alcatraz.sesta.com,o=isp" -Bo uid=test

The imsimta test -rewrite command, described below, will also automatically decode them.

Verify that the user’s filters are being seen by the MTA.

Issue the command:

# imsimta test -rewrite -filter -debug user@sesta.com

This should output the user’s Sieve filters that you retrieve in the previous step. If you do not see the filters, then you need to figure out why the LDAP entry isn't returning them. If the imsimta test -rewrite output shows the filters, then you know that the user’s filters are being seen by the MTA. The next step is to test the interpretation of the filters by using the imsimta test -expression command.

Use imsimta test -exp to debug the user's filter. The following information is required:

The user's Sieve language statements from their mailSieveRuleSource attribute. See the steps above.

The rfc2822 message that was supposed to trigger the filter.

Description of what they expected the filter to do to the message.

Create a text file (example: temp.filter) containing the Sieve language statements based on the user's mailSieveRuleSource: values. Example:

require "fileinto";
if anyof(header :contains
["To","Cc","Bcc","Resent-to","Resent-cc",
"Resent-bcc"] "commsqa"){
fileinto "QMSG";
}

Expected result: if commsqa is a recipient for this message, then file the message into a folder called QMSG.

Create a text file called test.msg that contains the contents of the rfc2822 message file supplied by user.

You can either use a .msg file from the user's message store area, or create a text file called test_rfc2822.msg that contains the contents of the rfc2822 message file supplied by user.

Use the imsimta test -exp command:

# imsimta test -exp -mm -block -input=temp.filter -message=test_rfc2822.msg

Examine the output.

The last lines of the imsimta test -exp command will show the result of the Sieve interpretation.They will look like this:

Sieve Result: []
or this:
Sieve Result: [action]

where action is the action that would be done as a result of applying the Sieve filter on this message.

If the criteria of the filter matched, you will have some action displayed as the result. If nothing matched, then the Sieve result will be blank, and there is either a logic error in the Sieve filter or the .msg file doesn't contain matching information. If you get any other error, then there is a syntax error in the Sieve script file, and you need to debug it.

For more details on the output, see imsimta test -exp Output.

If the filter is syntactically valid and results are correct, then the next step is to examine a tcp_local_slave.log debug log file.

It may be that the message file you're testing and the one being sent aren't identical. The only way to see what's being received is to examine a tcp_local_slave.log file. This log will show you the exact message being sent to the MTA and how the filter is being applied to that message.

For more information on getting a tcp_local_slave.log debug file, see the slave_debug keyword in Debugging Keywords.

imsimta test -exp Output

1) The Expression: output lines show the filter being read and parsed from tmp.filter text file. These are not particularly useful in debugging the script.

2) The Dump: output lines are the result of the computer interpreting the Sieve statements. You should not see any errors and the output should seem to match your input. For example the dump shows the word redirect, usr3@sesta.com which is like the line in the filter file redirect "usr3@sesta.com";

If it didn't show this matching text, then you'd be concerned, otherwise, these also are not particularly useful in debugging the script.

3) At the bottom of the output you will get the Filter result: statement. As stated earlier there are two possible results:

where action is the action taken by the Sieve script. Note that sometimes the results are expected to be empty. For example, for a discard filter, you should test that it doesn't always discard every .msg file you test it against. If there is some action between the brackets, for example:

This means the text in the rfc2822.msg file matched the filter criteria. In this particular example, the filter will file the mail into folder QMSG and keep a copy in the inbox. The resulting actions in this case are fileinto and keep.

When testing filters you should test various .msg files for both results. You should always test that messages that match your filter are filtered, and messages that you do not want to match are not filtered.

Keep in mind that if for wildcard matches, you must use the :matches test and not :contains. For example, if you wish from=*@sesta.com to match, you must use :matches or the test will fail as it will not ever satisfy the test condition.

imsimta test -exp Syntax

imsimta test -exp tests Sieve language statements against a specified RFC2822 message and sends the results of the filter to standard output.

imsimta test -exp -mm -block -input=Sieve_language_scriptfile -message=rfc2822_message_file

-block treats the entire input as a single Sieve script. The default is to treat each line as a separate script and to evaluate it separately. The Sieve will only be evaluated once the end of file is reached.

-input=Sieve_file is a file containing the Sieve script. The default is to read the test script lines or script block from stdin.

-message=message_file is a text file containing the RFC 2822 message you want to test your Sieve script against. This has to be an RFC 2822 message only. It cannot be a queue file (not a zz*.00 file).

Once activated, this command reads script information, evaluates it in the context of the test message, and writes out the result. The result shows what actions would be taken as well as the result of evaluating the final statement in the script.

-from=address specifies the envelope from: address to be used in envelope tests. The default is to use the value specified by the RETURN_ADDRESS MTA option.

-output=file writes results to file. The default is to write the results of script evaluation to stdout.I think we can get all of these Verizon MTA Minor Features in the JES3 docs.

Previous Contents Index Next
Sun Java System Messaging Server 6 2005Q1 Administration Guide