-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Timo Sirainen wrote:
Dovecot will soon have a plugin which allows running a nightly cronjob to expunge mails from configured mailboxes which have been in there for a configurable amount of time. For example the configuration could be:
plugin { # Trash 7d, Spam 30d expire = Trash 7 Spam 30 }
It also supports using Dovecot's lib-dict to keep track of the mailboxes and their oldest mail's timestamp, so that the nightly cronjob can quickly go through only those mailboxes that have those old mails. Berkeley DB support has been added to lib-dict for this purpose, but you could use SQL as well.
There's however one problem with it that I could use opinions on. Currently there's no way to know how long a mail has been in a mailbox. There are pretty much 3 ways to handle this:
When copying to those Trash/Spam mailboxes the message's INTERNALDATE could be replaced with the current time. That way the INTERNALDATE tells how long the message has been in there. The obvious downside of this is that if the user wants to move the message back to another mailbox, the original INTERNALDATE is lost (INTERNALDATE means the time when the message was received and is often the timestamp used to sort messages).
Preserve the INTERNALDATE while copying, but still use it anyway. Often the messages are moved to Trash (and especially to Spam) soon after they have been received. If not, then the user has time until the next nightly cronjob to move the messages back before they're lost.
Add a new field to index file which contains the date when the message was copied. This could be done only for those Trash/Spam boxes so they don't waste space for other mailboxes. The problem with this is that it won't work if there are no index files. To overcome that problem the time could be stored in yet another place, such as maildir filename and some new mbox header. I don't see supporting those as worth the trouble though, so the fallback could be either the date index file is created or the messages' INTERNALDATE.
I think either 1) or 3) would be best solutions. 3) probably, but if index files don't exist nearly permanently, it's not very reliable..
Timo,
I think #3 is the closet to a good solution. I read through the thread but decided to reply to the original post.
In the case of the mbox backend, when a message is deleted, the actual contents of the message has to be altered to change the status: flag, right? (it's been a long time since i've used mbox, so i could be off base on this) ... what if you (optionally) added an X-Dovecot-Reserved: header to the email with the last relevant date information to use as a backup if the indexes don't exist?
I think the maildir format issues have been pretty well hashed out and using ctime (mtime?) as the fallback would probably be reasonable.
I really like this idea as it could help me help my users manage their quotas by forcing the trashes to be deleted on a regular basis.
my 2yen worth
Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEiLybE2gsBSKjZHQRAu7UAKCgxwUKdKGDj2WvMJZGW6cAj6hD0ACfaj6x VpXJ9LrEa2YI/0gphDKiu7I= =8r0f -----END PGP SIGNATURE-----