Linux – Procmail seems not being executed when fetching emails with fetchmail

emaillinuxmuttprocmail

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 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.

Related Topic