relativitaet relativitaet - 2 months ago 10
Linux Question

Procmail seems not being executed when fetching emails with fetchmail

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.

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 how fetchmail runs procmail, there could be circumstances which are not clear from your question -- for example, if fetchmail is neither running as root 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 assigns LOGFILE=/tmp/procmail-testing.log and quits, with read permission for everyone. If you can get that to work, maybe LOG=`whoami` so you can see what permissions it's running with.