Pipe the mail to the following command(s):
Set the "inter-field seperator" (IFS) to a
space, and -- if that went O.K. (&&) execute
the program named "/usr/local/bin/procmail"
(yours may need to be different -- someone
at primenet should tell you where their
copy of procmail is installed, or you can try
the command which procmail to see if it's
on the patch or locate procmail if they
are maintaining a file locator database).
The procmail program is being passed a
set of switches: "-f-" which tells it to
"update timestamp in the leading the 'From'
line in the header"
(this last bit is rather obscure and has
to do with how messages are normally
stored in your "incoming" or mail file
or "spool" as we Unix hacks like to call it).
The next part of this .forward command is
the Bourne shell's "||" operator which is
basically a continuation from the "and"
(&&) operator that we used before. It
says "or" (if that command didn't work --
i.e. it returned any error) than "exit"
(stop processing) and return an error
number 75 (which we presume is meaningful
to sendmail -- the program that called
this command).
The last part of this .forward expression
is a comment which, according to the man
pages,
is not actually a parameter that is required by proc-
mail, in fact, it will be discarded by sh before procmail
ever sees it; it is however a necessary kludge against
overoptimising sendmail programs:
(quoting from it)
You should just change the phrase YOUR_NAME
to your login name on that system.
This complicated line can be just pasted into most
.forward files, minimally edited and forgotten.
If you did this and nothing else your mail would
basically be unaffected. procmail would just
append new messages into your normal spool file.
If your ISP uses procmail as its local delivery
agent then you can skip the whole part of about
using the .forward file -- or you can use it anyway.
In either event the next step to automating your
mail handling is to create a .procmailrc file in
your home directory. You could actually call
this file anything you wanted -- but then you'd
have to slip the name explicitly into the .forward
file (right before the "||" operator). If you use
.procmailrc than procmail will default to using it.
Now we can get to a specific example. So far, all
we've talked about it how everything gets routed
to procmail -- which mostly involves sendmail and
the Bourne shell's syntax. Almost all sendmails
are configured to use /bin/sh (the Bourne shell)
to interpret alias and .forward "pipes."
So, here's a very simple .procmailrc file:
:0c
$HOME/mail.backup
This just appends an extra copy of all incoming
mail to a file named mail.backup in your
home directory.
Note that a bunch of environment variable are preset
for you.
The :0 line marks the beginning of a "recipe"
(procedure, clause, whatever). :0 can be followed
be any of a number of "flags." There is a literally
dizzying number of ways to combine these flags. The
one flag we're using in this example is 'c' for
"copy."
The way procmail works is to start parsing
it's set of recipes from the beginning of the
.procmailrc file, through any INCLUDE'd files
until a message has been "delivered" (or
"disposed of" as the case may be). Any recipe
can be a "disposition" or "delivery" of the message.
As soon as a message is "delivered" then procmail
closes its files, removes its locks and exits.
If procmail reaches the end of its rc file
(and thus all of the INCLUDE'd files) without
"disposing" of the message -- than the message
is appended to your spool file (which looks
like a normal delivery to you and all of your
"mail user agents" like Eudora, elm, etc).
This explains why procmail is so forgiving
if you have no .procmailrc. It simply
delivers your message to the spool because
it has reached the end of all its recipes
(there were none).
The 'c' flag causes a recipe to work on a "copy"
of the message -- meaning that any actions
taken by that recipe are not considered to be
"dispositions" of the message.
Without the 'c' flag this recipe would catch
all incoming messages, and all your mail would
end up in mail.backup. None of it would get
into your spool file and none of the other recipes
would be parsed.
The next line in this sample recipe is simply
a filename. Like sendmail's aliases and .forward
files -- procmail recognizes three sorts of
disposition to any message. You can append it
to a file, forward it to some other mail address,
or filter it through a program.
Actually there is one special form of "delivery"
or "disposition" that procmail handles. If you
provide it with a directory name (rather than a
filename) it will add the message to that directory
as a separate file. The name of that file will be
based on several rather complicated factors that
you don't have to worry about unless you use
the Rand MH system, or some other relatively
obscure and "exotic" mail agent.
A procmail recipe generally consists of three
parts -- a start line (:0 with some flags) some
conditions (lines starting with a '*' -- asterisk --
character) and one "delivery" line which can be
file/directory name or a line starting with a '!' --
bang -- character or a '|' -- pipe character.
Here's another example:
:0
* ^From.*[email protected]
/dev/null
This is a simple one consisting of no flags,
one condition and a simple file delivery. It simply
throws away any mail from "someone I don't like."
(/dev/null under Unix is a "bit bucket" -- a bottomless
well for tossing unwanted output. DOS has a similar
concept but it's not nearly as handy).
Here's a more complex one:
:0
* !^FROM_DAEMON
* !^FROM_MAILER
* !^X-Loop: [email protected]
| $HOME/bin/my.script
This consists of a set of negative conditions (notice
that the conditions all start with the '!' character).
This means: for any mail that didn't come from a
"daemon" (some automated process) and didn't come from
a "mailer" (some other automated process) and which
doesn't contain any header line of the form:
"X-Loop: myadd...", send it through the script in
my bin directory.
I can put the script directly in the rc file
(which is what most procmail users do most of the
time). This script might do anything to the mail.
In this case -- whatever it does had better be good
because procmail will consider any such mail
to be delivered and any recipes after this will
only be reached by mail from DAEMON's, MAILER's
and any mail with that particular X-Loop: line
in the header.
These two particular FROM_ conditions are actually
"special." They are preset by procmail and actually
refer to a couple of rather complicated regular
expressions that are tailored to match the sorts of
things that are found in the headers of most mail
from daemons and mailers.
The X-Loop: line is a normal procmail condition.
In the RFC822 document (which defines what e-mail
headers should look like on the Internet) any line
started with X- is a "custom" header. This means
that any mail program that wants to can add pretty
much any X- line it wants.
A common procmail idiom is to add an X-Loop: line
to the header of any message that we send out --
and to check for our own X-Loop: line before
sending out anything. This is to protect against
"mail loops" -- situations where our mail gets
forwarded or "bounced" back to us and we endlessly
respond to it.
Finally we've gotten to the stage where we can
give you the particular example that you asked
for. First we start a recipe with:
:0
... then we add the one condition you've described
* ^From.*[email protected]
- (you'll have to change the address to suit
your case).
... and we add a couple of conditions to avoid
looping and to avoid responding to automated systems
* !^FROM_DAEMON
* !^FROM_MAILER
... and one more to prevent some tricky loop:
* !^X-Loop: [email protected]
... now we add a "disposition" -- the autoresponse.
| (formail -rk \
-A "X-Loop: [email protected]" \
-A "Precendence: junk"; \
echo "Please don't send me any more mail";\
echo "This is an automated response";\
echo "I'll never see your message";\
echo "So, GO AWAY" ) | $SENDMAIL -t -oi
This is pretty complicated -- but here's how it works:
-
The pipe character tells procmail that
it should launch a program and feed the
message to it.
The open parenthesis is a Bourne shell construct
that groups a set of commands in such a way as
to combine the output from all of them into
one "stream." We'll explain this more later.
The 'formail' command is a handy program that
is included with the procmail package. It
"formats" mail header according to its
command line switches and its input.
-
-rk tells 'formail' to format a
"reply" and to "keep" the message
body.
The -A parameters tells formail
to "add" the next parameter as a
header line. The parameters
provided to the -A switch must be
enclosed in quotes so the shell
treats the whole string (spaces
and all) as single parameters.
The backslashes at the end of each
line tell procmail mail to treat
the next line as part of this one.
So, all of the lines ending in
backslashes are passed to the shell
as one long line.
This "trailing backslash" or "line
continuation" character is a common
Unix idiom found in a number of
programming languages and configuration
file formats.
The semicolons tell the shell
to execute another command -- they
allow several commands to be issued
on the same command line.
Each of the echo commands should be
reasonably self-explanatory. We
could have used a 'cat' command
and put our text into a file if we
wanted. We can also call other programs
here -- like 'fortune' or 'date' --
and their output would be combined with
the rest of this).
Now we get to the closing parenthesis.
This marks the end of the block of
commands that we combined. The output
from all of those is fed into the
next pipe -- which starts the local
copy of sendmail (note that this is
another variable that procmail
thoughtfully presets for us).
The -t switch on sendmail tells it to
take the "To:" address from the header
of its input (where 'formail -r' put
it) and the -oi switch enables the
sendmail "option" to "ignore" lines
that consist only of a 'dot' (don't
worry about the details on that).
This is basically the recipe you want.
Obviously it has to be modified a bit. That's
why I've gone to such elaborate lengths to explain
how it all works.
Most of the difficulty in understanding procmail
has nothing to do with procmail itself. The intricacies
of regular expressions (those weird things on the
'*' -- conditional lines) and shell quoting and
command syntax, and how to format a reply header that
will be acceptable to sendmail (the 'formail' and
'sendmail' stuff) are the parts that require so
much explanation.