On Wed, Dec 10, 2003 at 11:25:06PM -0600, Chad Walstrom wrote: ] Not an entirely bad idea. ;-) I know it's been mentioned here before. ] There are some big logistical issues with this, however. MH format uses ] the filesystem not only as a repository for email, but as a sorting ] mechanism as well. Emails are actually renamed in sequence by the ] 'sort' program. With Maildir format, your mail client must cache an ] index of references to the actual emails on the filesystem. Both ] approaches have their strengths and weaknesses.
MailDir also makes user of nameing convention for sorting. tokyo# ll new total 16 -rw------- 1 v-worst v-worst 5539 Dec 10 19:18 1071112710.18167_0.tokyo -rw------- 1 v-worst v-worst 8822 Dec 10 20:03 1071115425.18279_0.tokyo Things get numbered as they come in. Mail messages that come in at the exact same time get the _0 incremented. tokyo# ll cur total 2 -rw------- 1 v-worst v-worst 408 Jun 22 16:17 1056323803.664_1.tokyo:2,Sc The additional issue is that MailDir changes the end of the filename to represent certain flags. The big issue is that the equivalent of the unseen seqence is done via "new" versus "cur" directories for the messages. There are probably several solutions to the renumbering issue. The trick is keeping things in sync with other mechanisms that might be using the store. tokyo# ll .Trash total 46 -rw------- 1 v-worst v-worst 22 Jun 4 2003 .customflags -rw------- 1 v-worst v-worst 1608 Jun 24 17:11 .imap.index -rw------- 1 v-worst v-worst 10264 Jun 24 17:11 .imap.index.data -rw------- 1 v-worst v-worst 2576 Jun 22 16:10 .imap.index.log -rw------- 1 v-worst v-worst 1556 Jun 24 17:11 .imap.index.tree drwx------ 2 v-worst v-worst 7168 Jun 24 17:11 cur -rw------- 1 v-worst v-worst 18 Jul 9 10:10 dovecot-uidlist drwx------ 2 v-worst v-worst 6656 Jun 24 17:11 new drwx------ 2 v-worst v-worst 6144 Jun 24 17:11 tmp tokyo# cat .Trash/.customflags 0002 0 Junk 1 NonJunk ] Will NMH get Maildir support? I don't see it as highly likely, but with ] a major rewrite, perhaps. One way around the sort problem would be to ] hardlink all of the Maildir emails into an MH folder (directory), and ] allow manipulation of the files through the hardlinks for NMH while ] allowing Maildir access to other clients. Interesting, but it would end up only allowing nmh to view the world in a semi-read only state. (Delete things dont really go away, changes only happen in the nmh side of things.) ] I haven't tried to mix Maildir and MH in procmail, but you might want to ] give something like this a try: ] ] :0 ] * Subject: Test MH/Maildir ] mhtest/. mdtest/ I'll play around with this and see where it leads. The issue is really that I want to manipulate the store at different times with the two methods. Mostly I was curious if others were interested in such a project. A friend (who uses nmh) has suggested that I get nmh to support IMAP. Interesting idea, but probably fraught with more pitfalls. -=erik.