Re: Sieve extension to expire mails?

[ned.freed@xxxxxxxxxxx]

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