Hi, I have a 2 month old Debian Wheezy mail server running Courier, ISPconfig 3.0.5.3 and Roundcube 0.9.5 The issue I'm having is in quotas. Yesterday one of the mail clients exceeded their quota so I doubled their mailbox size (500MB to 1000MB) and everything started to work again. Then from 00:40 the log shows them having quota errors again with the following error: Mar 12 00:40:55 srv5 postfix/pipe[9219]: A83CF362: to=<[email protected]>, relay=maildrop, delay=0.11, delays=0.05/0.01/0/0.05, dsn=4.3.0, status=deferred (temporary failure. Command output: maildrop: maildir over quota. ) Looking at the physical mailbox size it was about 575MB and ISPconfig was confirming this but logging onto roundcube webmail showed the mailbox being 100%. After changing the quota again to 1005MB everything then started working again, as it did yesterday, and roundcube changed to 51%. I assume the issue came in during the running of cron_daily which happens at 00:30 if I'm reading crontab correctly. Looking in the syslog and ispconfig/cron.log the only issue from the day before was: Tue Mar 11 00:30:01 GMT 2014 PHP Notice: Undefined index: admin_mail in /usr/local/ispconfig/server/cron_daily.php on line 1031 Tue Mar 11 00:30:01 GMT 2014 PHP Notice: Undefined index: admin_mail in /usr/local/ispconfig/server/cron_daily.php on line 1039 We believe we fixed this yesterday, before the issue, by putting an email address in the ISPConfig - System Config - Mail - Administrators email, we simply used [email protected] (ie one of the locally hosted accounts). After this we had no other messages. Any help would be appreciated.
The mail quota is not altered by the cron_daily.php script. The error message that you posted is just about the missing admin email address, it does not affect the quota function. The only way that a mailquota can be altered in ispconfig is by editing the mailbox and changing the quota value in the quota field.
Hi Till, I agree with what you're saying, I don't believe ISPConfig changed its quota. There is nothing to suggest it did, change the quota in that ISPconfig returned the correct quota setting for the user when I looked at their configuration. The issue was simply that wherever postfix gets its current volume and quota settings from was presumably not in sync with the settings in ISPconfig. This mismatch in settings was also visible through roundcube which gave the wrong settings. The only reason I mentioned cron_daily is the issue occurred just after that ran which seemed to be a coincidence. Do you know how postfix integrates with the whole quota process and what I may be able to check here?
Postfix is not checking the quota itself, it relies in courier-maildrop (the lda) for that. So basically postfix hands the email over to courier and courier-maildrop tries to put the email in the mailbox , if the quota is reached, it will reject the delivery and notifies postfix. So there is just a single application that handles the quota, I have no idea at the moment how it can differ in courier-imap and courier-maildrop.
Thanks Till, I assume courier reads the quota from the ISPconfig's database using /etc/courier/authmysqlrc details. Having checked the database backups from before and after the cron_daily there was no change in quota size and everything looks correct. What actual changes take place when I edit an individual users quota and hit save, as this fixed it it may give me a clue.
Just out of interest, there is clearly a difference between the current mailbox size as shown by ISPConfig and the actual size which is more inline with roundcube. Is this just because we're using courier, I read in the manual that the mailbox quota report is not available if you use Courier but it appears?
The maildir size that ispconfig shows for courier is the size of the maildir in the filesysstem reported by "du" command, as courier does not offer any other internal methods.
Hi Till Just as an update, I found the issue. Our warm standby server has files synced using unison but we don't automatically syns the databases at this time. What therefore happened, I believe, is at the daily cron job ISPConfig on our warm standby server finished making changes after our primary server. I assume one of these changes altered the maildirsize which was then resynced back to our primary server, reducing the quota hence roundcube and courier-maildrop thought the quota had been exceeded whilst ISPconfig said it was fine. Just for information, the reason we don't use master master replication on the databases at the moment is on our old servers we had more outages caused by having to resync the master master replication than we did due to primary server faults. The plan this time will simply be to copy the ISPConfig and Roundcube databases on a scheduled basis as we don't intend to have an automated failover, it will strictly happen when we need it to. If you have any negative thoughts on this it would be great to hear them.
