[Dovecot] 1.0-test21

[Timo Sirainen]

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? :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20040622/3488bb12/attachment-0001.bin>