Yeah, I dislike current IMAP servers exactly for the reasons you list
here. I think one file per message is the only reasonable mode of
operation. It would be best to tune the message store file system for
small inode size, and avoid the problem of large directories by storing
the messages in an /ab/cd/ef/gh type hierarchy. They would be useless on
their own, just a big soup of messages without the database.
Ryan Butler wrote:
Flat files on large mailboxes are terrible performers. It might read
sequentially faster, but try removing a message from the middle of the
flat file...
Not to mention how inflexible it is.
There's patches to qpopper and uw-imapd that allow you to use a sql auth
system with them. Maybe one of those would be better suited to what
yoour goal is. (Its what I ran previous to switching to dbmail)
