NAME
sortmail - classify incoming mail
SYNOPSIS
sortmail [ -v ] [ -terse ] [ -home path ] [ -mailbox path ] [ -mailrc
initfile ] [ -sortmailrc initfile ] [ -inbox filename ] [ -mbox ] [
-pop|pop3|pop2 user:password@host ] [ -pop|pop3|pop2 /path ] [ -keep ]
[ -noapop ] [ var=value ] [ -dumpCrcs dbmname ] [ -verify ] [ -version
] username
DESCRIPTION
Sortmail reads and classifies email according to patterns you specify.
It can be used to process incoming mail, filter mailing lists, process
mail folders or download mail from POP servers.
For processing incoming mail, create this .forward file in your home
directory:
"| /path/sortmail user"
Where "/path/sortmail" is the full path where you installed sortmail,
and user is your own userid. The userid must be specified because when
mail arrives, sortmail could be run as root, daemon, or any number of
other uid’s.
Once your .forward file is set up, sortmail will classify incoming mail
according to the patterns in $HOME/.sortmailrc. Your .sortmailrc file
is similar to a news KILL file, but somewhat more powerful. You can
discard mail, have it delivered to your mailbox, have it filed into a
folder, forward it to another address or even pipe it through a shell
command.
Don’t let the long list of options and command below frighten you. New
users might do well to skip to the EXAMPLES section below, and/or read
the README and sample files in /usr/share/doc/sortmail.
When sortmail starts up, it first reads the following config files:
/usr/lib/sortmailrc, /usr/local/lib/sortmailrc, /etc/sortmailrc,
/usr/etc/sortmailrc, /usr/local/etc/sortmailrc, $HOME/.mailrc and
$HOME/.sortmailrc.
OPTIONS
-v Verbose. A message is printed stderr or a log file of
your choosing for every mail message. A second -v
causes a lot more information to be printed.
-terse Set verbosity to 1, omit timestamps.
-home path Set user’s home directory, overriding the default taken
from the user’s passwd entry.
-mailbox path Set the user’s system mailbox, overriding the default
for your system (/var/mail/user).
-mailrc path Set the .mailrc file, overriding the default of
~/.mailrc. Path may be specified as /fullpath, ~/path,
~user/path, or path. The last form is the same as
~/path.
-sortmailrc path
Set the .sortmailrc file, overriding the default of
~/.sortmailrc. Path may be specified as with -mailrc,
above.
-inbox filename
Take input from named file instead of stdin. Filename
may be /abspath "~/path", "~user/path" or "+foldername".
When POP2 protocol is used, this option can be used to
select the inbox instead of the default mailbox.
-mbox Indicates that input is a standard Berkeley mailbox
containing multiple messages, rather than a single
message. Used to process an entire mailbox at once.
-pop user:password@host
Sortmail connects to the specified server, downloads
mail and processes it. If password is not specified,
the user is prompted interactively. Note: it is highly
recommended that you do not specify the password on the
command line on a multi-user system, see below.
Sortmail attempts to use pop3 and pop2 protocols in that
order. For obvious reasons, the user id may not contain
’:’.
Many providers assign usernames that contain ’@’, e.g.
user@foo.com. In this case, the argument to -pop will
look something like user@foo.com@pop.foo.com.
For security reasons, sortmail attempts to hide this
information from the "ps" command, but this does not
work under all operating systems (e.g. Solaris). It is
strongly discouraged to specify the password on the
command line for this reason.
-pop /path This variant of the -pop command reads a single line
from the specified file, containing user:password@host.
This is more secure than specifying the password on the
command line. File must be specified as a full
pathname, starting with ’/’.
-pop3 user:password@host
-pop3 /path Sortmail connects to the specified pop3 server,
downloads mail and processes it.
-pop2 user:password@host
-pop2 /path Sortmail connects to the specified pop2 server,
downloads mail and processes it.
-keep For POP use or when -inbox and -mbox are specified.
Indicates that all messages are to be left in the source
input box instead of being deleted.
-noapop For POP3, do not attempt to use APOP authentication.
This option is used when dealing with broken servers
which do not handle APOP correctly.
variable=value Set a variable on the command line. Spaces are not
permitted in the string.
-dumpCrcs dbmname
Dump the bounce-check database in dbmname.{dir,pag} for
debugging purposes.
-verify Verify only. Examine the mailrc and sortmailrc files
for errors and exit.
-version Print version and exit. If this option fails, you have
version 1.something.
SORTMAILRC FORMAT
Your .sortmailrc file is a series of lines in the form
set variable=value
/regular-expression/modifiers:command[:command...]
[ip-address]modifiers:commands..
[ip-address/mask]modifiers:commands..
[ip-address - ip-address]modifiers:commands..
(logical-expression):command[:command...]
includerc filename
listinclude filename
listexclude filename
header headerline
replace headerline
bouncecheck dbmname
where regular-expression is any ed(1)-style regular expression,
modifier is any of i, t, f, s, h, a, o, and command is one of m, j, v,
f file, a file, d file, +file, or | command. Multiple commands may be
placed on a line, separated by ’:’s. If you need to place a ’:’ within
a command for any reason, escape it with ’\’.
Users of rn-style KILLfiles will be familiar with this format.
The [ip-address] form specifies a literal IP address to be matched
(e.g. 192.168.3.4) or a partial IP address (e.g. 192.168.3). This
differs from a regular expression in that the ’.’ character must match
literally, and the pattern must match at the start (e.g. 129.192.168.3
would not match the pattern given above.) (Note that the ’[]’
characters are literal here, and do not denote an optional argument.)
IP addresses may also be specified as a range, e.g. "[192.168.0.0/16]"
would match all IP addresses containing 192.168 in the first 16 bits.
Finally, IP addresses may also be specified as e.g. "[192.168.0.0 -
"192.168.255.255]".
SEARCH MODIFIERS
These modifiers affect how the regular expression is applied to the
incoming mail. The default is ’s’.
i Ignore case.
o Evaluate variables in pattern only once, when sortmailrc file is
read. Without this option, variables are evaluated every time
the pattern is tested. If the pattern contains no variables,
this modifier has no effect.
s Test the "Subject: " line of the mail against the regular
expression.
t Test the "To: ", "Cc: " and "Apparently-To: " lines of the mail
against the regular expression.
f Test the "From: " line of the mail against the regular
expression.
r Test the Received: lines of the incoming mail against the regular
expression.
h Test the entire header of the incoming mail against the regular
expression.
a Test the entire incoming mail message against the regular
expression.
Any combination of s,t,f,h,a may be used. If none are specified, ’s’
is assumed.
SEARCH COMMANDS
These commands are executed for any message which matches a search
pattern.
:m Send the message to the user’s mailbox.
:m address
Forward the mail to the specified address.
:j Delete the message ("junk" it.)
:e n Set the exit code to n. When processing is complete,
sortmail will exit with the given exit code instead of zero.
:E n Exit immediately with exit code n.
:k Keep the message. When downloading messages from a POP
server, or when -inbox and -mbox are specified, messages are
normally deleted from the mailbox once transfer is
successful. This option causes the message to be left
behind.
:f folder Append the message to the given mail folder. folder may be
in the formats ~/path, /abspath, ~user/path, or +name. The
latter form expands to ~/folder/name where folder is the
value specified for the $folder variable (default is
"folders".)
:+folder Shorthand for "f +folder".
:d file Append the message to the given file in digest form. file
may be in the formats ~/path, /abspath, ~user/path, or +name.
"Digest" form is a stripped form where each message contains
only the "From:", "Subject:" and "Date:" headers, and
messages are separated by a line of dashes.
:a file "Archive". Identical to digest.
:| command
Pipe the mail message through the given shell-command. sh(1)
is used.
:c Continue processing. Normally, sortmail applies search
expressions to mail messages until a match is found. At this
point, the message is dispatched and sortmail is finished.
This command causes sortmail to continue comparing the
message to more patterns. This option may be considered
"continue", "Cc" or "copy" at your whim. Thus, a message may
be sent to more than one destination.
COMMANDS
The following is a list of commands which may be contained within a
.mailrc or .sortmailrc file.
set variable = value
Set an environment variable. Variables used by sortmail are
listed below. Quotes around the string are not needed. Special
characters such as ’$’ or ’\’ may be quoted with ’\’. Variables
may be included within the value string in the form $name or
${name}.
Note that the set command is processed immediately when the
initfile is read. Other commands are processed as mail messages
are read. Thus, all set commands are processed before any other
commands, regardless of their order in the init files.
listinclude filename
Used for mailing list administration (see below). Ignore this
command if you’re not using sortmail to administer a mailing
list.
This command specifies a file containing a list of addresses
which are permitted to post to the list. Each line of the file
contains one regular expression, which represents the email
address of a list member. Lines in the format
User Name <address>
will only use the address part of the line. This allows the
mailing list itself to be used as the include list.
Multiple include lists may be specified with multiple listinclude
commands. If the listinclude command is used, posters to the
list must be found in at least one of the lists. If no include
files are specified, anybody may post.
Messages which are rejected are handled according to the $reject
variable, which must exist and which contains either a filename
or a search command (see below.)
For more on include and exclude files, see MAILING LISTS, below.
listexclude filename
Specify a list of addresses which are not permitted to post to
the list. Same format as listinclude. In order to post to the
list, a user must be in the listinclude file(s) (if any) and not
in the listexclude file(s).
replace Header: value
Used for mailing list processing. Headers lines matching the
specified header are replaced with the new value. If no match is
found, the line is appended to the message header. Typically
used to change the "From: " header to specify the list address
rather than the originator, and to set an "Errors-To: " header.
If the value field is empty, the specified header line is
deleted.
header Header: value
Same format as replace, except that header lines are always
appended to the header, not replaced. Typically used to add
comments.
bouncecheck dbmname
Last resort mechanism for detecting mail loops. A crc-32 hash of
the text portion of the message is computed and stored in
dbmname.{dir,pag}. If another message with the same hash code is
encountered in the next 60 days, the message is rejected and
disposed of as described in $reject
This is not a perfect mechanism, however, as broken mailers may
choose to add some comments to the message before bouncing it
back.
includerc filename
Process commands from named file. Include files may be nested.
VARIABLES
Variables are used in the form $name or ${name}. Variables may appear
anywhere in the init file.
Sortmail uses the following variables, which may be changed in your
.mailrc or .sortmailrc files. Variables may also be set on the command
line.
default Command(s) used to handle unclassifiable mail. The default
behavior is to put unclassifiable mail into mailbox. Another
reasonable value might be "+other".
delay Used to prevent runaway mail loops; especially useful for
mailing list administration. Specifies a delay in seconds to
be imposed before mail is forwarded to another address or
piped through a command. For example, a 600-second delay
(ten minutes) would limit a mail loop to one message every
ten minutes.
folder The user’s mail folders directory. Mail folders are denoted
by a leading ’+’ in their name, and are stored in
~user/$folder/. Default is "folders". Many people choose to
set this to "Mail" instead.
from Used for mailing list administration. Specifies the value of
the "From " line when mail is forwarded to the list. Not all
versions of sendmail will honor this. You may need to make
sortmail suid-uucp or add your username to the "trusted
users" entry in /etc/sendmail.cf.
HOME The user’s home directory. Used to find initialization files
and the user’s folders directory. Default is ~user.
lines Count of lines of text in the message. Set by sortmail and
updated for every message.
logfile Debugging messages are sent to the specified log file. If
sortmail is executed from the command line, the default is
stderr. Otherwise the default is /tmp/sortmail.log.
If logfile cannot be opened, stderr is used. Note that when
sortmail is used from your .forward file to filter incoming
messages, messages sent to stderr will be sent back to the
sender as bounces.
mailbox The user’s mail box. Default is /var/mail/user.
mailrc Full path of the user’s .mailrc file. There’s no real point
in changing this.
maxlines Maximum number of message lines which will be searched during
pattern matching. Restricting this value can make searches
quicker and prevent the /tmp directory from filling. Default
value is 5000.
reject Used for mailing list administration. Specifies the file or
command to which rejected mail is sent.
sendmail The command used to deliver mail. Default value is
"/usr/lib/sendmail -om -oi". If ’%f’ occurs in the string,
it will be expanded to the temporary file name containing the
message. Otherwise, the message will be delivered to the
command’s standard input.
Special values "SMTP" and "SMTP hostname" cause the message
to be delivered directly to an SMTP port.
size Size of message in bytes. Set by sortmail and updated for
every message.
sortmailrc
Full path of the user’s .sortmailrc file. There’s no real
point in changing this.
timeout Timeout in seconds for POP connections.
user The user on behalf of whom sortmail is running. This value
must be specified on the command line when sortmail is
executed from a .forward file, but may be changed later. It
is used to determine the user’s home directory, among other
things.
vacation If set, mail to user will also be piped through vacation(1).
TMPDIR Directory used for temporary files. Default is "/tmp".
In addition, sortmail defines the following environment variables
before passing a message to another program.
FROM The sender of the message
SUBJECT The subject line from the incoming message
EXAMPLES
Here is a sample .sortmailrc file:
set default=+other
/MAILER-DAEMON/f:+bounces
/falk/t:m
/bldg8/t:m
/joe/f:m:c
/for brenda/s:k
/scubaclub/t:+scuba
/scuba/s:+scuba
/marko/f:j
/testing/t:m falk@lab
/jym@apple/f:| /home/falk/bin/fixjim
/^Precedence: junk/h:+other
(/bill/f && /dive/s):+scuba
[211.114.0.0/16]r:j
In this example, the folder directory and other variables have whatever
values were specified in .mailrc. Unclassifiable mail will be sent to
the folder "+other". Mail from "MAILER-DAEMON" is sent to the folder
"+bounces". Mail to "falk" or "bldg8" is sent directly to my mailbox.
Mail from my friend joe is sent directly to my mailbox, and processing
continues in order to see if there’s somewhere else it should go as
well.
Mail labeled "for brenda" is left at the POP server untouched. (This
only works if the email is being downloaded from a POP server; it would
be lost otherwise.)
Mail to the scuba club or with "scuba" in the subject line is sent to
the "+scuba" folder. Mail from marko is thrown away unread. Mail to
the "testing" alias is forwarded to my account on another machine.
Mail from my friend jym, who formats his mail in a funny way is passed
through a shell script which cleans up his messages and appends them to
my mailbox. Mail messages with "^Precedence: junk" anywhere in the
header are filed in +other.
The next-to-last line shows a feature new to sortmail version 2:
logical expressions. In this case, mail from bill with the subject
"dive" is added to the scuba folder. Logical expressions are described
in detail below.
Finally, the last line shows another feature new to sortmail version 2:
IP ranges. In this case, all email with an IP address in the
"211.114.0.0/16" range in a "Received:" line will be junked unread.
Note that the patterns are applied in the order given; it is important,
for example, that the "MAILER-DAEMON" pattern precede the "falk"
pattern so that mail from MAILER-DAEMON is filed in +bounces even if
directed to me personally. Similarly, mail from marko will not be
junked if addressed to me personally.
LOGICAL EXPRESSIONS
Logical expressions allow you to specify more complicated rules for
processing mail. For example, you could specify that all mail from a
certain domain with a size greater than a certain amount be deleted
unread unless a specific keyword were to be found in the header.
Logical expressions consist of the following operators, grouped in
order of precedence:
+----------+-------------------------------------------+
| n | integer constant |
| $var | variable. |
|/pattern/ | regular expression. Evaluates as 0 or 1. |
+----------+-------------------------------------------+
| ! | logical not |
+----------+-------------------------------------------+
| * | multiply |
| / | divide |
+----------+-------------------------------------------+
| + | add |
| - | subtract |
+----------+-------------------------------------------+
| < | less than |
| <= | less than or equal |
| > | greater than |
| >= | greater than or equal |
+----------+-------------------------------------------+
| == | equal |
| != | not equal |
+----------+-------------------------------------------+
| & | logical AND |
| && | logical AND |
+----------+-------------------------------------------+
| | | logical OR |
| || | logical OR |
+----------+-------------------------------------------+
| , | comma |
+----------+-------------------------------------------+
Order of precedence in expression evaluation may be modified by use of
parenthesis.
´:’ commands may follow any close-parenthesis or regular expression.
See examples below.
The second form of logical AND and OR operations ("&&" and "||") are
optimized in this way: If the left half of an AND is false, or the
left half of an OR is true, then the right hand is not evaluated.
Thus, you should place a simple expression (such as a subject match) to
the left and a complex expression (such as a message body search) to
the right. If the simple expression evalutes to false or true
respectively, the complex expression is not tested.
The first form of logical AND and OR operations ("&" and "|") always
test both sides of the expression.
The comma operator deserves a bit of explanation for those not familiar
with the C language. The comma operator evalutes the expressions on
both sides and returns the expression on the right -- ignoring the one
on the left. Thus, the expression "3 , 4" evaluates as 4. The comma
operator is useful only when the expression on the left has some sort
of side effect when evaluated -- i.e. it contains ’:’ commands.
Here are some sample expressions:
(/joe/f):m
mail from joe comes directly to me. This is the same as /joe/f:m
(/joe/f && /dive/s):+scuba
mail from joe with "dive" in the subject line goes to the scuba folder.
(/joe/f && !/dive/s):m
/joe/f:+scuba
mail from joe without "dive" in the subject line goes directly to me.
Else, mail from joe goes to the scuba folder.
(/joe/f && $lines > 1000):j
Looks like joe posted another long boring vacation report to the scuba
list. Junk it.
(/earthlink/r && $size > 32768 &&
!(/key west/ia || /caymans/ia) ):j
Junk it if it came from or passed through earthlink (as shown by the
Received: lines), and the size is greater than 32k and it does not
contain the phrase "key west" or "caymans" anywhere in the message
body. Case is ignored in the body search. Note that we examine the
message body last to avoid downloading the message unnecessarily.
Note also that logical expressions may be continued across multiple
lines as needed.
(1):+maillog:c
An extremely simple expression. (1) is always true, so all mail that
reaches this expression is filed to the folder "maillog". The ":c"
command causes processing to continue.
This expression is a very good one to have at the top of your
.sortmailrc when testing a new configuration. All incoming mail is
copied to a backup log before more complex expressions are tested.
(/joe/f:+joemail && /scuba/:+scuba)
This example shows the use of ’:’ commands within an expression. Mail
from joe goes to the "joemail" folder. If it also contains the subject
"scuba", it goes to the scuba folder as well.
(/joe/f:+joemail , /scuba/:+scuba)
This example shows the use of the ’,’ operator. Mail from joe goes to
the joemail folder. Whether or not this matches, the mail is tested
again to see if it belongs in the scuba folder. If so, then processing
is finished.
(/sex/:+sex && /drugs/:+drugs && /rock-n-roll/:+rock):+bacchanalia
This pattern does not do what it looks like it was intended to do.
That is, at first glance it looks as if the pattern is intended to
place all messages containing "sex" in the subject into the sex folder,
all "drugs" messages into the drugs folder, all "rock-n-roll" messages
into the rock folder and place messages into the bacchanalia folder if
they match on all three keys. However, logical expressions are only
evaluated as far as necessary. If the "sex" pattern is not matched,
the next two will not be tested at all. A "rock-n-roll" message would
be missed by this pattern.
In this case, the ’&’ operator should be used instead of ’&&’.
MAILING LISTS
Skip this section unless you’re using sortmail to administer a mailing
list.
In a homogeneous environment, it is usually not necessary to use
sortmail or any other mail filter. You would simply create the alias
in /etc/aliases and let sendmail(8) handle everything.
However, in a heterogeneous environment, there can be problems. The
internet document Rfc822 specifies the handling of internet mail, but
there are many mailers out there which do not honor Rfc822 and cause
trouble. Not surprisingly, many of the major service providers are
among the worst troublemakers.
What typically happens is that for some reason, some member of your
mailing list suddenly cannot receive mail. The service provider at the
user’s end bounces an error message back to the list itself rather than
to the original sender or the administrator. The error message is then
resent to the list subscribers -- including the the one who cannot
receive mail, causing another bounce. This creates a loop, sending and
resending bounce messages to everybody on the loop every few minutes.
Murphy’s Law states that this will happen while you are on vacation.
Here is how to administer a mailing list:
First, (as root) edit /etc/aliases and add the following lines:
scubaclub: "| /usr/yourname/sortmail -sortmailrc scubaclubrc
yourname"
scubaclub-real: :include:/usr/yourname/scubalist
scubaclub-request: yourname
owner-scubaclub: yourname
The first entry indicates that mail to the scuba club goes through
sortmail, using a specific sortmailrc file. The second entry is the
actual scuba club alias to which sortmail will forward the mail. The
third entry is a standard list address which will be used by users to
contact you directly; this should always exist for any mailing list.
The final entry is used by the sendmail system to send internal errors
back to you.
(Most unix systems require you to run newaliases(8) after editing
/etc/aliases.)
Second, create /usr/yourname/scubalist, containing the names and
addresses of everybody in the list.
yourname <youraddress>
Joe Shmoe <joe@foo.com>
Jane Doe <jane@bar.com>
(etc.)
Third, create a sortmailrc file which will be used to filter incoming
mail.
# general variables
set alias = scubaclub
set owner = yourname
set site = yourhost.com
set digestDir = ~/Maillists/Scubaclub
# mail that makes it through the filter gets mailed to
# the list and archived.
set default = m $alias-real@$site:a $digestDir/archive
# mail that gets rejected is mailed to me
set reject = m $owner
# catch anything that looks like a bounce or a loop
/Mailer-Daemon/f:m $owner
/MAILER-DAEMON/f:m $owner
/Postmaster/f:m $owner
/scubaclub/f:m $owner
/X-List-Name: scubaclub/h:m $owner
bouncecheck $digestDir/bounceDb
# (For some reason, we can’t set Errors-To to $owner@$site,
# because if we do, sendmail will expand $owner into an
# invalid value before connecting to SMTP. It would probably
# be ok if I didn’t have a personal .forward file. By adding
# a ’\’ to the address, we avoid the problem.)
replace Reply-To: $alias@$site
replace Errors-To: \\$owner@$site
header Comment: send add/delete requests to $alias-request@$site
header X-List-Name: $alias
In this example, the variables $alias, $owner, $site and $digestDir are
not used internally by sortmail, but are created for convenience and
generality.
The search patterns are used to detect possible mail loops, and as
such, always send mail to the owner. Mail that makes it without
matching any of the patterns is sent to the list.
As a last resort, the mail is processed by the bouncecheck command
which maintains a database of previously-seen messages and will reject
any message that seems to be a repeat.
If mail passes through all the patterns unmatched, it is probably a
valid message. In this case, the message is processed by the commands
in $other, which mail the message to the actual alias, and append a
digest version of the message to ~/Maillists/Scubaclub/archive.
Finally, the headers of outgoing mail are modified. The "Reply-To:"
header is added so that replies to mail from the list are sent to the
list at large, and not just to the sender of the original message. The
"Errors-To:" header is added so that bounces will be sent to the
administrator instead of to the list in general. (Not all mail
transfer agents honor the "Errors-To:" header.)
The "X-List-Name:" header line serves two purposes. First, it lets
recipients know what they’re receiving. Secondly, it is a trick used
to help detect bounces. It is added so that it may be searched for in
incoming mail. If an incoming message contains this header, it is
likely that this is a bounce, and is sent to the administrator for
inspection.
If some of your list members wish to receive messages in "digest" form,
you can split the list into two sections, one normal and one for the
members who want digests. Add the following line to /etc/aliases:
scubaclub-digest: :include:/usr/yourname/scubadigest
and change $default in /usr/yourname/scubaclubrc:
set default = m $alias-real@foo:a $digestDir/archive:d $digestDir/digest
Now, incoming messages will be copied to ~/Maillists/Scubaclub/digest
as well as to ~/Maillists/Scubaclub/archive. On a nightly basis,
execute a program that will test to see if ~/Maillists/Scubaclub/digest
is non-empty, and if so, mail it to scubaclub-digest@yourhost and empty
it.
#! /bin/sh
#
# collect the digest file, prepend some header info and transmit
digest=/usr/yourname/Maillists/Scubaclub/digest
alias=scubaclub
host=yourhost.com
if [ ! -s $digest ] ; then
exit 0
fi
cat $digest | awk "
BEGIN {
print \"Return-Path: $alias@$host\"
print \"Date: ‘date‘\"
print \"From: $alias@$host\"
print \"To: $alias@$host\"
print \"Subject: $alias digest\"
print \"X-List-Name: $alias\"
print \"\"
print \"\"
}
{print}" | \
/usr/lib/sendmail -om -oi -f$alias@$host $alias-digest
rm $digest
touch $digest
chmod a+w $digest
NOTES
Remember that sortmail can be executed under any userid (e.g. root,
daemon or the sender of the mail) depending on who sent the mail, and
whether or not it came from the local machine. Because of this, you
cannot depend on any user environment to be available, especially
environment variables and path. All filenames and program names should
be specified as full paths, except that "~", "~user" and "+folder"
forms are understood. The permissions of sortmail and every directory
along its path should be such that any user can execute it.
If you pipe incoming mail through a program, that program should not
generate any output to stdout or stderr whatsoever. If it does, that
output will be sent back to the originator of the mail as if the mail
had bounced.
Always test your setup thoroughly, especially when administering mail
lists. Mistakes usually result in bounce messages being sent to the
originator of mail. This can be catastrophic with a mail list. When
testing a mail list, start with a test list containing only your name
and a known bad address to test bounce handling. Use of a logfile and
-v is recommended for the first few days after installing.
The bounce detection mechanism tries to be robust, but as the saying
goes, you can never make a system that’s foolproof because some fools
are ingenious. No matter how thorough the detection mechanism is,
there is a broken mailer out there somewhere that can defeat it.
Never leave a mailing list unattended; that’s when bounce loops always
seem to start. If you go on vacation, either temporarily shut the list
down, or designate someone who can turn it off in an emergency.
EXIT STATUS
The following exit values are returned:
0 Normal exit, mail delivered successfully.
1 Normal exit, but no messages waiting (-mbox and -pop options)
2 User error in command line options.
3 Error in .mailrc or .sortmailrc file.
4 Out of memory
5 Cannot determine user name
6 Cannot determine user directory
7 Cannot open a temporary file. In this case, sortmail attempts to
recover by writing the incoming mail to the user’s inbox.
8 Cannot open bounce-check database (-dumpCrcs command)
9 Cannot open input file (-inbox option).
BUGS
If multiple instances of sortmail are executing and printing status
messages to the same logfile, the output may become jumbled.
The maxlines variable is not yet implemented.
SEE ALSO
Mail(1), procmail(1), fetchmail(1).
COPYRIGHT
Copyright 1990, 1999 by Edward A. Falk (falk@efalk.org)
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
regex.[ch] is covered by the GNU copyleft.
21 Apr 1991