Email Retention Policy trouble

[InternetGuy]

Hello,

Version 6.01, just noticed my email retention policy settings aren't working. I have "trashed message lifetime" set to 7, but one guy has messages in his trash that are a year old. The settings page says:

Note: These settings will not have effect if zimbraMailSleepPurgeInterval is disabled...

My setting is:

zimbraMailPurgeSleepInterval: 1m

BTW, notice the spelling difference in terms.

Ok, what am I missing? I'm sure his account is in the correct COS.

[tiger2000]

i remember someone said that system will purge the messages (according to message lifetime setting) only if their mailbox are loaded into memory.

however, i also hope to understand how to load someone's mailbox into memory so that it will be purged by system's lifetime policy?? (anyone help??)

[phoenix]

Originally Posted by tiger2000

i remember someone said that system will purge the messages (according to message lifetime setting) only if their mailbox are loaded into memory.

That's nonsense, messages are purged according to the defined schedule & lifetime.

Originally Posted by tiger2000

..... so that it will be purged by system's lifetime policy?? (anyone help??)

Search the forums for the setting mentioned above.

[tiger2000]

did you mean these settings ?

user-level:
zimbraPrefInboxReadLifetime
zimbraPrefInboxUnreadLifetime
zimbraPrefSentLifetime
zimbraPrefJunkLifetime
zimbraPrefTrashLifetime

system-level:
zimbraMailTrashLifetime
zimbraMailSpamLifetime
zimbraMailMessageLifetime

if yes, then these parameters don't work for my case. (no idea why)

any other info? thanks.

[ArcaneMagus]

Does this give you a number bigger then 0?

grep MailboxPurge /opt/zimbra/log/mailbox.log* | wc -l

[tiger2000]

yes, command result is > 0

system did purge several accounts' mailbox, however, I found there's still some accounts , even all parameters regarding to *lifetime* is set, are not purged.

does it have anything to do have the total accounts in system? we have thousands account in this system. (5.0.13 OSS)

[phoenix]

Originally Posted by tiger2000

yes, command result is > 0

system did purge several accounts' mailbox, however, I found there's still some accounts , even all parameters regarding to *lifetime* is set, are not purged.

How about posting the settings for a non-working mailbox and one that works plus the system wide setting instead of just saying it 'doesn't work'.

Originally Posted by tiger2000

does it have anything to do have the total accounts in system? we have thousands account in this system. (5.0.13 OSS)

The number of mailboxes on your system is irrelevant.

[tiger2000]

sorry for that, i should be more specific.

i have a script to set these parameters for those whose mailbox quota is > 97% and whose last login time is 30 days ago.

zimbraMailMessageLifetime: 60d
zimbraPrefInboxReadLifetime: 60d
zimbraPrefInboxUnreadLifetime: 60d

then script will do a "sleep 2556000" (71 hours), after that we will config these settings back to "0d".

we monitor mailbox.log* files by grep "MailboxPurge" for those account we've set. However, we didn't find any logs relative to these accounts.

that's what i saw..

[celsowebber]

Hello tiger2000,

Maybe your complain is right. I've just checked that on a 6.0.4 system and immediately after I changed these parameters the logs showed several [MailboxPurge] messages.

So for it's working, maybe it's a bug on 5.0.18? Since your post is some months ago, maybe you did solve this?

Regards, Celso.

Originally Posted by tiger2000

sorry for that, i should be more specific.

i have a script to set these parameters for those whose mailbox quota is > 97% and whose last login time is 30 days ago.

zimbraMailMessageLifetime: 60d
zimbraPrefInboxReadLifetime: 60d
zimbraPrefInboxUnreadLifetime: 60d

then script will do a "sleep 2556000" (71 hours), after that we will config these settings back to "0d".

we monitor mailbox.log* files by grep "MailboxPurge" for those account we've set. However, we didn't find any logs relative to these accounts.

that's what i saw..