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/
Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
1
  • For completeness, "none of the above" where the destination exists but is a directory selects Procmail's own MSGPREFIX file-per-message storage scheme. Commented Jan 11, 2017 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

Improve this answer
4
  • You're right, I thought they were basically the same thing. Commented Jan 11, 2017 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. Commented Jan 11, 2017 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. " Commented Jan 11, 2017 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. Commented Jan 12, 2017 at 5:11

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.