This section details only Procmail. For information on the
mail command, consult its man page.
Procmail delivers and filters email as it is placed in the mail
spool file of the localhost. It is powerful, gentle on system
resources, and widely used. Procmail can play a critical role in
delivering email to be read by email client applications.
Procmail can be invoked in several different ways. Whenever an
MTA places an email into the mail spool file, Procmail is launched.
Procmail then filters and files the email for the MUA and quits.
Alternatively, the MUA can be configured to execute Procmail any
time a message is received so that messages are moved into their
correct mailboxes. By default, the presence of /etc/procmailrc or of a .procmailrc file (also called an rc file) in the user's home directory invokes
Procmail whenever an MTA receives a new message.
Whether Procmail acts upon an email message depends upon whether
the message matches a specified set of conditions or recipes in the rc file.
If a message matches a recipe, then the email is placed in a
specified file, is deleted, or is otherwise processed.
When Procmail starts, it reads the email message and separates
the body from the header information. Next, Procmail looks for
/etc/procmailrc and rc files in the /etc/procmailrcs directory for default,
system-wide, Procmail environmental variables and recipes. Procmail
then searches for a .procmailrc file in
the user's home directory. Many users also create additional
rc files for Procmail that are referred
to within the .procmailrc file in their
home directory.
The Procmail configuration file contains important environmental
variables. These variables specify things such as which messages to
sort and what to do with the messages that do not match any
recipes.
These environmental variables usually appear at the beginning of
.procmailrc in the following format:
In this example, <env-variable> is the name of the
variable and <value> defines the variable.
There are many environment variables not used by most Procmail
users and many of the more important environment variables are
already defined by a default value. Most of the time, the following
variables are used:
-
DEFAULT — Sets the default
mailbox where messages that do not match any recipes are
placed.
The default DEFAULT value is the same
as $ORGMAIL.
-
INCLUDERC — Specifies additional
rc files containing more recipes for
messages to be checked against. This breaks up the Procmail recipe
lists into individual files that fulfill different roles, such as
blocking spam and managing email lists, that can then be turned off
or on by using comment characters in the user's .procmailrc file.
For example, lines in a user's .procmailrc file may look like this:
MAILDIR=$HOME/Msgs
INCLUDERC=$MAILDIR/lists.rc
INCLUDERC=$MAILDIR/spam.rc
|
If the user wants to turn off Procmail filtering of their email
lists but leave spam control in place, they would comment out the
first INCLUDERC line with a hash mark
character (#).
-
LOCKSLEEP — Sets the amount of
time, in seconds, between attempts by Procmail to use a particular
lockfile. The default is eight seconds.
-
LOCKTIMEOUT — Sets the amount of
time, in seconds, that must pass after a lockfile was last modified
before Procmail assumes that the lockfile is old and can be
deleted. The default is 1024 seconds.
-
LOGFILE — The file to which any
Procmail information or error messages are written.
-
MAILDIR — Sets the current
working directory for Procmail. If set, all other Procmail paths
are relative to this directory.
-
ORGMAIL — Specifies the original
mailbox, or another place to put the messages if they cannot be
placed in the default or recipe-required location.
By default, a value of /var/spool/mail/$LOGNAME is used.
-
SUSPEND — Sets the amount of
time, in seconds, that Procmail pauses if a necessary resource,
such as swap space, is not available.
-
SWITCHRC — Allows a user to
specify an external file containing additional Procmail recipes,
much like the INCLUDERC option, except
that recipe checking is actually stopped on the referring
configuration file and only the recipes on the SWITCHRC-specified file are used.
-
VERBOSE — Causes Procmail to log
more information. This option is useful for debugging.
Other important environmental variables are pulled from the
shell, such as LOGNAME, which is the login
name; HOME, which is the location of the
home directory; and SHELL, which is the
default shell.
A comprehensive explanation of all environments variables, as
well as their default values, is available in the procmailrc man page.
New users often find the construction of recipes the most
difficult part of learning to use Procmail. To some extent, this is
understandable, as recipes do their message matching using
regular expressions, which is a particular
format used to specify qualifications for a matching string.
However, regular expressions are not very difficult to construct
and even less difficult to understand when read. Additionally, the
consistency of the way Procmail recipes are written, regardless of
regular expressions, makes it easy to learn by example. To see
example Procmail recipes, refer to Section
11.4.2.5 Recipe Examples.
Procmail recipes take the following form:
:0<flags>: <lockfile-name>
* <special-condition-character> <condition-1>
* <special-condition-character> <condition-2>
* <special-condition-character> <condition-N>
<special-action-character><action-to-perform>
|
The first two characters in a Procmail recipe are a colon and a
zero. Various flags can be placed after the zero to control how
Procmail processes the recipe. A colon after the <flags> section
specifies that a lockfile is created for this message. If a
lockfile is created, the name can be specified by replacing
<lockfile-name>.
A recipe can contain several conditions to match against the
message. If it has no conditions, every message matches the recipe.
Regular expressions are placed in some conditions to facilitate
message matching. If multiple conditions are used, they must all
match for the action to be performed. Conditions are checked based
on the flags set in the recipe's first line. Optional special
characters placed after the * character
can further control the condition.
The <action-to-perform> specifies the
action taken when the message matches one of the conditions. There
can only be one action per recipe. In many cases, the name of a
mailbox is used here to direct matching messages into that file,
effectively sorting the email. Special action characters may also
be used before the action is specified. Refer to Section
11.4.2.4 Special Conditions and Actions for more
information.
The action used if the recipe matches a particular message
determines whether it is considered a delivering or non-delivering recipe. A delivering recipe contains
an action that writes the message to a file, sends the message to
another program, or forwards the message to another email address.
A non-delivering recipe covers any other actions, such as a
nesting block. A nesting block is a set of
actions, contained in braces { }, that are performed on messages which match the
recipe's conditions. Nesting blocks can be nested inside one
another, providing greater control for identifying and performing
actions on messages.
When messages match a delivering recipe, Procmail performs the
specified action and stops comparing the message against any other
recipes. Messages that match non-delivering recipes continue to be
compared against other recipes.
Flags are essential to determine how or if a recipe's conditions
are compared to a message. The following flags are commonly
used:
-
A — Specifies that this recipe is
only used if the previous recipe without an A or a flag also matched
this message.
-
a — Specifies that this recipe is
only used if the previous recipe with an A
or a flag also matched this message
and was successfully completed.
-
B — Parses the body of the
message and looks for matching conditions.
-
b — Uses the body in any
resulting action, such as writing the message to a file or
forwarding it. This is the default behavior.
-
c — Generates a carbon copy of
the email. This is useful with delivering recipes, since the
required action can be performed on the message and a copy of the
message can continue being processed in the rc files.
-
D — Makes the egrep comparison case-sensitive. By default, the
comparison process is not case-sensitive.
-
E — While similar to the
A flag, the conditions in the recipe are
only compared to the message if the immediately preceding the
recipe without an E flag did not match.
This is comparable to an else action.
-
e — The recipe is compared to the
message only if the action specified in the immediately preceding
recipe fails.
-
f — Uses the pipe as a
filter.
-
H — Parses the header of the
message and looks for matching conditions. This occurs by
default.
-
h — Uses the header in a
resulting action. This is the default behavior.
-
w — Tells Procmail to wait for
the specified filter or program to finish, and reports whether or
not it was successful before considering the message filtered.
-
W — Is identical to w except that "Program failure" messages are
suppressed.
For a detailed list of additional flags, refer to the procmailrc man page.
Lockfiles are very useful with Procmail to ensure that more than
one process does not try to alter a message simultaneously. Specify
a local lockfile by placing a colon (:)
after any flags on a recipe's first line. This creates a local
lockfile based on the destination file name plus whatever has been
set in the LOCKEXT global environment
variable.
Alternatively, specify the name of the local lockfile to be used
with this recipe after the colon.
Special characters used before Procmail recipe conditions and
actions change the way they are interpreted.
The following characters may be used after the * character at the beginning of a recipe's condition
line:
-
! — In the condition line, this
character inverts the condition, causing a match to occur only if
the condition does not match the message.
-
< — Checks if the message is
under a specified number of bytes.
-
> — Checks if the message is
over a specified number of bytes.
The following characters are used to perform special
actions:
-
! — In the action line, this
character tells Procmail to forward the message to the specified
email addresses.
-
$ — Refers to a variable set
earlier in the rc file. This is often
used to set a common mailbox that is referred to by various
recipes.
-
| — Starts a specified program to
process the message.
-
{ and }
— Constructs a nesting block, used to contain additional
recipes to apply to matching messages.
If no special character is used at the beginning of the action
line, Procmail assumes that the action line is specifying the
mailbox in which to write the message.
Procmail is an extremely flexible program, but as a result of
this flexibility, composing Procmail recipes from scratch can be
difficult for new users.
The best way to develop the skills to build Procmail recipe
conditions stems from a strong understanding of regular expressions
combined with looking at many examples built by others. A thorough
explanation of regular expressions is beyond the scope of this
section. The structure of Procmail recipes and useful sample
Procmail recipes can be found at various places on the Internet
(such as https://www.iki.fi/era/procmail/links.html). The proper
use and adaptation of regular expressions can be derived by viewing
these recipe examples. In addition, introductory information about
basic regular expression rules can be found in the grep man page.
The following simple examples demonstrate the basic structure of
Procmail recipes and can provide the foundation for more intricate
constructions.
A basic recipe may not even contain conditions, as is
illustrated in the following example:
The first line specifies that a local lockfile is to be created
but does not specify a name, so Procmail uses the destination file
name and appends the value specified in the LOCKEXT environment variable. No condition is
specified, so every message matches this recipe and is placed in
the single spool file called new-mail.spool, located within the directory
specified by the MAILDIR environment
variable. An MUA can then view messages in this file.
A basic recipe, such as this, can be placed at the end of all
rc files to direct messages to a default
location.
The following example matched messages from a specific email
address and throws them away.
With this example, any messages sent by [email protected] are sent to the
/dev/null device, deleting them.
 |
Caution |
| |
Be certain that rules are working as intended before sending
messages to /dev/null for permanent
deletion. If a recipe inadvertently catches unintended messages,
and those messages disappear, it becomes difficult to troubleshoot
the rule.
A better solution is to point the recipe's action to a special
mailbox, which can be checked from time to time to look for false
positives. Once satisfied that no messages are accidentally being
matched, delete the mailbox and direct the action to send the
messages to /dev/null.
|
The following recipe grabs email sent from a particular mailing
list and places it in a specified folder.
:0:
* ^(From|CC|To).*tux-lug
tuxlug
|
Any messages sent from the [email protected] mailing list are placed
in the tuxlug mailbox automatically for
the MUA. Note that the condition in this example matches the
message if it has the mailing list's email address on the
From, CC, or To lines.
Consult the many Procmail online resources available in Section 11.6 Additional
Resources for more detailed and powerful recipes.
Because it is called by Sendmail, Postfix, and Fetchmail upon
receiving new emails, Procmail can be used as a powerful tool for
combating spam.
This is particularly true when Procmail is used in conjunction
with SpamAssassin. When used together, these two applications can
quickly identify spam emails, and sort or destroy them.
SpamAssassin uses header analysis, text analysis, blacklists, a
spam-tracking database, and self-learning Bayesian spam analysis to
quickly and accurately identify and tag spam.
The easiest way for a local user to use SpamAssassin is to place
the following line near the top of the ~/.procmailrc file:
INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc
|
The /etc/mail/spamassassin/spamassassin-default.rc
contains a simple Procmail rule that activates SpamAssassin for all
incoming email. If an email is determined to be spam, it is tagged
in the header as such and the title is prepended with the following
pattern:
The message body of the email is also prepended with a running
tally of what elements caused it to be diagnosed as spam.
To file email tagged as spam, a rule similar to the following
can be used:
:0 Hw
* ^X-Spam-Status: Yes
spam
|
This rule files all email tagged in the header as spam into a
mailbox called spam.
Since SpamAssassin is a Perl script, it may be necessary on busy
servers to use the binary SpamAssassin daemon (spamd) and client application (spamc). Configuring SpamAssassin this way, however,
requires root access to the host.
To start the spamd daemon, type the
following command as root:
/sbin/service spamassassin start
|
To start the SpamAssassin daemon when the system is booted, use
an initscript utility, such as the Services
Configuration Tool (system-config-services), to turn on the spamassassin service. Refer to Section
1.4.2 Runlevel Utilities for more information about
initscript utilities.
To configure Procmail to use the SpamAssassin client application
instead of the Perl script, place the following line near the top
of the ~/.procmailrc file. For a
system-wide configuration, place it in /etc/procmailrc:
INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc
|
