On Thu, 2007-03-01 at 13:01 +0000, Daniel Watts wrote:> Hi All,
>
> I've read a bit about this but don't really see a full solution
> anywhere. Has anyone actually got a good fix for this?
>
> Telling a user they are over quota then not allowing them to delete
> anything does seem the height of perversion. =)
>
> Question is - is this even a problem for the IMAP server? Or should the
> MUA be detecting over quota problems and then issuing the right commands
> to delete messages WITHOUT the copy to Trash?
I hate the whole "copy to Trash" feature. Some future Dovecot versions
will have virtual mailbox support, and then it can be implemented by
creating a virtual Trash mailbox that contains all the messages with
\Deleted flag. Then there won't be any problems with this since the mail
is never really copied at all (it could just ignore the COPY commands).
With virtual quotas the copy-to-Trash can be solved by either a)
ignoring quota in Trash (maildir backend supports this) or b) giving
some extra space (eg. +100MB) into Trash (supported by quota-rewrite
code).
With filesystem quotas it really can't be fixed.
> Lastly - even if it is the MUA's responsibility - will Dovecot not
still
> have a problem with indexes? I suspect perhaps not if:
>
> A. When using FS Quotas you store the indexes in a non quota partition
Right, this is how it should be done.
> B. When using other quotas (dirsize / maildir++), Dovecot does not count
> the index files when counting up the usage.
>
> Is B true?
With maildir++ yes, with dirsize it looks like the indexes are counted
if they're in the same directory. But it still doesn't matter much
because the problematic case with indexes is that they can't be written
to if filesystem quota is full. With dirsize quota the writes still
succeed even though it would make the user go over quota.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070301/0de147eb/attachment.bin>