I'm using: Mutt-kz + Isync + msmtp + spamassassin + Procmail

Mutt-kz, Isync and msmtp are working. I cannot make procmail start automatically when mail arrives. I'm doing everything as non-root user and running Arch Linux. Procmail is installed.

Folders structure:


Mail arrives with this cronjob script:

mbsync googlemail && notmuch new

Here's my .forward with 644 perms.

"|IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #damian"

Here's my .procmailrc with 644 perms.


:0fw: spamassassin.lock
* < 512000
| /usr/bin/vendor_perl/spamc 

| /usr/bin/vendor_perl/spamc 

* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

* ^X-Spam-Status: Yes

If I run procmail -v I get (only the important stuff):

procmail v3.22 2001/09/10
Locking strategies:     dotlocking, fcntl(), lockf(), flock()
Default rcfile:         $HOME/.procmailrc
Your system mailbox:    /var/spool/mail/damian

I I run:

procmail DEFAULT=/dev/null VERBOSE=yes /dev/null </dev/null

I get:

procmail: [1970] Tue Apr 21 22:16:37 2015
procmail: Rcfile: "/dev/null"
procmail: Assigning "MAILDIR=/home/damian"
procmail: Assigning "LASTFOLDER=/dev/null"
procmail: Opening "/dev/null"
Folder: /dev/null             

There does not seem to be any easy way to integrate Procmail into isync / mbsync. I would go for server-side filtering, or possibly abandoning the (as such neat) idea of syncing IMAP with local folders.

With that, my original answer probably doesn't matter much, but I have preserved it below.

Your .forward file contains a syntax error. The damian should be a comment # damian but in this day and age, unless you are running a legacy Sendmail from last century, you can just leave it out.

Using zsh as your shell for Procmail processing looks weird; try changing that to /bin/sh. Even if you like zsh, you should probably prefer to avoid its features in Procmail. Using nonstandard shells has caused hard-to-explain trouble in the past (although the bugs I have seen were with tcsh).

You have two spamc recipes. One should suffice. The second one should go (spamc itself will refuse messages which are too large, anyway), but I would also remove locking from the first one.

Your DEFAULT should probably be $HOME/Mail/Inbox, right? You don't want mail in $HOME/Mail directly, do you?

Other than that, your .procmailrc is unremarkable.

For more help, maybe see http://iki.fi/era/mail/procmail-debug.html

  • It's not obvious to me that the .forward error or using zsh would break things completely for you, but I see nothing else here. Adding some diagnostics from your procmail.log would certainly be a useful addition to your question if this doesn't help. – tripleee Apr 21 '15 at 4:17
  • I have removed many of the recipes from procmail for the post, it's not the purpose of this question, I just want it running. procmail.log is empty, since it' s not starting. – damianjb Apr 21 '15 at 11:43
  • So did you try the things at iki.fi/era/mail/procmail-debug.html#startup? What's the result? – tripleee Apr 21 '15 at 12:32
  • I've changed damian with #damian in the .forward file and edited the question in the end with the results you asked for. Still not working. – damianjb Apr 21 '15 at 22:28
  • 1
    I don't see anything in there which would deliver any message locally, and thus nothing which would trigger Procmail. I don't think this setup has any sane chance to integrate your .forward file and still remain true to its goals. See also mail-archive.com/isync-devel@lists.sourceforge.net/… – tripleee Apr 22 '15 at 12:48

Since procmail isn't used as your MDA, it won't be called.

I suggest you to work on the basis of a shell script which will be fired regularly through cron and will use formail to explicitly feed procmail.

Here is a skeleton for such a shell script:

$ cat <<eof >splitter.sh


[ -s ${orig_mailbox} ] && formail -s <${orig_mailbox} procmail ${HOME}/.procmailrc

Of course this can only work as long as your .procmailrc will remove any mail from your incoming mailbox. To be sure of this I suggest to end your .procmailrc by a catch all rule:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.