1

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.

  • Stack Overflow is for programming questions. For troubleshooting a system service, I suggest migrating to [sf] or perhaps [unix.se] -- you can flag for moderator attention and request migration yourself (us regulars can really only vote to close, or to suggest moving to the [sf] migration queue). – tripleee Sep 27 '16 at 20:01

1 Answers1

1

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.

tripleee
  • 1,324
  • 3
  • 14
  • 24
  • Yes, that's true, I realized in the moment I sent the comment... I added the `-m $HOME/.procmailrc` flag to the `mda` call in the `.fetchmailrc` and now procmail seems to work. (the emails are bounced somewhere I don't know, but this is a mailbox and procmail syntax problem, I think...) Thank you for your help! –  Sep 28 '16 at 09:21
  • I commented the `LOCKFILE` line. Procmail's standard error output are the expected lines from http://porkmail.org/era/mail/procmail-debug.html . a `fetchmail -vvv` now has another line: `procmail: Couldn't read "/home/user/.procmailrc"` and indeed a `procmail -v` has in its output this line: `Your system mailbox: /var/mail/user`. I did check the permissions of the `.procmailrc` again, but they are the same as in the man. –  Sep 28 '16 at 08:51
  • I don't know why now it is working, while before it wasn't, also because it is the first time that I see the `-m` called in the `.fetchmailrc`, but as long as it is working I leave it like that... –  Sep 28 '16 at 09:48
  • If this answer helped, please consider accepting, so that this question no longer comes up as unresolved. See http://stackoverflow.com/help/someone-answers -- thanks! – tripleee Sep 28 '16 at 09:23
  • So your `.procmailrc` is in the wrong location or has the wrong permissions. The system mailbox simply tells you the system default, i.e. before any `.procmailrc` (which clearly could not be read anyway). – tripleee Sep 28 '16 at 08:59
  • Not entirely convinced `-m` makes more sense than `-d` here but it also depends on `fetchmail`, which I'm not terribly familiar with. – tripleee Sep 28 '16 at 09:24