Well here's what I have...
Aug 3 05:12:31 r2d2 procmail[2064]: Attempt to fake stamp by "timh"
Aug 3 05:12:31 r2d2 procmail[2064]: Suspicious rcfile
"/home/timh/.procmailrc"
Aug 3 05:12:52 r2d2 procmail[2089]: Suspicious rcfile
"/home/timh/.procmailrc"
Basically that's scattered through out /var/log/mail/errors. And it
appears that it didn't start doing that until I updated procmail.
Running the other task you mentioned, I get this output.
[timh(_at_)r2d2 timh]$ procmail </dev/null
procmail: Suspicious rcfile "/home/timh/.procmailrc"
procmail: Couldn't read "/home/timh/.procmailrc"
However it doesn't seem to complain as the root user.
[root(_at_)r2d2 mail]# procmail </dev/null
But for another user on the box I do get a complaint.
[erice(_at_)r2d2 erice]$
procmail </dev/null
procmail: Suspicious rcfile "/home/erice/.procmailrc"
procmail: Couldn't read "/home/erice/.procmailrc"
But now that I look, the root user doesn't have a .procmailrc, so that
may be why it's not causing problems. I moved the rc file and then ran
the command again, and nothing returned.
Looking at main.cf for Postfix, the only lines in there about procmail
are as follows.
[timh(_at_)r2d2 postfix]$ grep procmail *
main.cf:#mailbox_command = /some/where/procmail
main.cf:#mailbox_command = /some/where/procmail -a "$EXTENSION"
main.cf:mailbox_command = /usr/bin/procmail -o -a $DOMAIN -d $LOGNAME
The only one that's not commented out appears to be correct.
To answer another question, I used the .forward idea only AFTER I
couldn't get procmail to work. It worked in once place I thought trying
it here would help me out. But it didn't.
Currently I have no .forward, and I've toyed with the idea of going to
Qmail on my FreeBSD box, I've not actually done it on our network.
tdh
--
T. Holmes
-----------------
UNIXTECHS.org
tim(_at_)unixtechs(_dot_)org
-----------------
"Real Men Use Vi!"
Uptime:
--------------------------------------------------------------------
5:13am up 1 day, 16:07, 5 users, load average: 0.00, 0.00, 0.00
--------------------------------------------------------------------
| Tim Holmes <tim(_at_)unixtechs(_dot_)org> writes:
| >Well I know the PATH=`which procmail` works. It's being used on another
| >machine that uses procmail and there aren't any problems. Basically it
| >runs which procmail when it asks for where procmail is located. (I was
| >doing a lot of shell scripting at the time, that's why I used that.)
| >
| >[timh(_at_)yoda timh]$ echo "`which procmail`"
| >/usr/local/bin/procmail
| >
| >So when it looks for procmail it will get that. I know that's not the
| >problem, like I said I have it running like that at 6 different
| >locations and it works fine. As well as it was set like that when I set
| >up that .procmailrc, when it was working.
|
| Let's back up a second and see how the shell interpretes the PATH
| variable. Quoting the sh(1) manpage:
|
| PATH A colon separated list of directories that are searched when
| looking for commands and .'d files. An empty string resulting
| from a leading or trailing colon, or two adjacent colons, is
| treated as a ``.'', the current directory.
|
| Okay, that seems to match with procmail's default setting:
|
| $ procmail DEFAULT=/dev/null LOG='$PATH' /dev/null </dev/null; echo
| /home/users/guenther/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
| $
|
|
| Now compare that to the value returned by "which procmail". "which"
| returns the path to a single file, not a directory. As a result, after
| that assignment only can invoke commands using their full path. Yeah,
| you can use "$PATH" to invoke procmail now, but you would get the *exact*
| same result by removing the assignment and just invoking "procmail".
| Same procmail binary and it won't confuse the bejeesus out of everyone
| to whom you describe your .procmailrc.
|
| Besides, the "which" command on many systems is a hairy C-shell script
| that looks for aliases and other bogus things. It can output more text
| than just the path to the specified command, in which case you wouldn't
| even be able to use $PATH to invoke procmail! It's a lose-lose situation.
|
|
| In your first message you wrote:
| >The machine is a Mandrake 8.0 machine. It appears that Postfix is
| >configured to automatically send mail through procmail. I have procmail
| >running and working fine on a RedHat 7.1 machine and a FreeBSD machine.
| >(I had to create a .forward for FreeBSD, but it works fine.) Can
| >anybody advise or provide any idea of where to look? Thank you!
|
| Does anything related to procmail appear in the maillog? Does procmail
| output any errors when you type "procmail </dev/null"? Do postfix's
| logfiles say anything useful?
|
| If procmail operates correctly when invoked from the command line,
| then either:
| a) the MTA or its configuration is broken, or
| b) the user-specific configuration that tells the MTA to invoke procmail
| (e.g., .forward file or .qmail file) is incorrect in some way.
|
|
| Philip Guenther
| _______________________________________________
| procmail mailing list
| procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
| http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
------------------------------------------------------------------
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail