On Thu, Mar 11, 2004 at 06:42:24AM -0800,
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
Michael Haardt writes:
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).
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. They
are not the same, although I understand that for some, they are
intertwined. 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.
Yours,
-mm-