![]() |
Courier+maildrop are not updating maildirsize
It seems that the file /home/vmail/domain/user/maildirsize is not being updated with the new quota size when the quota is changed by ISPConfig. The hack that seems to fix it is to run the commands:
maildirmake -q {quota}S /home/vmail/domain/user/ chown vmail:vmail /home/vmail/domain/user/maildirsize right after the quota is changed. I don't know where to add this hack to ISPConfig to fix the bug, if this is even the right hack to do it. |
Courier and maildrop are configured to read the maildir size directly from the mysql database in the file /etc/courier/authmysqlrc
|
It is configured to read it when creating the maildir the first time, but it seems to ignore the database after the user is created. I could be wrong, but so far all my tests show that it only looks to the database during initial creation, then ignores the database afterthat(atleast when it comes to quota). But if you manually tell it to recalculate the maildirsize file then it accurately handles changes in mail dir sizes.
|
Ok, then we should add this in the user_update function in the plugin file /usr/local/ispconfig/server/plugins-available/mail_plugin.inc.php
Maybe we find later a reason why maildrop is not recognizing it in the db. |
Till, you or me?
I think if I program it I think the code will still need to be cleaned up, but I think I can make it 'work' quickly. Do you know where I can find an example plugin that executes a command on the command line? Should exec() be used? or avoided? |
Ok, never mind. Found it, and a sample.
exec('mkdir -p '.escapeshellcmd($data['new']['maildir'])); exec('chown '.$mail_config['mailuser_name'].':'.$mail_config['mailuser_group'].' '.escapeshellcmd($data['new']['maildir'])); |
It is fine to use exec, we dont have a wrapper function for exec (at least yet).
|
Quote:
|
I'll see if I can get this bug atleast started. I might be able to make it work.
Till, of the bugs I've seen I would say the one I would need help tracking down in the mail quota size. It's an int overflow bug. It could be a security concern. I don't know if the over flow is in the AJAX side of things, or in the php processing side. |
Till, also there seems to be no way to change the log level.
|
| All times are GMT +2. The time now is 08:03. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2013, vBulletin Solutions, Inc.