1

I'm using fetchmail to download email, and using procmail for delivery as the mda. I'd like them to be delivered for use with mh, but procmail seems to deliver them in a manner that mh doesn't understand: I get subdirectories new/ cur/ and tmp/ with files in new/ named something like 1484079635.67044_0.HOSTNAME

If I rename these files to just integers and move them up one directory, mh will pick them up fine. I'd like to be able to do this automatically, as well as to maintain the sequence from the last fetchmail run.

fetchmail config:

set logfile /path/to/fetchmail.log
set no bouncemail

poll "imap.gmail.com"
protocol imap
username "USER"
password "PASSWORD"
fetchall
keep
ssl
mda "/path/to/procmail -m /path/to/.procmailrc"

procmail config:

LOGFILE=$HOME/procmail.log
VERBOSE=on
DELIVERED=yes
MAILDIR=$HOME/Mail/.
DEFAULT=inbox/
3

Your DEFAULT=inbox/ says that mail should be delivered to a Maildir mailbox (with subdirectories cur, new and tmp). This mailbox is located in $HOME/Mail/. according to the MAILDIR variable.

To deliver to an MH mailbox instead, you should set DEFAULT to inbox/. (note the dot at the end). MAILDIR can be set to $HOME/Mail.

In short:

  • The final mailbox path has / at the end: Maildir mailbox
  • ... has /. at the end: MH mailbox
  • ... has none of the above: Ordinary Unix mbox mailbox.

See the procmailrc(5) manual.

  • For completeness, "none of the above" where the destination exists but is a directory selects Procmail's own MSGPREFIX file-per-message storage scheme. – tripleee Jan 11 '17 at 7:21
1

The accepted answer is correct, but I'd like to add some comments and amplifications.

Your question seems to suggest that you believe that MH and Maildir are one and the same format. They are not; MH traditionally uses a single directory per folder, while Maildir, as you discovered, uses three subdirectories; it originally delivers into new, then moves to tmp, and then finally to cur.

Procmail natively supports delivering into both. For MH, however, simply delivering straight into the target directory bypasses some useful features of MH. You can instead pipe to the rcvstore program, which offers better overall integration with the MH system (it will update the associated control and cache files).

You can't directly set DEFAULT to accomplish this; you need to have a simple .procmailrc with something like

:0:foldername.lock
| rcvstore +foldername   # from memory it wants a plus, is that right?

That's an unconditional delivering action with locking on a named lock file.

This approach generalizes to many other folder formats. Even though Procmail does not natively support MBX, Dovecot's dbox, and various other formats, you can deliver to those if you have a delivery program for that format which you can pipe messages into.

This answer basically reiterates information from http://www.iki.fi/era/procmail/mini-faq.html#appendix-folders

  • You're right, I thought they were basically the same thing. – Angelo Jan 11 '17 at 17:02
  • MH is much older, from a time when local access was the normal. The newer Maildir is robust against various concurrency issues (to theepoint that you don't want or need to use locking in Procmail), and suitable e.g. for IMAP servers. – tripleee Jan 11 '17 at 17:39
  • Can you explain this from the procmailex man page? "Unfortunately, the lockfile doesn’t completely solve the problem as rcvstore could be invoked while ‘show’ or ‘mark’ or some other MH program is running. This problem is expected to be fixed in some future version of MH, but until then, you’ll have to balance the risk of lost or corrupt sequences against the benefits of the unseen sequence. " – Angelo Jan 11 '17 at 19:18
  • 1
    It means those commands too manipulate the cache etc, and do not obey the lock set by Procmail to prevent itself (and cooperating processes) from manipulating it from two separate jobs at the same time. Basically, Procmail says "add this to the cache file as unseen" and show says "mark this as read in the cache file" and if they do it at roughly the same time, one or the other change will be overwritten, and thus effectively lost. – tripleee Jan 12 '17 at 5:11

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.