I have the following problem:
I got a new working PC (Debian testing, codenme: stretch) recently and had to reinstall fetchmail
and procmail
in order to read my emails with mutt
.
Now, fetchmail
works well as also mutt
is doing, only the spool mailbox of my mails seems to stay the same default one, which is /var/mail/user
.
In my .fetchmailrc
I defined the mda
that should be executed with:
mda '/usr/bin/procmail -f %F -d %T';
and the .procmailrc
that I created looks like this:
# Please check if all the paths in PATH are reachable, remove the ones that
# are not.
SHELL=/bin/sh
PATH=$HOME/bin:/usr/bin:/usr/ucb:/bin:/usr/local/bin:.
MAILDIR=$HOME/Mail # Youd better make sure it exists
SPOOL=$HOME/Mail/mbox
DEFAULT=$MAILDIR/mbox
ORGMAIL=$MAILDIR/mbox
LOGFILE=$MAILDIR/log
LOCKFILE=$HOME/.lockmail
VERBOSE= yes
LOGABSTRACT= all
After looking everywhere I could, changeing and checking the permissions of the rc
files and of the mail folder again and again, finally trying to uninstall all and reinstalling it, nothing changed: the mails are all still delivered to /var/mail/user
even when I insert some delivery conditions into the .procmailrc
.
Finally I noticed that there is no /etc/procmailrc
file (as, I think, it is supposed to be) and also all the log
files that are supposed to exist and to be written are not existent.
fetchmail
is calling procmail, because a $ fetchmail -vvv
with an incoming email has, within it's longer output, this string:
fetchmail: about to deliver with: /usr/bin/procmail -f 'email@addres' -d 'user'
My conclusion is that procmail
isn't working properly or at all.
The emails still arrive, but all in that default mailbox/folder and I'm not able to move them while they are delivered (when I'm in mutt
I'm able to save them to all the mailboxes I have or might define).
I would really appreciate if someone could help me solving this issue!
Kind regards.
Best Answer
The
LOCKFILE
assignment prevents Procmail from doing anything at all.Examining Procmail's output on standard error with
procmail -m VERBOSE=yes .procmailrc </dev/null
should readily reveal that it is forever waiting on the lock, and eventually giving up.See also http://www.iki.fi/era/procmail/mini-faq.html#locking and http://www.iki.fi/era/mail/procmail-debug.html
Generally, you should not need to touch
ORGMAIL
for any reason, either.Procmail doesn't require an
/etc/procmailrc
file; if it does exist, it will be invoked before your.procmailrc
, but it should not be necessary or particularly useful in your scenario.Normally your
.procmailrc
should exist in your home directory, with read (and, for practical maintenance reasons, write) access only for yourself. Depending on howfetchmail
runsprocmail
, there could be circumstances which are not clear from your question -- for example, iffetchmail
is neither running asroot
nor as yourself, it might not have permission to switch to your UID.For troubleshooting, maybe move your regular
.procmailrc
to the side and try a really simple, general one which perhaps simply assignsLOGFILE=/tmp/procmail-testing.log
and quits, with read permission for everyone. If you can get that to work, maybeLOG=`whoami`
so you can see what permissions it's running with.