[Dovecot] maildir++ specification compliance.

[Stephan Bosch]

Apps Lists schreef:
> I was doing some testing this morning and realized Dovecot RC2 isn't fully
> compliant with the maildir++ specification.
> 
> Most notably, it appears that Dovecot isn't creating a "maildirfolder"
> file (0 byte length) in folders it creates.
> 
>>From http://www.inter7.com/courierimap/README.maildirquota.html
> 
> "Within each subdirectory there's an empty file, maildirfolder. Its
> existence tells the mail delivery agent that this Maildir is a really a
> folder underneath a parent Maildir++."
Yeah, noticed this too. The .dovecot.sieve file in my maildir is 
recognized as a folder when I open my subscription dialog :).

>  While Dovecot shouldn't be creating maildirsize files in each folder (the
> maildirfolder file is there to tell clients to look in .. for a
> maildirsize) ... it should still be able to answer queries about the
> number of messages (count of files in the folder) as well as the total
> size of all messages in that folder (sum of S=xxxx or by stat() on
> individual message files).
Actually this behaviour of dovecot is correct. All (maildir) folders 
currently belong to the same quotaroot and therefore dovecot will report 
the same quota for each folder you query within the same storage. By the 
looks of it, the current quota plugin does support various quota roots 
in general, but the maildir-storage-quota implementation does not.

I gave this some thought in the past. You could add support for multiple 
quota roots to the Maildir specification. The problem is that other mail 
programs won't support it.  If this is implemented, one is (at least 
initially) forced to use the dovecot-lda. One way to implement this is 
by managing a separate maildirsize (e.g. maildirsize.SOMEROOT) file for 
each quotaroot and putting some other file(s) in the maildir specifying 
the structure of the maildir regarding the quotaroot membership of the 
different folders. If this is specified properly we could possibly 
persuade other mail software to support this new feature.

(BTW, stat()'ing or summing the S=xxx names of the files is a relatively 
slow process and that is why the maildirsize file was concieved in the 
first place. So, this would not be a very good idea.)

One could even combine this new feature with the trash expire 
functionality; give folders like 'Trash', 'Junk' or 'Spam' their own 
distinct quotaroot and perform the deletion if the root goes over quota. 
Using the IMAP protocol one could configure this such that the users can 
set their own Trash quota voluntarily (giving them no power over their 
overall quota).

Regards,

Stephan