[Dovecot] Trash expire plugin

[alan premselaar]

-----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:
> 
> 1) 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).
> 
> 2) 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.
> 
> 3) 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-----