5

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
11
  • 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 iki.fi/era/mail/procmail-debug.html – tripleee Dec 13 '16 at 5:23
  • FWIW the not flushed is apparently from Fetchmail. – tripleee Dec 13 '16 at 5:23
  • The "system mailbox" simply indicates the system default; procmail -v is not reading your .procmailrc at all. – tripleee Dec 13 '16 at 5: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 5:28
  • 1
    Let us continue this discussion in chat. – tripleee Dec 13 '16 at 15:34
4

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).

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.