Hi Folks,
I am having a bit of hassle configuring procmail.
I have created a test user called tux and have confirmed I can send mail to him.
I have then created a /home/tux/.procmailrc file containing:
[tux@alice tux]$ cat .procmailrc VERBOSE=on MAILDIR=$HOME/mail PMDIR=$HOME/.procmail LOGFILE=$PMDIR/log INCLUDERC=$PMDIR/rc.testing
I have also created a /home/tux/.procmail directory and created a rc.testing file in it containing:
[tux@alice tux]$ cat ~/.procmail/rc.testing :0: * ^Subject:.*HOT SPAM.HOT
I then created a /home/tux/.forward file (which I copied from a book and don't understand) containing:
[tux@alice tux]$ cat ~/.forward "|IFS=' ' && exec /usr/bin/procmail -f || exec 75 tux"
If however I try to send tux an email I get an error email back containing the following:
----- The following addresses had permanent fatal errors ----- "|IFS=' ' && exec /usr/bin/procmail -f || exec 75 tux" (expanded from: tux)
----- Transcript of session follows ----- sh: cannot use & in command 554 "|IFS=' ' && exec /usr/bin/procmail -f || exec 75 tux"... Service unavailable
Do any ALUGers have any experience of configuring procmail and can help me suss out a correct ~/.forward file to invoke it?
Ta muchly!
Ian.
On 2004-07-13 07:40:18 +0100 Ian Douglas alug@k1ngph1cher.com wrote:
[tux@alice tux]$ cat ~/.forward "|IFS=' ' && exec /usr/bin/procmail -f || exec 75 tux"
I'm pretty sure this should be something more like:
|/usr/bin/procmail -f tux
Look at "man procmail" on your system to see if it has the preferred invocation. If you really need the above form, I think
|IFS=' ' exec /usr/bin/procmail -f || exec 75 tux
is more usual... not sure why those &&s were there. Usually && behaves like a ; dividing two commands, but the second command is only run if the first one succeeds (unlike ; where the second command is always run as soon as the first exits). In the line above, starting at the left, | says this is a pipe (so email gets sent to its input), IFS=' ' just sets a shell variable (without running a command), then the shell thinks && is the command, so it complains with the error you gave. Maybe it used to be accepted by some shell, but I'm not sure I've ever seen it before.
By the way, many modern MTAs can run procmail without a .forward file, by checking whether .procmailrc exists. Exim is definitely one and I'd expect Postfix to be able to do that too. Exim's default debian config does this, I believe. Maybe a Postfix user can tell us how that works?
In general, I suggest avoiding procmail unless you have a Compelling Reason. Its configuration is user-hostile line noise and alternatives like maildrop and Exim filter files are easier to write.
On Tue, 2004-07-13 at 09:34, MJ Ray wrote:
On 2004-07-13 07:40:18 +0100 Ian Douglas alug@k1ngph1cher.com wrote:
[tux@alice tux]$ cat ~/.forward "|IFS=' ' && exec /usr/bin/procmail -f || exec 75 tux"
...
not sure why those &&s were there.
In sh those &&'s are okay, they work like commands that can fail. Compare:
mak@yoda$ SHELLOPTS=foo && date bash: SHELLOPTS: readonly variable
mak@yoda$ SHELLOPTS=foo date bash: SHELLOPTS: readonly variable Tue Jul 13 10:54:44 BST 2004
The procmail man page and at least two of the FAQs from the procmail.org use them.
Your "exec 75 tux" should be "exit 75 #tux". That returns the 75 EX_TEMPFAIL exit code to the mta if the procmail invocation fails (say because of syntax error in your .procmailrc), so that your mail doesn't bounce but gets retried later. The "#username" bit is a hideous ancient hack to workaround a sendmail bug.
The "-f" needs an argument, use "-f -". Probably you don't need it at all.
The IFS variable is reset to space because of a very old security bug that I don't remember.
For some example lines:
man procmail (the NOTES section at the bottom) http://rhols66.adsl.netsonic.fi/era/procmail/mini-faq.html#forward http://www.faqs.org/faqs/mail/filtering-faq/section-18.html
Now then, judging by the error message you got, either your mta uses a restricted shell that explicitly disallows the && constructs, or perhaps it parses the whole double-quoted string as a the first argument, where it expects the command.
I'd say try one of these:
|IFS=' ' exec /usr/bin/procmail -f- || exit 75 #tux |/usr/local/bin/procmail
By the way, many modern MTAs can run procmail without a .forward file, by checking whether .procmailrc exists. Exim is definitely one and I'd expect Postfix to be able to do that too. Exim's default debian config does this, I believe. Maybe a Postfix user can tell us how that works?
An MTA doesn't check for ".procmailrc" itself; but you can configure an mta to use procmail as the "local delivery agent". In postfix you can do that with the "mailbox_command" in /etc/postfix/main.cf. In exim you setup a procmail director+transport. If you're going to use procmail for a lot of users on your system, that's probably worth it.
In general, I suggest avoiding procmail unless you have a Compelling Reason. Its configuration is user-hostile line noise and alternatives like maildrop and Exim filter files are easier to write.
After using a custom Perl script based on Mail::Audit for years, I switched to maildrop recently, and that works fairly well for my needs. http://www.flounder.net/~mrsam/maildrop/README.html
My current recipe for a pleasant email life (with admittedly considerable setup time): postfix + spamassassin spamd + amavis + maildrop + courier imap. Stir, simmer, season to taste.
-- Martijn
On 2004-07-13 12:03:12 +0100 Martijn Koster mak-alug@greenhills.co.uk wrote:
By the way, many modern MTAs can run procmail without a .forward file, by checking whether .procmailrc exists. Exim is definitely one [...]
An MTA doesn't check for ".procmailrc" itself; [...]
I wrote Exim definitely does this, so I disagree with your absolute statement. What do you think this part from the debian default exim config does, then:
# This director runs procmail for users who have a .procmailrc file
procmail: driver = localuser transport = procmail_pipe require_files = ${local_part}:+${home}:+${home}/.procmailrc:+/usr/bin/procmail no_verify
On Tue, 2004-07-13 at 13:06, MJ Ray wrote:
On 2004-07-13 12:03:12 +0100 Martijn Koster mak-alug@greenhills.co.uk wrote:
By the way, many modern MTAs can run procmail without a .forward file, by checking whether .procmailrc exists. Exim is definitely one [...]
An MTA doesn't check for ".procmailrc" itself; [...]
I wrote Exim definitely does this, so I disagree with your absolute statement. What do you think this part from the debian default exim config does, then:
# This director runs procmail for users who have a .procmailrc file
procmail: driver = localuser transport = procmail_pipe require_files = ${local_part}:+${home}:+${home}/.procmailrc:+/usr/bin/procmail no_verify
Note the comment: "runs procmail" :-) The mta itself doesn't read .procmailrc; it runs a separate local delivery agent /usr/bin/procmail, and *that* reads the .procmailrc. I'm not aware of any mta's linking with procmail as a library, so until you present a counter example I stand by my assertion :-)
I do not know know if the original poster has a exim configuration that configures procmail as default local delivery agent too. If not, he might be surprised to see that his .procmailrc gets ignored. That's why I explicitly mentioned it needs to be configured in both postfix and exim.
-- Martijn
On Tuesday 13 July 2004 09:34, MJ Ray wrote:
By the way, many modern MTAs can run procmail without a .forward file, by checking whether .procmailrc exists.
Thanks for that tip MJR. I deleted my feeble attempt at a .forward file and am happy to confirm that both the Red Hat and Slackware IMAP servers I am currently playing with procmail on do in fact, as you suggest, work ok without a .forward file and act correctly using the contents of the .procmailrc files I have created.... now for some fun trying to install spamassassin!
Thanks, Ian.
-
Ian Douglas -
Martijn Koster -
MJ Ray