https://htyp.org/mw/index.php?title=Procmail/doc/FAQ&feed=atom&action=historyProcmail/doc/FAQ - Revision history2024-03-28T10:56:38ZRevision history for this page on the wikiMediaWiki 1.35.0https://htyp.org/mw/index.php?title=Procmail/doc/FAQ&diff=18995&oldid=prevWoozle: Created page with "<pre> ------------------------------------------------------------------------------ ---------------------- Frequently Asked Questions ---------------------------- -----------..."2012-07-14T22:52:08Z<p>Created page with "<pre> ------------------------------------------------------------------------------ ---------------------- Frequently Asked Questions ---------------------------- -----------..."</p>
<p><b>New page</b></p><div><pre><br />
------------------------------------------------------------------------------<br />
---------------------- Frequently Asked Questions ----------------------------<br />
------------------------------------------------------------------------------<br />
<br />
1. How do I go about setting up a mailinglist or a mail-archive server?<br />
<br />
Look in the SmartList directory, start reading the INTRO file,<br />
it describes it in detail and should get you started.<br />
<br />
2. I installed procmail (i.e. typed 'make install'), but how am I supposed to<br />
use it? When I type procmail on the command line it simply does nothing.<br />
<br />
***********************************************************************<br />
There exists an excellent newbie FAQ about mailfilters (and procmail<br />
in particular), it is being maintained by Nancy McGough <nancym@ii.com><br />
and can be obtained via:<br />
<br />
World Wide Web (the nicest format for online reading!):<br />
http://www.faqs.org/faqs/mail/filtering-faq/<br />
<br />
Anonymous FTP:<br />
ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/filtering-faq<br />
<br />
E-mail:<br />
Send mail to mail-server@rtfm.mit.edu containing the following:<br />
send usenet/news.answers/mail/filtering-faq<br />
<br />
UUCP:<br />
uunet!/archive/usenet/news.answers/mail/filtering-faq<br />
<br />
It is also posted monthly in at least the following newsgroups:<br />
comp.mail.misc, comp.answers, news.answers<br />
***********************************************************************<br />
<br />
You're not supposed to start procmail from the command line.<br />
Procmail expects exactly one mail message to be presented to it<br />
on its stdin. Usually the mail system feeds it into procmail.<br />
If you start it by hand, you have to type the mail.<br />
<br />
Be sure to have a .forward and a .procmailrc file in your home<br />
directory (see the examples subdirectory or the man page).<br />
MMDF users should note that they need a .maildelivery file *instead*<br />
of a .forward file (see the man page for more detailed information).<br />
<br />
If however, procmail has been integrated in the maildelivery system<br />
(i.e. if your system administrator installed it that way, ask him/her),<br />
then you no longer need the .forward files in your home directory,<br />
having a .procmailrc file will suffice.<br />
<br />
On some systems .forward files are not checked.<br />
It might be possible that your system supports a command like:<br />
mail -F "|/usr/bin/procmail"<br />
to set up forwarding to a program. (If procmail is in /usr/local/bin<br />
then use that path instead when trying these.)<br />
If that doesn't seem to work it might be worth trying to put a line<br />
looking like this:<br />
Forward to |/usr/bin/procmail<br />
or if that doesn't work, try:<br />
Pipe to /usr/bin/procmail<br />
as the only line in your mail spool file (e.g. /var/mail/$LOGNAME), as<br />
well as doing a "chmod 06660 /var/mail/$LOGNAME". For more information<br />
on such systems, do a "man mail".<br />
<br />
If all of this doesn't work, procmail can be called on a periodical<br />
basis, either via "cron", "at" or whenever you start reading mail (or<br />
log in). For a sample script look in the NOTES section of the<br />
procmail(1) man page.<br />
<br />
3. When I compile everything the compiler complains about invalid or illegal<br />
pointer combinations, but it produces the executables anyway.<br />
Should I be concerned?<br />
<br />
Ignore these warnings, they simply indicate that either your compiler<br />
or your system include files are not ANSI/POSIX compliant.<br />
The compiler will produce correct code regardless of these warnings.<br />
<br />
4. The compiler seems to issue warnings about "loop not entered at top",<br />
is that a problem?<br />
<br />
No, no problem at all, it just means I wrote the code :-).<br />
That's just about the only uncommon coding technique I use (don't<br />
think I don't try to avoid those jumps in loops, it's just that<br />
sometimes they are the best way to code it). This warning, as<br />
well as "statement not reached", can be ignored -- the compiler<br />
will still generate correct code. Use gcc if they really bother<br />
you.<br />
<br />
5. The compiler complains about unmodifiable lvalues or assignments to const<br />
variables. Now what?<br />
<br />
Well, if the compiler produces the executables anyway everything<br />
probably is all right. If it doesn't, you might try inserting a<br />
"#define const" in the autoconf.h file by hand. However in any case,<br />
your compiler is broken; I would recommend submitting this as a<br />
compiler bug to your vendor. In any case, if this should occur, I'd<br />
appreciate a mail from you (so I can try to fix the autoconf script<br />
to recognise your compiler correctly as well).<br />
<br />
6. The compiler refuses to compile regexp.c, what is the problem?<br />
<br />
Try compiling that module with optimisation turned off.<br />
<br />
7. Everything installed just fine, it's just that there are several stale<br />
_locktst processes which refuse to die. How do I get rid of those?<br />
<br />
In order to prevent things like this from happening to procmail,<br />
_locktst tries to determine which kernel locking methods are<br />
reliable. Sometimes this triggers a bug in the kernel or in<br />
your system-supplied lockd; this is good, because _locktst detects<br />
this and makes sure that procmail will not make the same mistake.<br />
A side effect is that this sometimes leaves behind some stale<br />
_locktst processes that seem to be unkillable.<br />
<br />
This usually is the result of a buggy lockdaemon. In order to<br />
get rid of the stale processes, ask your system administrator<br />
to kill and restart the (rpc.)lockd (and perhaps the (rpc.)statd)<br />
on both the filesystem-client (where you compiled procmail) and the<br />
filesystem-server(s) (where the lockingtests took place).<br />
Depending on the OS it might help if you send the offending<br />
_locktst processes a kill signal before or after restarting the<br />
lockd again.<br />
<br />
In any case, _locktst just uncovered a bug in your operating system.<br />
You should contact your system's vendor and ask for a bugfix for<br />
your lockd.<br />
<br />
8. When I send myself a testmail, the mail bounces with the message: cannot<br />
execute binary file. What am I doing wrong?<br />
<br />
It is very well possible that mail is processed on a different<br />
machine from that where you usually read your mail. Therefore you<br />
have to make sure that procmail has the right binary format to<br />
execute on those machines on which mail could arrive. In order to<br />
get this right you might need to do some .forward file tweaking,<br />
look at the examples/advanced file for some suggestions.<br />
<br />
9. Where do I look for examples about:<br />
One home directory, several machine architectures?<br />
Procmail as an integrated local mail delivery agent? (generic,<br />
sendmail, ZMailer, smail, SysV mailsurr)<br />
Changing the mail spool directory to $HOME for all users<br />
Security considerations (when installing procmail suid root)<br />
<br />
Well, this probably is your lucky day :-), all these topics are covered<br />
in the examples/advanced file.<br />
<br />
Other examples (e.g. for autoreplies) are most likely to be found by<br />
typing: man procmailex<br />
<br />
10. How do I use procmail as a general mail filter inside sendmail?<br />
<br />
See EXAMPLES section of the procmail(1) man page.<br />
<br />
11. Why do I have to insert my login name after the '#' in the .forward or<br />
.maildelivery file?<br />
<br />
Some mailers `optimise' maildelivery and take out duplicates from<br />
Cc:, Bcc: and alias lists before delivery. If two or more persons on<br />
such a list would have identical .forward files, then the mailer will<br />
eliminate all but one. Adding a `#' with your login name following<br />
it will make the .forward files unique, and will ensure that the mailer<br />
doesn't optimise away some addresses.<br />
<br />
12. How do I view the man pages?<br />
<br />
If the man(1) program on your system understands the MANPATH<br />
environment variable, make sure that the installation directory listed<br />
in the Makefile for the manpages is included in your MANPATH. If your<br />
man program does not support MANPATH, make sure that the man pages<br />
are installed in one of the standard man directories, like under<br />
/usr/man. If you do not want to install the man pages before viewing<br />
them, you can view an individual man file by typing something like:<br />
nroff -man procmail.1 | more<br />
<br />
13. The leading From_ line on all my arriving mail shows the wrong time.<br />
Before putting procmail in the .forward file everything was OK.<br />
<br />
This is a known bug in sendmail-5.65c+IDA. The real fix would be<br />
to upgrade to sendmail 6.x or later. For a quick fix, see the<br />
procmailex man page.<br />
<br />
14. When sending mail to someone with procmail in his/her .forward I sometimes<br />
get back an error saying: "Cannot mail directly to programs."<br />
<br />
This is a known bug in some older sendmails that mistakenly drop<br />
their root privileges when they are given the -t flag. Either<br />
make sure that your sendmail always forwards to a mailserver first or<br />
upgrade to sendmail 6.x or later.<br />
<br />
15. When sending mail to someone with procmail in his/her .forward I sometimes<br />
get back an error saying:<br />
"User doesn't have a valid shell for mailing to programs."<br />
<br />
This indicates that the mail arrives on a mailserver which most likely<br />
has a different user database (/etc/passwd) where the login shell<br />
specified for the recipient is not present in /etc/shells.<br />
Contact your administrator to put the name of that shell in<br />
/etc/shells.<br />
<br />
16. My mailtool sometimes reports that it is confused about the state of<br />
the mailbox, or I get "Couldn't unlock" errors from procmail now and then,<br />
or sometimes it simply seems to hang just when new mail arrives.<br />
<br />
This is a known bug in the OpenLook mailtool. It holds on to<br />
the kernel lock on the mail-spoolfile most of the time as a<br />
signal to other mailtool processes. With newer versions of<br />
mailtool, enabling the "Use network aware mail file locking"<br />
configuration option may solve the problem, though this option<br />
isn't always available. If that doesn't work then recompile<br />
procmail with both the fcntl() and lockf() locking method<br />
disabled (see config.h).<br />
<br />
17. I sometimes get these `Lock failure on "/var/mail/$LOGNAME.lock"' errors<br />
from procmail. What do I do about it?<br />
<br />
The problem here is that as long as procmail has not read a<br />
$HOME/.procmailrc file, it can hang on to the sgid mail permission<br />
(which it needs in order to create a lockfile in /var/mail).<br />
I.e. if procmail delivers mail to a user without a $HOME/.procmailrc<br />
file, procmail *can* (and does) use the /var/mail/$LOGNAME.lock file.<br />
<br />
If, however, it finds a $HOME/.procmailrc file, procmail has to let go<br />
of the sgid mail permission because otherwise any ordinary user could<br />
abuse that.<br />
<br />
There are several solutions to this problem:<br />
- Some systems support the sticky bit on directories (when set only<br />
allows the owner of a file in that directory to rename or remove<br />
it). This enables you to make /var/mail drwxrwxrwt. It is<br />
thus effectively world writable, but all the mailboxes in it are<br />
protected because only the mailbox owner can remove or rename it.<br />
- If your system did not exhibit the !@#$%^&* POSIX semantics for<br />
setgid(), procmail would have been able to switch back and forth<br />
between group mail and the group the recipient belongs to without<br />
creating security holes.<br />
- If your system supported setrgid() or setregid() or setresgid()<br />
with BSD semantics, procmail would have been able to switch...<br />
(see the previous point).<br />
- You could simply put the following at the end of your .procmailrc<br />
file:<br />
<br />
LOCKFILE # removes any preexisting lockfile<br />
LOG=`lockfile $DEFAULT$LOCKEXT`<br />
TRAP="rm -f $DEFAULT$LOCKEXT"<br />
:0<br />
$DEFAULT<br />
<br />
- You could, instead of using /var/mail/$LOGNAME, use a file below<br />
your home directory as your default mailbox.<br />
- Or, you could still use /var/mail/$LOGNAME as the mailbox, but<br />
simply instruct procmail to use a different lockfile. This can<br />
be achieved by putting following recipe at the bottom of<br />
your .procmailrc file:<br />
<br />
:0:$HOME/.lockmail<br />
$DEFAULT<br />
<br />
You have to make sure that all other programs that update your<br />
system mailbox will be using the same lockfile of course.<br />
- You can ignore the problem if you know that both your mail reader<br />
and procmail use an overlapping kernel locking method.<br />
<br />
18. Is procmail Y2K safe/compliant?<br />
<br />
Both procmail and formail are believed to be Y2K compliant if<br />
your system's libraries are Y2K compliant. In particular, they<br />
use the time_t type to hold the current time when it is needed<br />
and print out the time using the ctime() library routine.<br />
However, no actual compliancy tests have been run, so you if<br />
you need that you'll need to run them yourself.<br />
<br />
For those who have examined the code themselves, the casting of<br />
a time_t value to unsigned long in formail.c is guaranteed to<br />
work according to the current version of the C language<br />
standard. Future revisions of that standard may change that,<br />
at which time formail will be updated to work with both the new<br />
and the old standards.<br />
<br />
Individual recipes and rcfiles may need to be checked for<br />
unsafe date handling.<br />
<br />
19. How can I make procmail deliver a message to all local users? E-mail<br />
for several people all come into a single mailbox and I'm trying to<br />
split them back up.<br />
<br />
If you are asking this, you are on the wrong track. Procmail<br />
cannot route messages like this correctly without special help<br />
from the MTA (sendmail, qmail, etc). For a more lengthy<br />
discussion about the issues, please refer to<br />
http://www.iki.fi/era/procmail/mini-faq.html#advanced<br />
<br />
20. None of the above topics cover my problem. Should I panic?<br />
<br />
Let me ask you a question :-), have you examined the CAVEATS,<br />
WARNINGS, BUGS and NOTES sections of the manual pages *closely* ?<br />
Have you checked any of the FAQs referenced from the procmail<br />
website, http://www.procmail.org, to see if the answer it? If<br />
you have, well, then panic. Or, alternatively, you could<br />
submit your question to the procmail mailinglist (see the man<br />
page for the exact addresses, or try "procmail -v", or look in<br />
the patchlevel.h file).<br />
</pre></div>Woozle