Hy,
i installed the current master branch which includes the new dovecot quota.
Thanks @aseques and all @devs!
I have a question. Logged in as customer with a hosting plan (200MB Webspace)
and i was able to set a quota with 2GB or unlimited for all the mail accounts 
I´m not sure how the used hdd space for the customer is calculated and the mails
are included there or not.
I´m a bit confused 
Thanks & Greez
BeNe
Hi BeNe, the space occuped by the whoile domain (including mail) is being calculated every night with a cron script, that one will be shown in the general domain stats.
The per-user accounting is being read from the database, dovecot itself takes care of updating the values, that will be shown in the user stats.
Hi aseques,
thanks for your answer. So i understand the way it goes.
Means a user can set 2GB or unlimited quota for dovecot - but if the webspace gets full the mail will not be able to recieve/send mails ? Not or ? Because dovecot is only checking the quota and not imscp.
If the mail account size (210MB only mails for example) is over the hosting plan (200MB total wespace) means that mail work still work but the domain is disabled ?
Sorry for that answer...
Greez BeNe
Means a user can set 2GB or unlimited quota for dovecot - but if the webspace gets full the mail will not be able to recieve/send mails ? Not or ? Because dovecot is only checking the quota and not imscp.
He will be able to receive mails even when his hosting is full, the only thing that will fail will be the upload of ftp files. That doesn't change from current mail installs.
There are plenty of things that could be done (send a warning mail when hosting is nearly full, or create and autoreply to warn the users, and others, ...)
If the mail account size (210MB only mails for example) is over the hosting plan (200MB total wespace) means that mail work still work but the domain is disabled ?
Yes, exactly that, mail will be accounted but not blocked at this point.
sorry aseques for catch this point again.
I don´t know how to handle the quota with a hosting plan.
I sell a hosting plan with 200MB of webspace including the mailspace. But this doesn´t work with current quota since the user can set unlimted mailspace for every mail account.
May there is a way as reseller to enable/disable quota or set a max value for a customer ? So i can create a hosting and say that all mailboxes comes with a 1GB max quota.
Don´t understand me wrong, i love the dovecot quota. Had this running since ispCP.
But there was only the admin allowed to set the quota in den db directly. The new way to change this in the GUI itself is perfect. But i mean we need some restictions.
Or how does the other i-MSCP handle it ? May my way of thinking is wrong ?
Greez BeNe
sorry aseques for catch this point again.
I don´t know how to handle the quota with a hosting plan.
I sell a hosting plan with 200MB of webspace including the mailspace. But this doesn´t work with current quota since the user can set unlimted mailspace for every mail account.
In our case, we warn the customers that are exceeding their plan on a monthly basis, if that's the case, we let them choose to promote them to a bigger hosting plan or change the 'days on server' setting for less days.
May there is a way as reseller to enable/disable quota or set a max value for a customer ? So i can create a hosting and say that all mailboxes comes with a 1GB max quota.
No at the moment, altough it would be nice, something like locking a customer to set a quota bigger than his space allowed.
Don´t understand me wrong, i love the dovecot quota. Had this running since ispCP.
But there was only the admin allowed to set the quota in den db directly. The new way to change this in the GUI itself is perfect. But i mean we need some restictions.
The current implementation has been done trying to do minimal changes to the i-mscp behaviour, because the courier users cannot implement quota in an easy way.
Or how does the other i-MSCP handle it ? May my way of thinking is wrong ?
I don't know about the others, but blocking it on real time is difficult due to the resources needed.
The easiest change would be to use the same script that make the accounting overnight to warn the users (sieve, warn mails, redirection, ...)
I think we should aim at dropping courier support. Now that there's a clean way to migrate all the mailboxes without any kind of information loss, there is simply no reason to stick with courier anymore. Dovecot is a superior piece of software, that can do everything courier can, plus some extra things. Further, it performs better in general (a lot better in some cases).
I opposed to a dovecot transition in the past (on the other project). The reason was simple: in there, we supported older debian versions (lenny) and other oses/distros that did not include dovecot >=1.1. Until dovecot 1.1 there was no clean way to migrate existing mailboxes, so dropping courier support would have meant unclean migrations (with already downloaded mails being downloaded again by the clients). However, this is not an issue anymore because all of the imscp's supported distros/versions *do* have dovecot > 1.1.
AFAIK, the only reason courier is still supported in imscp is because nuxwin wanted to keep courier, arguing that "he was fine with it and didn't want to change". Since this is obviously not a sound reason, and nuxwin is not around anymore, my opinion now is that we should move forward, drop courier, and try to achieve the best panel behaviour we can.
In this case, there should be at least a per-domain maximum mailbox quota limit, just like there is one for the disk space. The only thing I am speaking about here is a new limit in the hosting plans, stating the maximum cumulative quota that can be assigned to mailboxes of each domain. This is, a limit of "1Gb" should allow for either a 1Gb mailbox or 10 100Mb mailboxes, but not a 10Gb mailbox.
Additionally, the panel should let admins choose if the mail space is intended to be counted towards the disk quota or not. If it is not, then mail space is only limited by the mail quota above, and is enforced in real time by dovecot. Otherwise, the nighly script will detect disk oversize in the nighly run and disable FTP access (just as it does right now).
I think we should aim at dropping courier support. Now that there's a clean way to migrate all the mailboxes without any kind of information loss, there is simply no reason to stick with courier anymore. Dovecot is a superior piece of software, that can do everything courier can, plus some extra things. Further, it performs better in general (a lot better in some cases).
I opposed to a dovecot transition in the past (on the other project). The reason was simple: in there, we supported older debian versions (lenny) and other oses/distros that did not include dovecot >=1.1. Until dovecot 1.1 there was no clean way to migrate existing mailboxes, so dropping courier support would have meant unclean migrations (with already downloaded mails being downloaded again by the clients). However, this is not an issue anymore because all of the imscp's supported distros/versions *do* have dovecot > 1.1.
AFAIK, the only reason courier is still supported in imscp is because nuxwin wanted to keep courier, arguing that "he was fine with it and didn't want to change". Since this is obviously not a sound reason, and nuxwin is not around anymore, my opinion now is that we should move forward, drop courier, and try to achieve the best panel behaviour we can.
+1
In this case, there should be at least a per-domain maximum mailbox quota limit, just like there is one for the disk space. The only thing I am speaking about here is a new limit in the hosting plans, stating the maximum cumulative quota that can be assigned to mailboxes of each domain. This is, a limit of "1Gb" should allow for either a 1Gb mailbox or 10 100Mb mailboxes, but not a 10Gb mailbox.
Additionally, the panel should let admins choose if the mail space is intended to be counted towards the disk quota or not. If it is not, then mail space is only limited by the mail quota above, and is enforced in real time by dovecot. Otherwise, the nighly script will detect disk oversize in the nighly run and disable FTP access (just as it does right now).
I quite like both ideas, after droping (if it's dropped) courier we could do a roadmap to implement those. At the moment I wouldn't request for dovecot more than we already provide with courier.
AFAIK, the only reason courier is still supported in imscp is because nuxwin wanted to keep courier, arguing that "he was fine with it and didn't want to change". Since this is obviously not a sound reason, and nuxwin is not around anymore, my opinion now is that we should move forward, drop courier, and try to achieve the best panel behaviour we can.
What about the ispcp migration?
What about the ispcp migration?
The migration courier -> dovecot is totally transparent to the users. There should't be any features from courier that can't be replaced transparently by dovecot.