[SOLVED] does the spam filter learn from unread messages in Junk

[alto]

I know everyday Zimbra polls the spam and ham folders but wonder if it will pick up on unread messages in the Junk folder. And as you can set how long it keeps the messages in Trash and Junk will it automatically delete unread messages from Junk after 30 days or what ever option is set.

And yes I suppose if they are already in Junk as unread then its done its job but will it delete unread ones.

I have some users who are using Outlook and never check the Junk for missed or open the mail client. One user has 3,000 unread in Junk so I guess I'm answering my own question and they are not automatically deleted. Is it possible to make it delete unread in Junk?

Overall Zimbra is great and has been running without much trouble for nearly 2 years now so well done, keep up the good work, thanks.

[phoenix]

Overall Zimbra is great and has been running without much trouble for nearly 2 years now so well done, keep up the good work, thanks.

Which version of Zimbra are you currently running? Yes, the Junk folder contents will get deleted after a set period of time (you can modify that in the Admin UI on recent versions).

[alto]

Hi, we use 5.0.2 Network edition moving shortly to 5.0.5 for some bug fixes.
Where can I modify this? Is it the HSM setting
Just now I had a look in Admin gui and our hsm is set to 30 days, then popped in to a users mailbox who has 6,000 unread spam in Junk the oldest dated 27th Jan over 90 days

[phoenix]

Go to Admin UI and Class of Service/Advanced tab and then Email Retention Policy, you can set the lifetime there.

[alto]

Go to Admin UI and Class of Service/Advanced tab and then Email Retention Policy, you can set the lifetime there.

I might be missing something here but in the advanced tab there is:
Attachment Settings
Quotas
Password
Failed Login Policy
Timeout Policy

now Timeout Policy has email message lifetime as 0 days, trashed and Spam message lifetime as 30 days

There is no Email Retention Policy that I can see

Thanks for the help,
John

[phoenix]

There is no Email Retention Policy that I can see

That's the title of the section where you set the lifetime of the retained mail. 0 = never delete and the others are set to 30 days before mail is deleted in those folders.

[alto]

That's the title of the section where you set the lifetime of the retained mail. 0 = never delete and the others are set to 30 days before mail is deleted in those folders.

but with some messages older than 30 days in Junk it's obviously stopped working. The oldest in Junk is dated 27th Jan 08 and last week it was still the 27th.
I might reduce it to 20 or 25 days to see if it makes any difference

Thanks,
John

[alto]

I changed the lifetime to 25 days and the emails are still not deleting out of Junk.
Is there some service I can restart to kick it off again?

[mmorse]

Hi, we use 5.0.2 Network edition moving shortly to 5.0.5 for some bug fixes.

There's the issue, you need to:
zmprov ms server.domain.com zimbraMailPurgeSleepInterval 1m
or just upgrade to 5.0.5
1m is the new default in 5.0.3+, which purges approx 1440 accounts per server per day - though with fewer accounts some prefer a setting of 1h.

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 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 for 5.0.x, 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.

It's exposed in 5.0.3 in the admin console: Bug 24823 - expose zimbraMailPurgeSleepInterval in Admin Console.

Admins can set these attributes via CLI on COS or individual user:
zimbraMailMessageLifetime (default is 0 disabled - careful with this one as it affects mail in any folder)
zimbraMailSpamLifetime (default is 30d)
zimbraMailTrashLifetime (default is 30d)

These as well, though currently not exposed in the user's UI:
zimbraPrefInboxReadLifetime
zimbraPrefInboxUnreadLifetime
zimbraPrefSentLifetime
zimbraPrefJunkLifetime
zimbraPrefTrashLifetime

[alto]

Thanks for the comprehensive answer.
Since we can't find a quiet time to upgrade to 5.0.5 I entered that command zmprov ms server.domain.com zimbraMailPurgeSleepInterval 1m and look forward to seeing what happens