Cor Bosman wrote:
I've been implementing this slowly over the last few months. Takes annoyingly long (it's boring), but it's getting there. In the mean time IMAP and POP3 code in 1.0-tests keep stabilizing nicely. So after this one large change things may be a bit unstable for a while, but after that 1.0 should be very near :)
I personally think one small issue in the current dovecot is kind of a showstopper. If a user exceeded their quota, dovecot will just plain not work at all. So a user can also not delete their email to remedy the situation.
This is what happens when a customer (without previously having used dovecot) connects:
A002 SELECT "INBOX" A002 NO Internal error occured. Refer to server log for more information. [2005- 05-31 17:56:36]
The internal error is a 'quota exceeded'.
I think at the very minimum someone should be able to delete email...
Regards,
Cor
Cor,
I agree with you. I've resorted to having a script run to check quotas twice a day and sending notifications (I have a fairly large difference in soft and hard limits set) to each user that they are over their quota and what remaining grace time they have so they can remove mail from the server as appropriate.
On occassion I have to temporarily increase a user's quota just to allow them to connect and remove their email.
The problem as I see it, however, isn't specifically a Dovecot issue. the quotas are filesystem level quotas, and in order to move/delete/etc mail, the user would have to have persmissions to write files on the filesystem (which it does not). Obviously having the imap/pop3 portions of dovecot running as root is not an option.
It would be nice if dovecot had an application level quota facility, but I think it's been made pretty clear that it's not a priority feature at this time (correct me if i'm wrong, anybody)
Alan