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..