[Dovecot] Trash expire plugin
Timo Sirainen
tss at iki.fi
Thu Jun 8 17:33:17 EEST 2006
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..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20060608/ff80810f/attachment.pgp
More information about the dovecot
mailing list