Junk/Trash + COS Message Lifetime problem

[psousa]

Hi,

First of all. Zimbra Rules... I've migrated my 2 sendmail servers to Zimbra and my users appreciate the huge diference.

But we still have some issues. One ot them is that messages in Junk/Trash folder are never purged from users mailboxes.
I've set the Spam message lifetime and the Trashed message lifetime in COS (applied to my users) but these values are never applied/executed. I've checked the logs (maibox.log) for audit information about purging message process but I have no messages!!!
I've set both values to 30 days and since the beginning of January no message was ever deleted!!!

Looking thru the Forum I've came across this post ([SOLVED] junk mail cleanup) but my version is 4.5.9 UBUNTU6 OSE. When I've tried to set the zimbraMailPurgeSleepInterval value zmprov said there was no such property.

Can anyone help, please?

Thanks,
Pedro Sousa
Law Faculty of Oporto's University

[DEREKB]

Not deleting the Junk folder messages is a bug in the version of zimbra you have . You need to upgrade to the the latest 4.x (4.5.11) version or preferably to the latest 5.x version (5.0.5)

[mmorse]

& when you upgrade to 4.5.11 realize that there still won't be a zimbraMailPurgeSleepInterval as that was implemented in 5.0.0RC2

To explain it better:
There really is no concept of a "purge interval". The purge thread is constantly running, purging mailboxes in memory, one at a time. Between every one-two mailboxes it sleeps for the interval specified by zimbraMailPurgeSleepInterval. I have much fewer mailboxes on my server so 1d or 1m is fine for me - set accordingly after you work out the math. This is way more robust than the old method & allows for spreading the load out overtime, which is especially nice for larger setups.

Work on this was done via Bug 13435 - User-definable expiration policy for systems folders where PurgeThread was implemented, which iterates all the mailboxes on the server and purges them one at a time. Mailboxes are only purged if they're loaded into the server cache & the thread sleeps between subsequent purges.
In short, the current mailbox purge algorithm only affects mailboxes that are in memory - as the theory is that if a mailbox is not in memory, it's not being accessed, not receiving mail, and therefore has less of a need to be purged.
Bug 20720 - Guarantee that mailboxes will be purged was filed for the issue of wanting a double check - possibly by making use of a zimbraMailLastPurgedTimestamp.

And yes zmpurgemessages, which used to produce some heavier load, was removed from cron/libexec in Bug 20705 - Remove zmpurgemessages

Of course it's all dependent on the zimbraMailSpamLifetime/zimbraMailTrashLifetime (default 30d) for what mail is removed.