If sieve makes the promise that a a mailbox should contain only the past
seven days' mail, users might reasonably rely on that. If, then, no
mail is delivered in seven days, the mailbox should STILL contain the
past seven days' mail (that is, it should be empty). If expiry happens
as part of delivery, older mail will still be retrievable.
I guess I have no problem per se with having per-folder or per-mailbox
expirations. But sieve operates per-message, not per-folder or per-mailbox.
Supporting per-message expirations is considerably more difficult than
per-folder or per-mailbox, and I doubt if the benefits are worth the cost.
Just to back up a little bit: I've got a similar item on my own
todo/wish list, so I do support a related concept. However I don't
look at it as a sieve agent managing mailbox expirations. Pure mailbox
expirations are, I would agree, more of an external maintenance function.
The thing that I would like to see is more of limiting the volume
of a folder, either in terms of total data size or of number of messages.
So either
fileinto :keep-maximum-messages 100 "somefolder";
or
fileinto :keep-maximum-storage 100k "somefolder";
(or both).
Or how about limits on an entire folder tree? Or limits expressed in terms of
messages with different characteristics? (These are not theoretical -- I've
seen requests for both of these.) The list goes on and on and on.
Like it or not, this is digging deep into the general area of message store
semantics and brings up any number of fairly subtle issues, e.g., are the
criteria met by deleting old messages, deleting the largest messages, holding
new messages, bouncing new messages, etc. etc.
I will again repeat that this is an area that sieve has previously succeeded in
avoiding, and given that we have at least two active working groups (IMAPEXT
and LEMONADE) playing in this general area, plus one inactive one that has
come fairly close to this space (ACAP) I think it is unlikely in the extreme
that sieve work on such things will be uncontroversial. Remember, we made an
intentional choice not to be an IETF working group, and that choice has
consequences, both good and bad.
One comment raised was along the lines of "sieve deals with messages,
not with folders." I would contend that sieve is a language that can
operate inside of many contexts, one of which is local delivery. With
local delivery, the distinction is blurred. I own my incoming mail,
and I own my stored folders, and I want to be able to tell my delivery
agent how to manage both of them and resolve a storage/quota issue in
a reasonably understandable way. This sort of thing (which I think of
as "rolling mailboxes") would be a nice facility for quarantining
incoming messages which, without the facility, one might otherwise
simply delete.
Also, I understand the philosophy that says that this sort of thing
should be an attribute of a folder. However I don't agree that every
operation that you might want to do on a folder should be expressed as
a folder attribute, especially one with magic side effects. There's
really nothing wrong with expressing folder limits as a control over
delivery; the distinction is where and how you express it. Expressing
it inside a delivery script is as much setting a folder/delivery
attribute as is expressing it in some parameter attached to the
folder. BTW I have nothing against either. (This is kind of like the
way that various OSes differ in their treatment of files: in some, one
configures files to behave in a certain way; in others, one writes
programs to treat files in different ways.)
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.
I don't really see why IMAP should drive SIEVE (then again, I'm no
longer talking about "expiration" so this may not be a disagreement.)
SIEVE is a filtering language, IMAP is a folder access protocol.
The reason IMAP should drive sieve in this area is because IMAP is,
in addition to being a protocol, the way we've chosen to capture
a consistent set of message store semantics.
They
are not the same, although I understand that for some, they are
intertwined.
The implementation intertwining of the two is largely irrelevant as far as I'm
concerned. My concern is that this group isn't the right place to define
significant extensions to message store semantics. Even if we do it and do it
right I suspect the IESG won't like it one bit. (I base this assessment on the
LEMONADE chartering experience, where the IESG required explicit language
restricting the group's activities to IMAP and also called for close
coordination with IMAPEXT.)
But I wouldn't use that subset of circumstances as a
driver for SIEVE functionality. (If I'm misunderstanding, I'm happy
to be educated.)
Bottom line: I don't (necessarily) support sieve dictating folder
expiration, but would look forward to a "rolling mailbox" sort of
facility.
Well, as others have previously pointed out, one way to get this sort of
functionality is through the specification of an extension that hooks into
the IMAP ANNOTATE or ANNOTATEMORE extensions. Nothing would prevent someone
from using such an extension in a non-IMAP environment.
Ned