Mail over the 'lifetime' will be removed when the purge thread hits it - the user inherits the COS value unless you set it explicitly on the user's account:
COS Level-
Check by:
zmprov gc COSName | grep Lifetime
Set by:
zmprov mc COSName zimbraMailTrashLifetime 30d
zmprov mc COSName zimbraMailSpamLifetime 30d
OR User Level-
Check by:
zmprov ga
user@domain.com | grep Lifetime
Set by:
zmprov ma
user@domain.com zimbraMailTrashLifetime 30d
zmprov ma
user@domain.com zimbraMailSpamLifetime 30d
The purge thread itself:
Check by:
zmprov gs server.domain.com | zimbraMailPurgeSleepInterval
Set by:
zmprov ms server.domain.com zimbraMailPurgeSleepInterval 1m
0 on any of those disables automatic purging for that machine/account
So really it's a but of math logic -say you have:
-6 users
-zimbraMailTrashLifetime 30d
-zimbraMailPurgeSleepInterval 1d
-A message in the trash of account 5 that's 31 days old - this mail is now 'capable of being removed' as it's over the zimbraMailTrashLifetime.
Day 32: Mailboxes 1/2 are purged
Day 33: Mailboxes 2/3/4 (I'm not gonna nail down this timing right now - 3 gets purged for sure)
Day 34: Mailboxes 4/5/6 are purged
So really that message in account 5's trash technically stayed around till day 34.
This allows for better scaling rather than just everyone in one big cron job putting load on the server - for instance you could decide to purge 1400 accounts per day.