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