Eventually, I took the time to investigate this a bit more. My Debian box with ISPconfig is running Debian 4.0 "Etch" (pretty much a default installation) with a current ISPconfig v2.2.19.
The problem persists: /var/log/mail.log.0 shows only lines from midnight until approximately 6:30. The reason is, vaguely put, a conflict between default Debian log file rotation and ISPconfig, more specifically its cronjob
59 23 * * * /root/ispconfig/php/php /root/ispconfig/scripts/shell/mail_logs.php
BTW, if you miss your data have a look at the other mail.* log files, especially /var/log/mail.info
Whether your Debian log file rotation kicks in or not you can check with
It returns all files which get rotated weekly by means of /etc/cron.weekly/sysklogd which again, on my system, is run every Sunday morning at 6:47 (see /etc/crontab).
But the main problem I see -- sorry to say this -- in ISPconfig's /root/ispconfig/scripts/shell/mail_logs.php -- though the whole issue is definitely not trivial. Anyway, from my point of view, mail_logs.php needs some rethinking.
wrote, mail_logs.php is working on a temporary copy. I guess he referred to line 53
$mod->log->caselog("cp -f $dist_mail_log $dist_mail_log.$datum", $FILE, __LINE__);
So this is true. But a few lines further below the original data is overwritten with
$fp = fopen($dist_mail_log, "w");
There our data is lost. mail_logs.php deletes everything until midnight.
I do not know enough about ISPconfig but I am afraid this here is bound to break on systems with log rotation that occurs during the day. I guess it also means that ISPconfig's mail stats are not accurate. Certainly, just disabling the lines which erase $dist_mail_log does not help.
Nevertheless, maybe there is a simpler fix since till
reported that he has never seen this problem, probably for a reason.
P.S.: In mail_logs.php there are references to $datum2 which I assume does not exist/is empty. It does not break the script but I recommend to fix it anyway should the code ever be used somewhere else.