I am dealing with procmail the first time, so I apologize if the following question is stupid. Before I put procmail in production, I am doing a few basic tests. One of them yielded a totally unexpected result which makes it nearly worthless in my scenario:

When procmail cannot read its configuration file, it nevertheless sets its exit code to 0 (true) when it finishes. This is catastrophic, because in my scenario, I am using procmail as an MDA which is executed from within fetchmail. If procmail can't read its configuration file, it can't process (deliver) messages as needed, but sets exit code 0 when it finishes; fetchmail interprets this as successful delivery and deletes the respective messages upstream. In summary, this leads to those messages being lost.

The permissions in this scenario are quite complex (fetchmail + procmail + cyrdeliver over lmtp, fetchmail running under its own user account, procmail being suid and setgid, and so on), so it could very well happen that somebody makes a mistake with the permissions when something needs to be changed. Due to the problem described above, such mistakes likely lead to loss of messages.

Therefore, I'd like to know how to make procmail to exit with failure (exit code other than 0) if it can't read its configuration file.

To give an idea what this is about, please consider the following terminal session (irrelevant lines removed). Please note that the ownership / permissions in the config directory are wrong by intention, because this is my test case.

root@morn /etc/fetchmail # whoami

root@morn /etc/fetchmail # dir
total 52K
drwx------   2 fetchmail root 4.0K 2022-01-23 10:09 .
drwxr-xr-x 123 root      root  12K 2022-01-22 17:17 ..
-rw-------   1 fetchmail root 2.4K 2022-01-23 10:09 fetchmailrc
-rw-------   1 root      mail  282 2022-01-23 02:49 procmailrc
-rw-r--r--   1 root      root  110 2022-01-23 00:36 testmessage

root@morn /etc/fetchmail # dir `which procmail`
-rwsr-sr-x 1 root mail 92K 2017-11-16 23:42 /usr/bin/procmail
root@morn /etc/fetchmail # cat /etc/systemd/system/pp-fetchmail.service    
ExecStart=/usr/bin/fetchmail -f /etc/fetchmail/fetchmailrc --pidfile /run/fetchmail/fetchmail.pid --syslog

root@morn /etc/fetchmail # cat fetchmailrc
proto pop3
bad-header accept
user "[email protected]"
pass "supersecret"
is "user1" here
no rewrite
mda "/usr/bin/procmail TARGET=user1 /etc/fetchmail/procmailrc"

root@morn /etc/fetchmail # cat testmessage
From: [email protected]
To: [email protected]
Subject: Test message

This is a test message.

root@morn /etc/fetchmail # sudo -u fetchmail -g mail /usr/bin/procmail /etc/fetchmail/procmailrc < testmessage && echo "procmail exited 0" 
procmail: Couldn't read "/etc/fetchmail/procmailrc"
procmail exited 0

Of course, the last two lines are the problem. Does anybody know how to circumvent it? Of course, fixing the permissions would make it work correctly, but that is what I'm explicitly not asking for. I'd like to have a solution which is more robust in case of mistakes (mine or others').


2 Answers 2


If Procmail returns success, it successfully delivered the messages somewhere, though apparently not where you wanted it to. A failure would occur when it runs out of fallbacks and can't deliver anywhere. To figure out where the messages go, examine the log file (which gets emitted to standard error if you have not explicitly configured a log file). However, in the absence of any explicit log configuration, you will mainly only see the actual delivery logs, like

From [email protected]  Wed Apr 1, 2022 09:10:11 UTC
 Subject: Your inheritance from Nigeria
  Folder: /var/mail/fetchmail                       12524

Procmail out of the box will simply deliver to DEFAULT in the absence of any other instructions. The -m option requires a configuration file and will fail with an error (exit code 73) if it cannot be read, but will turn off some of the regular delivery functionality, which may not eventually be what you want.

Your configuration seems rather brittle on the whole. TARGET=user on its own does not mean anything to Procmail, so you really have to have a procmailrc file which does something with that information. The regular delivery mechanism would use -d user to explicitly deliver to the user in question, and handle fallbacks etc robustly. (I'm not familiar enough with Fetchmail to have an informed opinion about what would be correct to use here, though.)

  • Regarding the logs: Before posting the question, I did the following (as root): cd /var/log; grep -r procmail * This didn't yield anything interesting: Some entries from the procmail setup process in dpkg.log (I'm on debian), some entries created by fetchmail ("about to deliver with ... procmail ...), and that was it - not a single trace of procmail's actual activity. Likewise, there was nothing helpful on the screen during my tests.
    – Binarus
    Commented Jan 24, 2022 at 7:18
  • Thank for the great answer, +1! I guess I'll give the answer to you since it answers my question better than the first one which I've already accepted (if it turns out that I can use the -m switch for my purpose).
    – Binarus
    Commented Jan 24, 2022 at 7:19
  • Regarding the variable usage: I knew that I better should have removed that assignment :-). Yes, I know that TARGET doesn't mean anything to procmail. The sense of it: I have multiple accounts on the Cyrus IMAP server (i.e. multiple fetchmail snippets like the one I've shown, each of them with a different TARGET variable) and would like to use the same procmail configuration / recipes for all of them. In procmailrc, I then have action lines like the following: | cyrdeliver ... ${TARGET}. This works as expected.
    – Binarus
    Commented Jan 24, 2022 at 7:22

In this case, I'd write a wrapper shell script that wraps around the "/usr/bin/procmail TARGET=user1 /etc/fetchmail/procmailrc" call but performs the config file permissions check beforehand. If the config file can't be read, return 1, if it can be read, execute the "/usr/bin/procmail TARGET=user1 /etc/fetchmail/procmailrc" call and return.

Then, in the fetchmailrc file, do this:

mda "/path/to/your/wrapper/script"
  • 1
    Thank you very much, accepted and +1. I had that idea also, but was hoping that procmail itself could made behave reasonably, perhaps by setting an environment variable, a command line argument or something else which I have missed. Furthermore, I guess that the problem will resurrect if procmail can read its config file, but the config file is syntactically wrong. I can't imagine how to catch this case - but this would be a separate question, and I haven't confirmed it yet.
    – Binarus
    Commented Jan 23, 2022 at 12:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .