I have the following problem:
I got a new working PC (Debian testing, codenme: stretch) recently and had to reinstall
mda '/usr/bin/procmail -f %F -d %T';
# Please check if all the paths in PATH are reachable, remove the ones that
# are not.
MAILDIR=$HOME/Mail # Youd better make sure it exists
$ fetchmail -vvv
fetchmail: about to deliver with: /usr/bin/procmail -f 'email@addres' -d 'user'
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.
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.
.procmailrc should exist in your home directory, with read (and, for practical maintenance reasons, write) access only for yourself. Depending on how
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.