On 22.6.2004, at 04:44, Tom Allison wrote:
That last statement is arguable. cyrus-imap has some nice capabilities. But if you use procmail then it's no contest who is going to win! ;)
I actually hate procmail. It's code mostly. It's horrible.
But I seem to remember that their indexes had an achilles heal. If you (re)moved an email file via filesystem then the indexes were badly corrupted and there was little you could do with that mail directory again. I don't think that this is proper behaviour for imap servers under a unix environment.
I think it can be fixed by running "cyrusadm recover" or something similiar.
That said, I suspect that cyrus used their indexes as a means of providing some rudimentary search results for a give key and an array of file inodes for the correlating email messages in maildir. This would store the locations in the file inode table, making for a nice speedy access of files. Hence, the removal of a file would corrupt their inode lookup table...
I don't really understand much of that :) If you mean by inode table the real filesystem's inode table, I don't think you can store any custom data there yourself? And removing the file would remove the inode, so no problem there.
Anyway, Cyrus' indexes are currently quite similiar to Dovecot's. It stores more data per mail, but some of it is just bloat and the rest is forcefeeded caching data that client may never use. Cyrus would be able to deal with losing files if it just wanted to.
Implementing Cyrus mail store support for Dovecot might be a fun project, any takers? :)