Subject: Re: Sieve extension to expire mails?

From: Michael Haardt <[email-masked]>
Date: Thu, 11 Mar 2004 15:01:05 +0100

> Sieve, as a language/protocol, must be held to stricter standards than 
> any single implementation.

I gave an example, where I know that expiry on delivery would be almost
for free, to show that there are alternatives to a regular cleanup job.
That's why I would allow both.

> If sieve makes the promise that a a mailbox should contain only the past 
> seven days' mail, users might reasonably rely on that.

If Sieve makes that promise, yes, but that's not what I was talking about.
I didn't talk about a privacy feature, either, but about a convenience
feature, and that's why I don't have a "privacy/security issue".

The feature I described is: Hey, MDA, you can throw messages in this
folder away after n days.  A great thing for subscribed newsletters.

> FWIW, I also don't like the idea of sieve managing folder properties. 
> That seems to be out of scope for sieve.

That's a point I can understand.  If Sieve focuses only on messages,
then manipulating persistent folder attributes would be simply out
of scope.  Does it focus strictly on messages, not folders, despite
folders containing messages?

If so, how about message attributes to allow expiration to happen?

Michael

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 11 Mar 2004 15:28:38 +0100

Michael Haardt writes:
> If Sieve makes that promise, yes, but that's not what I was talking 
> about. I didn't talk about a privacy feature, either, but about a 
> convenience feature, and that's why I don't have a "privacy/security 
> issue".

It's a privacy/security issue the moment a user misunderstands, and 
relies on the feature.

>>  FWIW, I also don't like the idea of sieve managing folder 
>>  properties. That seems to be out of scope for sieve.
>
> then manipulating persistent folder attributes would be simply out of 
> scope. Does it focus strictly on messages, not folders, despite 

Yes. Sieve ignores folders almost entirely. (Except that fileinto may 
create a folder.)

> If so, how about message attributes to allow expiration to happen?

Much better.

Such attributes are called annotations in IMAPspeak, and they're 
supported by the ANNOTATE extension, which is itself still a draft and 
not terribly widely implemented. If there isn't yet a sieve extension 
to set a message annotation, there certainly should be.

Arnt

---

From: "Guðbjörn S. Hreinsson" <[email-masked]>
Date: Thu, 11 Mar 2004 14:31:48 -0000

> If so, how about message attributes to allow expiration to happen?

Nothing wrong with that. You could maintain messages in the users 
maildir (however you store them) and maintain information about 
thoses messages in a db, like sleepycat for instance. Relatively simple 
and cheap to read that db for messages that need to be expired and 
expire those that are due...

Rgds,
-GSH

---

From: [email-masked]
Date: Thu, 11 Mar 2004 07:04:01 -0800 (PST)

> Yes. Sieve ignores folders almost entirely. (Except that fileinto may

And IMAP's folder-level capabilities are somewhat limited.

> to set a message annotation, there certainly should be.

Yes, a sieve extension to interface with the IMAP ANNOTATE extension makes
sense, assuming of course that IMAP ANNOTATE is approved. But it only makes
sense to use annotations for storying expiry information if it is done
per-message. And even then a separate IMAP extension would need to be defined.

				Ned

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 11 Mar 2004 10:22:46 -0500 (EST)

> per-message. And even then a separate IMAP extension would need to be defined.

I suspect it makes more sense (in general) to ahve a per-folder
(ANNOTATEMORE) entry to perform expiration (Cyrus IMAP provides this now
using a vendor annotation).  I suppose a per-folder annotation could just
be used as a default value for a per-message annotation too, however..

[as we venture off-topic]...

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----