The 1-PATTERN, 2-PATTERN, 3-PATTERN, and ACCEPT items determine
whether or not the directive applies to a particular message. In
most cases a string comparison is performed between the patterns
1-PATTERN, 2-PATTERN, and 3-PATTERN and, respectively, the FROM:,
TO: and SUBJECT: fields that would be seen in VMS MAIL. Note
that these fields do not correspond exactly to the RFC 822 header
lines of the same name; a complex set of mapping criteria are
used to convert the RFC 822 header lines into VMS MAIL headers.
Moreover, it is possible to rearrange the strings the patterns
are compared against in complex ways using the 1, 2, and 3
actions.
The comparison is not case sensitive. The usual OpenVMS wildcard
characters, * and %, can be used in the patterns. The pattern *
will match anything. For partial matches, the pattern * is used
to indicate a field that should be ignored.
The default string comparison operations can optionally be
replaced with numeric comparisons. This is controlled by the
second and third characters in the ACCEPT item. If present, both
the column values and the comparison strings are converted to
integer values. The match fails if the conversion fails. A single
asterisk in the comparison string disables comparisons for that
column completely. Once converted, the ACCEPT item determines the
type of comparison:
> Match if comparison string is greater than the column value.
>= Match if comparison string is greater than or equal to the
column value.
< Match if comparison string is less than the column value.
<= Match if comparison string is less than or equal to the
column value.
<> Match if comparison string is not equal to the column value.
Once the comparisons, string or numeric, have been performed,
the ACCEPT item determines if the directive should be applied
to the message. Only the first two characters of ACCEPT are
significant at this point. The first character should be one
of the following:
A Always apply this directive; ignore the results of the
comparisons. Note that this directive does not count as
an applied directive (see the O, B, S, and E actions below).
X Never apply this directive; ignore the results of the
comparisons.
T, Apply this directive if the patterns all matched.
Y
F, Apply this directive if the patterns did not all match (i.e.
N some or all failed).
P Apply this directive if at least one of the patterns matched
(i.e. some or all matched). In this case the pattern * is
not treated as a match.
O, Apply this directive if the patterns all matched and
? no previous directive has been applied to the message.
Directives that used the A accept item don't count as having
been applied. DELIVER can also be told to forget the fact
the some directive has been applied by clearing the R flag
with the R action.
B, Apply this directive if a pattern did not match and no
Q previous directive has been applied to the message.
Directives that used the A accept item don't count as having
been applied.
S Apply this directive if at least one pattern matched and
no previous directive has been applied to the message.
Directives that used the A accept item don't count as having
been applied.
E This directive applies if all the patterns matched or no
other directive has been applied so far. Directives that
used the A accept item do not count as having been applied.
Any other character is interpreted as an X.
If the second character is an asterisk, *, then the ACCEPT item
is modified in that it does not count as an applied directive.
This makes it possible for any ACCEPT item to be treated like the
A item (which never sets the applied flag).
Directives are tested in the order they appear in the
MAIL.DELIVERY file.
For example, suppose JIM@EXAMPLE.COM sends a message to
BOB@SAMPLE.COM. The subject line of the message is "Re: Mooses".
BOB's MAIL.DELIVERY file contains the following lines (the
function of the last two columns of each line, the ACTION and
1-PARAMETER items, is described later):
"*FRED@SAMPLE.COM*" * * T Q
"*JIM@EXAMPLE.COM*" * * T A JIM.LOG
* * *mooses* T A MOOSE.LOG
* * * O A OTHER.LOG
* * * A D
The first directive does not apply since the message is not from
FRED@SAMPLE.COM. The second and third directives both apply since
JIM@EXAMPLE.COM is the sender and the subject line contains the
string "mooses". The fourth directive's patterns all match, but
a preceeding directive has applied, so it does not itself apply.
The final directive applies since it would apply to any message.
The result is that three directives apply to this message, and
thus three separate actions are taken in processing the message.
Note that the patterns "*FRED@SAMPLE.COM*" and
"*JIM@EXAMPLE.COM*" are useful since personal name fields
and possibly other addresses and source routes can appear in
addresses; (e.g., the address FRED@SAMPLE.COM might actually
appear as "Fred Smith <fred@sample.com>"). Depending on personal
name fields for message handling is not a good idea since some
users have a tendency to change personal names frequently and
without warning. The use of the leading and trailing asterisks
makes the pattern match any string that contains the address,
regardless of the context of the address; the result is a
MAIL.DELIVERY file which is insensitive to personal names.
If none of the directives in the file are found to apply to and
process the message in some way, the message is just delivered
normally. (Note, however, that an empty MAIL.DELIVERY file by
default is considered an error; unless your system manager has
configured DELIVER otherwise, your e-mail messages will not be
delivered if you have an empty MAIL.DELIVERY file.) The effect of
having no matching directives (in a non-empty MAIL.DELIVERY file)
is similar to the following directive:
* * * A D
Note that the J, K, L, M, R, S, 1, 2, and 3 actions are not
thought of as having "processed" the message and hence do not
block the application of this default.