Hello,
let me summarise the recent discussion. I hope this reflects most
views expressed on the topic:
Some mail systems allow the concept of "rolling/automatically expiring"
mailboxes/folders which automatically remove old mail, which is useful
for mailing lists and junk mail folders. It is important that this
function is not performed by the client, because clients usually don't
clean up during vacation.
For that reason, I suggest a Sieve extension, which allows the mail
system to remove mail. There are several ways to address the problem:
Including nailing down the semantics of this as an IMAP extension first,
and once that's done worrying the sieve issues if appropriate.
Note that semantics specified as part of an IMAP extension can be used outside
of IMAP.
Folder Attributes
Sieve focuses on message delivery, so using sieve to control folder
attributes would be using it for a purpose it was not intended for.
Message Attributes
This fits well into Sieve, it allows the richest set of features, but
message expiration attributes are also the most complicated approach.
Further, users might expect expiration dates to be met exactly and
not be pleased about lazy expiration, adding further complexity for
the implementation. IMAP ANNOTATE may be the way to go for message
attributes.
Message removal at delivery
This approach is easy to understand for users and easy to implement: It
keeps removing mail, starting from the oldest, until the given criteria
are matched. It could be realised by adding an option to "fileinto"
and probably "keep":
fileinto :max-days 7 "inbox.mailinglist";
fileinto :max-messages 100 "inbox.mailinglist";
fileinto :max-storage 1M "inbox.mailinglist";
It is still open how the last action should behave when delivering
a 2M message. Perhaps there is a better name instead of "max-".
This mechanism should not be called expiration, because people expect
a different behaviour by that name.
I'm sorry, but these are simply folder-level attributes crammed in at the
message level because that's the mechanism sieve provides. But calling them
message atributes doesn't change their nature.
I'm opposed to all of these approaches and strongly opposed to the last one. If
you want to do this, do it right - specify an IMAP extension and then, if it
makes sense, specify a sieve extension that can be used to control the
mechanism.
Ned