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