procmail insists in writing to /var/mail in macOS Sierra

Question

I'm trying to configure fetchmail and procmail with a Google account. This is my $HOME/.fetchmailrc:

poll imap.gmail.com protocol IMAP 
   user "<email>" is jviotti here
   password '<password>'
   folder 'Inbox'
   keep
   ssl
mda 'procmail'

And this is my $HOME/.procmailrc:

MAILDIR=$HOME/Mail
DEFAULT=$MAILDIR/$LOGNAME/
LOGFILE=$MAILDIR/log/procmail
VERBOSE=on

I get the following errors from procmail when running fetchmail -a -v for every message that gets downloaded:

fetchmail: IMAP> A0005 FETCH 1 RFC822.HEADER
fetchmail: IMAP< * 1 FETCH (RFC822.HEADER {2865}
reading message <email>@gmail-imap.l.google.com:1 of 22 (2865 header octets) #
fetchmail: IMAP< )
fetchmail: IMAP< A0005 OK Success
fetchmail: IMAP> A0006 FETCH 1 BODY.PEEK[TEXT]
fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {3983}
 (3983 body octets) *******************************.************************.***********.*****
fetchmail: IMAP< )
fetchmail: IMAP< A0006 OK Success
procmail: Couldn't create "/var/mail/jviotti"
 not flushed
fetchmail: IMAP> A0007 STORE 1 +FLAGS (\Seen)
fetchmail: IMAP< A0007 OK Success

Notice procmail: Couldn't create "/var/mail/jviotti" not flushed. For some reason, procmail insists on writing to /var/mail even though MAILDIR=$HOME/Mail and DEFAULT=$MAILDIR/$LOGNAME/.

Why is this the case?

By looking at procmailrc man page, I found that ORGMAIL defaults to /var/mail/$LOGNAME, and that DEFAULT defaults to ORGMAIL:

 ORGMAIL               /var/mail/$LOGNAME
                       (Unless -m has been specified, in which case it is unset)

 DEFAULT               $ORGMAIL

However even after setting ORGMAIL to something else in $HOME/.procmailrc, I get the same error/warning.

Notice that even though I get this error, my mail is correctly downloaded to $HOME/Mail.

EDIT: See the output of procmail -v. For some reason it still sets my system mailbox to /var/mail/jviotti.

$ procmail -v
procmail v3.22 2001/09/10
    Copyright (c) 1990-2001, Stephen R. van den Berg    <srb@cuci.nl>
    Copyright (c) 1997-2001, Philip A. Guenther         <guenther@sendmail.com>

Submit questions/answers to the procmail-related mailinglist by sending to:
        <procmail-users@procmail.org>

And of course, subscription and information requests for this list to:
        <procmail-users-request@procmail.org>

Locking strategies:     dotlocking, flock()
Default rcfile:         $HOME/.procmailrc
Your system mailbox:    /var/mail/jviotti

EDIT 2: See the following from man procmail:

If no rcfiles and no -p have been specified on the command line, procmail will, prior to reading $HOME/.procmailrc, interpret commands from /etc/procmailrc (if present). Care must be taken when creating /etc/procmailrc, because, if circumstances permit, it will be exe- cuted with root privileges (contrary to the $HOME/.procmailrc file of course).

Here is says that prior to reading my home configuration, it will read from /etc/procmailrc, however that file doesn't exist on my system, and even by explicitly passing -p (pointing to my home configuration), the system mailbox is still /var/mail/jviotti.

The man page also says:

If no rcfile is found, or processing of the rcfile falls off the end, procmail will store the mail in the default system mailbox.

What does "falls off the end" means?

Here is the output in the Procmail log file from one incoming message:

procmail: [49293] Tue Dec 13 14:29:20 2016 
procmail: Assigning "LASTFOLDER=/Users/jviotti/Mail/jviotti/new/1481653760.49293_2.jviotti-rmbp.local" 
procmail: Notified comsat: "jviotti@0:/Users/jviotti/Mail/jviotti/new/1481653760.49293_2.jviotti-rmbp.local" 
From jviotti Tue Dec 13 14:29:20 2016 
 Subject: Re: [resin-io/etcher] chore: add support for snapshot builds (#968) 
  Folder: /Users/jviotti/Mail/jviotti/new/1481653760.49293_2.jviotti-r         8015

It looks like it isn't picking up your `.procmailrc` in the first place. Can you add a `LOG=` statement to the top of your `.procmailrc` to see whether it is being executed at all? (My guess is it isn't.) See also http://www.iki.fi/era/mail/procmail-debug.html — tripleee, Dec 13 '16 at 05:23
The "system mailbox" simply indicates the system default; `procmail -v` is not reading your `.procmailrc` at all. — tripleee, Dec 13 '16 at 05:24
Your `.procmailrc` is attempting to deliver to `$HOME/Mail/$LOGNAME` i.e. probably `~/Mail/jviotti`. Is that really what you want? — tripleee, Dec 13 '16 at 05:28
Do you get anything in `$HOME/Mail/log/procmail`? With `VERBOSE=on` there should be several lines of trace for each message. — tripleee, Dec 13 '16 at 05:29
@tripleee I added a dummy `LOG` and it gets executed, but that makes sense, given that my mail is being delivered to the location I specified (`$HOME/Mail/$LOGNAME`). The intention behind that directory is to deliver somewhere in my home directory. What is the best practice in that case? — jviotti, Dec 13 '16 at 14:43
There are a lot of logs at `$HOME/Mail/log/procmail`, but nothing relevant to this problem, just a list of emails subjects and the location they are being saved to (in `~/Mail/jviotti`) — jviotti, Dec 13 '16 at 14:44
See my second edit. Could it be that my rcfile is "falling off the end", as the man page describes it (although I don't understand what that means)? — jviotti, Dec 13 '16 at 14:50
It simply means it will deliver to `$DEFAULT` if you didn't have any matching recipe which made it deliver somewhere else and thereby stop processing. — tripleee, Dec 13 '16 at 15:21
Is the `LOGFILE` value the name of a directory, not a file? This is an error, though I don't think it's the cause of your problem. Anyway, set `LOGFILE` to a file (it doesn't need to exist) and you should at least then see what Procmail is doing. — tripleee, Dec 13 '16 at 15:33
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/50034/discussion-between-tripleee-and-jviotti). — tripleee, Dec 13 '16 at 15:34

score 5 · Accepted Answer · answered Dec 14 '16 at 05:09

The error message you see is basically harmless, but it's Procmail telling you that it cannot create the default inbox with your current permissions -- you need to be root to create an empty mailbox.

Creating it manually with the right permissions should resolve this issue.

sudo install -o $USER -g mail -m 0600 /dev/null /var/mail/$USER

procmail -v simply reports what the compiled-in defaults are; it does not examine your .procmailrc at all (and if it did, any nontrivial recipe file would contain a large number of mailboxes with different conditions for when to write to which).

"Fall off the end" means if you have a .procmailrc which does not tell Procmail to deliver to a specific mailbox and stop processing (such as yours), the final action will be similar to if the last lines in your .procmailrc were

:0:
$DEFAULT

which also illustrates what an unconditional Procmail delivering recipe looks like.

The log file snippet from Procmail you posted shows that Procmail is actually executing your .procmailrc just fine. The error message apparently happens while it's starting up, before it starts executing your .procmailrc (though I cannot repro this exactly, so this is mildly speculative).

procmail insists in writing to /var/mail in macOS Sierra

1 Answers1