Mail broken since security update 2008-004, multiple symptoms

Question

Unfortunately, I can't sum this up in a snappy headline.
To get this started: the machine is an iMac 800MHz, which is running Mac OS X Server 10.4.11. It's not running Leopard, which might cure several issues, because it can't be installed on that machine.
The load is very light (low-traffic web site, DNS server for a low-traffic domain, mail server for essentially one user). I just mention this before I get the "you should not run this on an iMac" type of replies, which are not to the point. The computer ran Mac OS X Server ever since I got it years ago, and it can keep up with the load just fine. It can't keep up with the fragile nature of the Cyrus/postfix/whatever combination, which e.g. after a power outage, or worse, after a software update seems to leave the system semi-regularly in a state that's utterly undefined.
So the system was running very smoothly, for the first time in quite a while, until that security update 2008-004 came along. In installed it, rebooted the system, and now Mail service is down.
If I try to look at the settings for Mail with Server Admin, I get this error message:
"A Service has encountered an error - Try to refresh the view (MY.FIXED.IP.ADDRESS/Mail). Report the problem to the administrator if it persists. (Cannot allocate memory)"
Usually, when Mail acts up, I have this standard routine that I execute, and in 98% of cases that fixes everything:
+serveradmin stop mail+
+serveradmin stop mail+
+find /private/var/imap/socket/ -name "lock" -print -exec rm -rf {} \;+
+rm /private/var/imap/socket/lmtpunix*+
+rm /private//var/imap/socket/lmtp+
+sudo -u cyrusimap /usr/bin/cyrus/bin/ctl_cyrusdb -r+
+sudo -u cyrusimap /usr/bin/cyrus/bin/chk_cyrus+
+serveradmin start mail+
+serveradmin start mail+
+postfix check+
+postfix start+
Typically, when the ctl_cyrusdb -r runs, I see all the various IMAP folders listed as they are being processed. This is NOT happing now, even though if I navigate into /var/spool/imap/user/someUserName they are all there in the proper hierarchy
I ran DiskUtility's repair permissions, just in case something was screwed up by the ugprade. Also no dice.
Any hints highly appreciated...

Answer 1

Thanks for your suggestions. I knew that a full rebuild of the database would likely get things going again, and I ended up doing just that, because there server was reaching the point of down-time where permanent delivery failures would result if I didn't bring it back up.
The problem with the mailbox rebuild approach is, that all flags and read/unread status are lost, with is a MAJOR problem. I wish Apple's Mail had a feature where you can push cached message status back to the server, overriding server side message attributes with those cached on the client. Unfortunately this isn't available.
So Mail is running again, but I can't really consider this problem "solved" because all my flagged messages are unflagged, and all messages, read or unread, are now marked unread. If you have a mail archive of several GB dating back to the early 90s, then losing the flagged status on messages is a major issue, as is trying to ge a few hundred thousand messages to get unread again...
I do however take some exception to what you write:
pterobyte wrote:
You shouldn't have to rebuild your database after a restart or update. If you have to something is wrong on your server. A power outage is a different issue. Any database in the world can get inconsistent because of a sudden power cut. This is what an UPS is for.
That is akin to saying, it's OK if a file system is in a messed up state when the power goes down. That's what atomic operations, transactions, journaling, etc. were invented for. This day and age, there's no excuse for a database to end up in a messed up state because power went down, or for that matter, the system crashes, because no UPS will protect from the latter.
Critical systems, and mail delivery belongs to these, must handle failure gracefully, and the technology to do so, does exist.
pterobyte wrote:
Also, on OS X Server you should NOT use "postfix stop|start". Use Server Admin or launchctl to stop the launchd item. Furthermore, you should not manually interact with the Cyrus database and remove files. Cyrus is capable of handling its locks and sockets.
I know that this is how things SHOULD be. Unfortunately, postfix will not start properly when mail services are started with server admin. It will stop properly when I stop mail services though.
I had posted a question about that ages ago, but nobody could figure out what is going on. So in the mean time I have resigned to the fact that I have to start postfix manually after each reboot.
I'd more than happy to get past that issue. Here a link to my question regarding this matter:
http://discussions.apple.com/thread.jspa?threadID=904736&tstart=0
http://discussions.apple.com/thread.jspa?threadID=908174&tstart=0
Similarly, I had once issus where cyrus would refuse to start up, and I found in some support forum the instructions to remove some of these lock files and pipes. That indeed got cyrus going again, and since it recreates these files automatically, I ended up adding the removal of these files to my "try this procedure if mail acts up" routine. It doesn't seem to harm the setup from what I can tell, and it has gotten a stuck system back to work more than once.