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.