> But regardless of the expiration model, this proposal seems to me to be
> putting the cart before the horse - we'd need to define an IMAP expiration
> extension before it is reasonable to extend sieve to support it. And such a
> sieve extension only makes sense if the model chosen for expirations is
> per-message.
Expiration based on message age is common in voicemail systems. Some
such systems warn users about messages about to expire and allow users
to "renew" messages, so although the expiration interval is typically
per mailbox/folder the expiry process must be driven by a writable
per message property (one of effective date or expiration date).
First, the fact that some (but by no means all) voice mail systems work this
way doesn't make it a good idea for email systems to work this way. My
voicemail is seriously stressed by my having 20 stored messages in it. In
contrast, my email handles more than 2,000,000 stored messages without
incident, and I routinely put more than 20,000 messages in a single folder.
Per-message expirations could easily have a deleterious effect on this sort of
scalability.
Second, even assuming per-message expiries are a good idea doesn't change the
fact that this proposal is being made in the wrong venue. An IMAP extension
needs to be specified first. Only after that is in place does it make sense to
consider whether or not a sieve extension makes sense. And this in turn
breaks down into three cases:
(1) Expiration is done per-folder or per-mailbox. Sieve deals with messages,
not folders or mailboxes, so an extension is inappropriate.
(2) Expiration is done per-message using annotations. A sieve extension
to deal with annotations makes sense in this case; a sieve extension
to deal with expiration specifically does not.
(3) Expiration is done separately from annotations. A sieve extension may
make sense in this case, but the odds of this being the way expirations
get implemented are very, very low.
Ned