maildir and IMAP hell

from Olivier Thereaux <[email protected]>, Wed, 24 Dec 2003 10:11:12 +0900

Replies:

Parents:

None.

For the past few (2 or 3) years I have been a happy user of maildirs. It
started on this list. I am starting to wonder whether it will stop here,
too.

After being hyped for a while, it seems that maildir is becoming
"featura non grata" in a few systems. Here is, e.g, the message one gets
when upgrading uw-imapd (and related packages) in Debian:

[[
Libc-client earlier than version 2002d (and development versions of
2003) included an unofficial and no longer maintained patch to support
Maildirs. By default Maildirs where not used by uw-imapd or ipopd,
but if you have changed your system configuration or other installed
programs depend on libc-client then upgrading may result in broken mail
handling.
]]

I could not find a justification for these changes other than bland
comments in changelogs such as "dropped maildir patch" and messages
("there was, and is, no [official] support for maildir in the c-client
lib") in mailing-lists. Apparently, the patch (here? [1]) was simply
dropped because it was lacking an official maintainer and the
unmaintained code was getting out of sync [2]. Fair enough.

[1] http://www.flounder.net/qmail/
[2] http://www.freshports.org/mail/cclient/

Not knowing whether there was actually a search for a maintainer or if
the featured was just dropped because it was more convenient, I will
certainly not judge c-client maintainers' decision, olny lament that it
will make my own litte life miserable while I sort it out.

One of the results of this change in the c-client lib is that, uw-imapd,
which has no maildir support but was relying on the lib, now does not
understand the "cur tmp new" structure, and simply thinks that each of
the file in subfolders is actually a mailbox. In other words, *not*
usable.

Fortunately, mutt is good as ever (even better, somehow, now that my new
OS makes me input unicode with vim properly) so I can still read and
write mails, but I am back at a point where reading e-mail on several
machines, on- or offline can only be made through complicated syncing
mechanisms, when IMAP syncing was, especially with Apple's Mail.app, a
breeze.

The only option seems to be courier-imap, which does have native Maildir
support. I have not found yet any "good" documentation, but if I am not
mistaken, its hardcoded namespace (INBOX.foo) for maildirs seems to make
it a massive PITA, as I would have to move all my maildirs around to fit
that naming convention. I hope I am mistaken, because that would be
about as unpleasant as converting maildirs back to mailboxes, which I am
also considering, although reluctantly. At least I can consider myself
happy that I have control over the server where my mail resides...

I know there are several people here who started using maildirs at about
the same time as I did, did you run into the same kind of issues, or
were you so far unaffected?

More to come, maybe, as I proceed with exploring courier.

--
olivier

Re: maildir and IMAP hell

from Olivier Thereaux <[email protected]>, Wed, 7 Jan 2004 09:11:24 +0900

Replies:

None.

Parents:

On Wed, Dec 24, 2003, Olivier Thereaux wrote:
> More to come, maybe, as I proceed with exploring courier.

I finally made my system work with courier... *Not* thanks to the doc,
which is apparently quite scattered, incomplete, and in my case
unhelpful.

What I learned with a lot of trial-and-error:

- The maildirs MUST be in ~/Maildir
If the directory does not exist, courier fails the authentication (now
*that* is a useful error message, thank you!)

- ~/Maildir MUST have the maildir format (i.e "cur tmp new" subfolders)
otherwise it stops silently and does not look for other sub-maildirs

- sub-maildirs must follow a specific naming convention (see below)

- While other implementations of maildir actually allow the directories
to be embedded, courier only accept a flat list, and has its own way
of creating a virtual tree.

e.g... I have maildirs as follows:

~/Maildir
\
maildir 1
foobar subdirectory
\
maildir 2
maildir 3
maildir 4

etc.

courier only accept a flat list as follows:

~/Maildir
\
.maildir1
.foobar.maildir2
.foobar.maildir3
.maildir4

the "dots" as separators for the hierarchy are mandatory, as far as I
can tell.

This did not really fit with my current mail structure, where maildirs
are in ~/mail, and deeply embedded

So I created ~/Maildir and the proper subdirectories ('mkdir cur tmp
new') and wrote a small perl script (I'm too lame to make it with shell,
but I'm certain it takes a simple one-liner) to symlink the existing
~/mail/foo/bar/quz to the appropriate ~/Maildir/.foo.bar.quz

copied here for your convenience, just in case:
[[
#!/usr/bin/perl -w

my $mdirname;
my $mdirsymlink;
open (MDIRS, "find ~/mail -name new |");
while (my $mdirname = <MDIRS>)
{
$mdirname =~ s/\n//;
$mdirsymlink = $mdirname;
$mdirname =~ s/\/new//;
$mdirsymlink =~ s/\/home\/ot\/mail//;
$mdirsymlink =~ s/\/new//;
$mdirsymlink =~ s/\//./g;
print "~/Maildir/$mdirsymlink";

if (-e "~/Maildir/$mdirsymlink")
{ print " already exists \n" }
else
{ `ln -s $mdirname ~/Maildir/$mdirsymlink`;
print " alias created \n";}
}
]]

The result is fast (quite obviously, since the imap server does not have
to read through the directory tree, only the flat list of maildirs)...
Which makes me think that courier is a good server, well documented with
regards to its installation, so it's a great candidate for a new server
welcoming new users, but its lack of good documentation doesn't make it
a very good candidate for e.g transition from a POP server, or another
implementation of maildirs over IMAP.

--
olivier