Procmail Frequently Asked Questions
This is the original FAQ which comes with the Procmail distribution.
I have included it here in order to make it easy to reference it from
my own attempt at a Procmail FAQ
I have made every attempt to preserve as much as possible
of Stephen's original FAQ. The HTML encoding is by me, though.
If you want to check out the original, text-only version,
look no further.
$Id: faq.html,v 1.2 2009/01/07 12:04:02 gsutter Exp $
Table of Contents
-
How do I go about setting up a mailinglist or a mail-archive server?
-
I installed procmail (i.e. typed 'make install'), but how am I supposed to use it? When I type procmail on the command line it simply does nothing.
-
When I compile everything the compiler complains about invalid or illegal pointer combinations, but it produces the executables anyway. Should I be concerned?
-
The compiler seems to issue warnings about "loop not entered at top", is that a problem?
-
The compiler complains about unmodifiable lvalues or assignments to const variables. Now what?
-
The compiler refuses to compile
regexp.c
, what is the problem?
-
Everything installed just fine, it's just that there are several stale
_locktst
processes which refuse to die. How do I get rid of those?
-
When I send myself a testmail, the mail bounces with the message: cannot execute binary file. What am I doing wrong?
-
Where do I look for examples about:
-
One home directory, several machine architectures?
-
Procmail as an integrated local mail delivery agent? (generic,
sendmail, ZMailer, smail, SysV mailsurr)
-
Changing the mail spool directory to
$HOME
for all users
-
Security considerations (when installing procmail suid root)
-
How do I use procmail as a general mail filter inside sendmail?
-
Why do I have to insert my login name after the '#' in the
.forward
or .maildelivery
file?
-
How do I view the man pages?
-
The leading From_ line on all my arriving mail shows the wrong time. Before putting procmail in the
.forward
file everything was OK.
-
When sending mail to someone with procmail in his/her
.forward
I sometimes get back an error saying: "Cannot mail directly to programs."
-
When sending mail to someone with procmail in his/her
.forward
I sometimes get back an error saying: "User doesn't have a valid shell for mailing to programs."
-
My mailtool sometimes reports that it is confused about the state of the mailbox, or I get "Couldn't unlock" errors from procmail now and then, or sometimes it simply seems to hang just when new mail arrives.
-
I sometimes get these `Lock failure on "/usr/mail/$LOGNAME.lock"' errors from procmail. What do I do about it?
-
None of the above topics cover my problem. Should I panic?
Frequently Asked Questions
-
How do I go about setting up a mailinglist or a mail-archive server?
Look in the SmartList directory, start reading the INTRO file,
it describes it in detail and should get you started.
-
I installed procmail (i.e. typed 'make install'), but how am I supposed to
use it? When I type procmail on the command line it simply does nothing.
There exists an excellent newbie FAQ about mailfilters (and procmail
in particular), it is being maintained by Nancy McGough
and can be obtained via:
World Wide Web (the nicest format for online reading!):
http://www.cis.ohio-state.edu/hypertext/faq/usenet/mail/filtering-faq/faq.html
(If the above doesn't work, try the "FAQ Launcher" at
http://www.ii.com/internet/faqs/launchers/mail/filtering-faq/
... Thanks to Eric Hilding for pointing out this problem. // era)
Anonymous FTP:
ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/filtering-faq
Email:
Send mail to
mail-server@rtfm.mit.edu
containing the following:
send usenet/news.answers/mail/filtering-faq
UUCP:
uunet!/archive/usenet/news.answers/mail/filtering-faq
It is also posted monthly in at least the following newsgroups:
comp.mail.misc,
comp.answers,
news.answers
You're not supposed to start procmail from the command line.
Procmail expects exactly one mail message to be presented to it
on its stdin
. Usually the mail system feeds it into procmail.
If you start it by hand, you have to type the mail.
Be sure to have a .forward
and a .procmailrc
file in your home
directory (see the examples subdirectory or the man page).
MMDF users should note that they need a .maildelivery
file instead
of a .forward
file (see the man page for more detailed information).
If however, procmail has been integrated in the maildelivery system
(i.e. if your system administrator installed it that way, ask him/her),
then you no longer need the .forward
files in your home directory,
having a .procmailrc
file will suffice.
On some systems .forward
files are not checked.
It might be possible that your system supports a command like:
mail -F "|/usr/local/bin/procmail"
to set up forwarding to a program.
If that doesn't seem to work it might be worth trying to put a line
looking like this:
Forward to |/usr/local/bin/procmail
or if that doesn't work, try:
Pipe to /usr/local/bin/procmail
as the only line in your mail spool file (e.g. /usr/mail/$LOGNAME
), as
well as doing a chmod 06660 /usr/mail/$LOGNAME
. For more information
on such systems, do a "man mail".
If all of this doesn't work, procmail can be called on a periodical
basis, either via "cron", "at" or whenever you start reading mail (or
log in). For a sample script look in the NOTES section of the
procmail(1) man page.
-
When I compile everything the compiler complains about invalid or illegal
pointer combinations, but it produces the executables anyway.
Should I be concerned?
Ignore these warnings, they simply indicate that either your compiler
or your system include files are not ANSI/POSIX compliant.
The compiler will produce correct code regardless of these warnings.
-
The compiler seems to issue warnings about "loop not entered at top",
is that a problem?
No, no problem at all, it just means I wrote the code :-).
That's just about the only uncommon coding technique I use (don't
think I don't try to avoid those jumps in loops, it's just that
sometimes they are the best way to code it). Use gcc
if you want
to avoid these warnings.
-
The compiler complains about unmodifiable lvalues or assignments to const
variables. Now what?
Well, if the compiler produces the executables anyway everything
probably is all right. If it doesn't, you might try inserting a
#define const
in the autoconf.h
file by hand.
However in any case,
your compiler is broken; I would recommend submitting this as a
compiler bug to your vendor. In any case, if this should occur, I'd
appreciate a mail from you (so I can try to fix the autoconf
script
to recognise your compiler correctly as well).
-
The compiler refuses to compile
regexp.c
, what is the problem?
Try compiling that module with optimisation turned off.
-
Everything installed just fine, it's just that there are several stale
_locktst
processes which refuse to die. How do I get rid of those?
In order to prevent things like this from happening to procmail,
_locktst
tries to determine which kernel locking methods are
reliable. Sometimes this triggers a bug in the kernel or in
your system-supplied lockd
; this is good, because _locktst
detects
this and makes sure that procmail will not make the same mistake.
A side effect is that this sometimes leaves behind some stale
_locktst
processes that seem to be unkillable.
This usually is the result of a buggy lockdaemon. In order to
get rid of the stale processes, ask your system administrator
to kill and restart the (rpc.)lockd (and perhaps the (rpc.)statd)
on both the filesystem-client (where you compiled procmail) and the
filesystem-server(s) (where the lockingtests took place).
Depending on the OS it might help if you send the offending
_locktst
processes a kill signal before or after restarting the
lockd again.
In any case, _locktst
just uncovered a bug in your operating system.
You should contact your system's vendor and ask for a bugfix for
your lockd
.
-
When I send myself a testmail, the mail bounces with the message: cannot
execute binary file. What am I doing wrong?
It is very well possible that mail is processed on a different
machine from that where you usually read your mail. Therefore you
have to make sure that procmail has the right binary format to
execute on those machines on which mail could arrive. In order to
get this right you might need to do some .forward
file tweaking,
look at the examples/advanced file for some suggestions.
-
Where do I look for examples about:
-
One home directory, several machine architectures?
-
Procmail as an integrated local mail delivery agent? (generic,
sendmail, ZMailer, smail, SysV mailsurr)
-
Changing the mail spool directory to
$HOME
for all users
-
Security considerations (when installing procmail suid root)
Well, this probably is your lucky day :-), all these topics are covered
in the examples / advanced file.
Other examples (e.g. for autoreplies) are most likely to be found by
typing: man procmailex
-
How do I use procmail as a general mail filter inside sendmail?
See EXAMPLES section of the procmail(1) man page.
-
Why do I have to insert my login name after the '#' in the
.forward
or
.maildelivery
file?
Some mailers `optimise' maildelivery and take out duplicates from
Cc:, Bcc: and alias lists before delivery. If two or more persons on
such a list would have identical .forward files, then the mailer will
eliminate all but one. Adding a `#' with your login name following
it will make the .forward
files unique, and will ensure that the mailer
doesn't optimise away some addresses.
-
How do I view the man pages?
If the man(1) program on your system understands the MANPATH
environment variable, make sure that the installation directory listed
in the Makefile for the manpages is included in your MANPATH. If your
man program does not support MANPATH, make sure that the man pages
are installed in one of the standard man directories, like under
/usr/man
. If you do not want to install the man pages before viewing
them, you can view an individual man file by typing something like:
nroff -man procmail.1 | more
-
The leading From_ line on all my arriving mail shows the wrong time.
Before putting procmail in the
.forward
file everything was OK.
This is a known bug in sendmail-5.65c+IDA. The real fix would be
to upgrade to sendmail 6.x or later. For a quick fix, see the
procmailex man page.
-
When sending mail to someone with procmail in his/her
.forward
I sometimes
get back an error saying: "Cannot mail directly to programs."
This is a known bug in some older sendmails that mistakenly drop
their root privileges when they are given the -t
flag.
Either
make sure that your sendmail always forwards to a mailserver first or
upgrade to sendmail 6.x or later.
-
When sending mail to someone with procmail in his/her
.forward
I sometimes
get back an error saying:
"User doesn't have a valid shell for mailing to programs."
This indicates that the mail arrives on a mailserver which most likely
has a different user database (/etc/passwd
) where the login shell
specified for the recipient is not present in /etc/shells
.
Contact your administrator to put the name of that shell in
/etc/shells
.
-
My mailtool sometimes reports that it is confused about the state of
the mailbox, or I get "Couldn't unlock" errors from procmail now and then,
or sometimes it simply seems to hang just when new mail arrives.
This is a known bug in the OpenLook mailtool. It holds on to the
kernel lock on the mail-spoolfile most of the time, and releases
this lock when it shouldn't. Either ask for a bugfix from your
vendor (I'm not sure if a bugfix exists), or make sure that during
the compilation of procmail both the fcntl() and lockf() locking
methods are disabled (see config.h).
-
I sometimes get these `Lock failure on "/usr/mail/$LOGNAME.lock"' errors
from procmail. What do I do about it?
The problem here is that as long as procmail has not read a
$HOME/.procmailrc
file, it can hang on to the sgid mail permission
(which it needs in order to create a lockfile in /usr/mail
).
I.e. if procmail delivers mail to a user without a $HOME/.procmailrc
file, procmail can (and does) use the /usr/mail/$LOGNAME.lock
file.
If, however, it finds a $HOME/.procmailrc
file, procmail has to let go
of the sgid mail permission because otherwise any ordinary user could
abuse that.
There are several solutions to this problem:
-
None of the above topics cover my problem. Should I panic?
Let me ask you a question :-), have you examined the CAVEATS, WARNINGS,
BUGS and NOTES sections of the manual pages closely?
If you have, well, then panic. Or, alternatively, you could submit
your question to the procmail mailinglist (see the man page for the
exact addresses, or try "procmail -v", or look in the patchlevel.h
file).