Subject: Comments on draft-daboo-sieve-mime-00.txt

From: [email-masked]
Date: Mon, 08 Mar 2004 09:22:25 -0800 (PST)

> FYI - the following is a draft for a new SIEVE operation for testing the
> content of MIME part headers. Comments welcome...

First let me say that I think the scope of this extension is right
on target - a simple mechanism that allows searching through embedded
part and message headers and which provides for simple checks against
media type and content disposition parammters is something we need.

Having said that, I think the specifics of how this was done aren't right.
First, as presently written this specification only extends the header test,
and it does so by creating an entirely new test. But there are two other tests
that are equally applicable to inner headers: exists and address. Either
similar "mimeexists" and "mimeaddress" tests need to be added (and perhaps
"mime" changed to "mimeheader"), or this needs to be done within the existing
tests by adding a :mime parameter. I'm indifferent as to which one of these
approaches is chosen, but we do need one of them.

Second, I really don't like the use of an optional middle parameter to specify
that the test is to be performed on a parameter value. This sort of thing is
why we have labelled parameters: It should be done as :parameter or something
similar. As for the use of a null parameter-names value to indicate a test of
non-paramer material, this can done with :parameter as well, but I do worry
that this is a bit tricky. OTOH, I haven't been able to come up with a
differenent way to do it that I like better.

Third, some references probably needs to be made to RFC 2231 and how to handle
encoded parameters. I think the right answer here is to handle this the same
way we already require that encoded words be handled.

A final implementation note. I threw together an implementation of this the
other day and I've already found it to be very useful. IMO this is an
extension we should try and advance sooner rather than later.

				Ned

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 15 Mar 2004 14:59:36 -0500

Hi Ned,
Thanks for your comments:

--On Monday, March 8, 2004 9:22 AM -0800 [email-masked] wrote:

| Having said that, I think the specifics of how this was done aren't
| right. First, as presently written this specification only extends the
| header test, and it does so by creating an entirely new test. But there
| are two other tests that are equally applicable to inner headers: exists
| and address. Either similar "mimeexists" and "mimeaddress" tests need to
| be added (and perhaps "mime" changed to "mimeheader"), or this needs to
| be done within the existing tests by adding a :mime parameter. I'm
| indifferent as to which one of these approaches is chosen, but we do need
| one of them.
|
| Second, I really don't like the use of an optional middle parameter to
| specify that the test is to be performed on a parameter value. This sort
| of thing is why we have labelled parameters: It should be done as
| :parameter or something similar. As for the use of a null parameter-names
| value to indicate a test of non-paramer material, this can done with
| :parameter as well, but I do worry that this is a bit tricky. OTOH, I
| haven't been able to come up with a differenent way to do it that I like
| better.

OK - here is another solution to the syntax. What I'm proposing is a 
mimeheader test that takes the following parameters:

:name - the name of a specific MIME header to test (can be a list of names)
:parameter-name - the name of a specific parameter name to test (can be a 
list)

:exists - test the existence of the specified items

:text - do comparisons against the content of the entire MIME header 
selected
:value - do comparisons against the value of the MIME header, excluding 
parameters
:parameter-value - do comparisons on parameter values only

In the case of the later three parameters a comparator and text to compare 
against are also required, in the case of :exists, no additional items 
appear.

What I've done below is to enumerate the type of tests one might want to do 
with MIME headers together with new sample syntax for how those would 
appear in a SIEVE script:

1) Test the presence of a specific MIME header:

    if (mimeheader :name "Content-Foo" :exists)

2) Test the presence of a specific parameter in any MIME header:

    if (mimeheader :parameter-name "filename" :exists)

3) Test the presence of a specific parameter in a specific MIME header:

    if (mimeheader :name "Content-Disposition" :parameter-name "filename" 
:exists)

4) Test for text anywhere in a specific MIME header

    if (mimeheader :name "Content-Disposition" :text :contains ".exe")

5) Test for text only in the value (not parameters) in a specific MIME 
header

    if (mimeheader :name "Content-Disposition" :value :contains "attach")

6) Test for text in any parameter values only in a specific MIME header

    if (mimeheader :name "Content-Disposition" :parameter-value :contains 
".exe")

7) Test for text in a specific parameter value only in a specific MIME 
header

    if (mimeheader :name "Content-Disposition" :parameter-name "filename" 
:parameter-value :contains ".exe")

8) Test for text in any MIME header

    if (mimeheader :text :contains ".exe")

9) Test for text only in the value (not parameters) in any MIME header

    if (mimeheader :value :contains "7bit")

10) Test for text in any parameter values only in any MIME header

    if (mimeheader :parameter-value :contains "us-ascii")

11) Test for text in a specific parameter value only in any MIME header

    if (mimeheader :parameter-name "filename" :parameter-value :contains 
".exe")

I think the above deals with the issues you describe, except for the 
'address' test. Arguably there are several different formats for header 
content that one might want to test against, so I wonder whether we need 
this to be extensible in some way. Certainly for the time being we could 
have a 'address [ADDRESS-PART]' parameter in mimeheader as well.

| Third, some references probably needs to be made to RFC 2231 and how to
| handle encoded parameters. I think the right answer here is to handle
| this the same way we already require that encoded words be handled.
|

Is it OK to simply require the concatenation of parameter value 
continuations that have been split according to 2231 syntax? Would you want 
a test to specifically look for the language information?

-- 
Cyrus Daboo

---

From: "Nigel Swinson" <[email-masked]>
Date: Tue, 16 Mar 2004 00:10:30 -0000

I've spent quite a lot of time thinking about this particular extension too and can't wait to implement it, but have never really felt comfortable with a set of syntax, and don't feel comfortable with any of the proposals so far; so here's another to throw into the pool for thought:

I think MIME consists of two significant parts here; there's a set of new headers, and then there's the facility for multiple body parts.  Looking at the list of new headers, most of them seem to fit neatly into our existing tests (Mime-Version, Content-Id, etc), however the only one that has additional significant structure is the Content-Type header, which is defined as:

     content := "Content-Type" ":" type "/" subtype
                *(";" parameter)
                ; Matching of media type and subtype
                ; is ALWAYS case-insensitive.

Then looking more generically we've also got:

     disposition := "Content-Disposition" ":"
                    disposition-type
                    *(";" disposition-parm)

And there's probably others.  So we have this syntax.

     mime-header := header-name ":"
                    header-value
                    *(";" param-name "=" param-value)

So lets provide a tagged argument to the header, exists, address tests that parses out this structure and allows us to select exactly which bits we want to test against:

   Syntax:   header [HEADER-PART] [COMPARATOR] [MATCH-TYPE]
             <header-names: string-list> <key-list: string-list>

    HEADER-PART: ":value" / ":parameter" <param-names: string-list>

- If we specify ":value" as the optional header-part parameter, then the test only operates on the header-value.  
- If we specify the :parameter optional header-part parameter, then the string list describes the list of parameter values that we should search in.  
- If neither optional parameter is specified, the header test operates on the entire header value as normal.
- Other HEADER-PARTS could be defined in the future if we have other headers with a different defined structure.

If we think :value is too confusing for the "header value when with parameters" compared to the "whole header value", then perhaps we could use :valueonly, :noparameters or :mimevalue or something else?  Maybe the prefix could be like a "namespace" defining the header parsing algorithm to use, and if we have other headers that have a common structure, we could define other namespaces that detail the header parsing method to use.

The above would test only in the "active body part" which is the top level body part, which is the email headers, which is what we've all been dealing with already.  It would NOT recursively look for headers in all child body parts.  That would be done with the second half of my proposal.  Where a server doesn't have a mime parser, or was worried about the extra overhead of parsing the mime structure, it wouldn't support this second part, but could still support Header-Parts.

The second significant half of MIME permits us to recursively define body parts, which each have a set of headers, and content.  So any solution that we have needs to cope with the potential recursive nature of the MIME structure.  So what if we define a new tagged argument for use with all of our existing tests that specifies that we should recursively look in the body parts too?  Call it :bodyparts.  So this means that if I write a test that says:

    if header :contains "Content-Type" "text/html"

Then this would only match if the message contains a single body part that is text/html.  However if I write the following, then this would match if there is ANY text/html body part anywhere in the legal MIME structure of the message:

    if header :bodyparts :contains "Content-Type" "text/html"

With our new mimeheader test this would become more correctly:

    if header :bodyparts :value :contains "Content-Type" "text/html"

Then if we combine this with allof(), we could further define that multiple tests within an allof() must apply to the same body part.  So if we say:

    if allof :bodyparts (header :value :contains "Content-Type" "image/jpeg",
                                  size :over 100K)

Then this would catch all messages that contain a image/jpeg body part that is over 100K.  However if we say the following, then this would catch any message that contained a body part that was image/jpeg and a body part (potentially different) which was over 100K in size.:

    if allof (header :bodyparts :value :contains "Content-Type" "image/jpeg",
                size :bodyparts :over 100K)

This then very neatly fits with the body extention, and we get a test like this which would test for all messages that contain a text body part that contains the word "Spam":

    if allof :bodyparts (header :value :contains "Content-Type" "text",
                                  body :contains "Spam")

For more examples, I'll go through Cyrus examples and show how they would look for this proposal.  However before I do, I note that many look for an "in any header value" or an "in any parameter value" concept.  We currently haven't found a need for these, and I'm not sure we need them.  If we do, then I'd propose we have new tests like "anyheader", "anyexists" and a new header-part of ":anyparameter".

Also to strictly "like for like" Cyrus's examples, I have to use my :bodypart parameter on them all, even though that wouldn't be necessary, and to remove it may actually create a better test.

>     if (mimeheader :name "Content-Foo" :exists)

if exists :bodyparts "Content-Foo"

(Reads as: If there is any "Content-Foo" header in any body part)

>     if (mimeheader :parameter-name "filename" :exists)

if anyexists :bodyparts :parameter "filename"

(Reads as: If there is any header in any body part which has a filename parameter)

>     if (mimeheader :name "Content-Disposition" :parameter-name "filename" 

if exists :bodyparts :parameter "filename" "Content-Disposition"

(Reads as: If there is a Content-Disposition header in any body part which has a filename parameter)

>     if (mimeheader :name "Content-Disposition" :text :contains ".exe")

if header :bodyparts :contains "Content-Disposition" ".exe"

(Reads as: If there is a Content-Disposition header in any body part which contains the string ".exe")

>     if (mimeheader :name "Content-Disposition" :value :contains "attach")

if header :bodyparts :value :contains "Content-Disposition" "attach"

(Reads as: If there is a Content-Disposition header in any body part which contains the string "attach" in the value excluding the parameters)

>     if (mimeheader :name "Content-Disposition" :parameter-value :contains 

if header :bodyparts :anyparameter :contains "Content-Disposition" ".exe"
 
(Reads as: If there is a Content-Disposition header in any body part which contains the string ".exe" in any parameter)

> :parameter-value :contains ".exe")

if header :bodypart :contains :parameter "filename" "Content-Disposition" ".exe"

(Reads as: If there is a Content-Disposition header in any body part which contains the string ".exe" in the filename parameter)

>     if (mimeheader :text :contains ".exe")

if anyheader :bodypart :contains ".exe"

(Reads as: If there is any header in any body part which contains the string ".exe")

I'd imagine this to be more useful though:

if anyof :bodyparts (header :anyparameter :contains "Content-Disposition" ".exe",
                                header :anyparameter :contains "Content-Type" ".exe")
 
>     if (mimeheader :value :contains "7bit")

if anyheader :bodyparts :value :contains "7bit"

(Reads as: If there is a header in any body part which contains the string "7bit" in the value not including the parameters)

>     if (mimeheader :parameter-value :contains "us-ascii")

if anyheader :bodyparts :anyparameter :contains "us-ascii"
 
(Reads as: If there is any header in any body part which contains the string "us-ascii" in any parameter)

>     if (mimeheader :parameter-name "filename" :parameter-value :contains 

if anyheader :bodyparts :parameters "filename" :contains ".exe"

(Reads as: If there is any header in any body part which contains the string ".exe" in any "filename" parameter)

What do you think?

Nigel

---

From: [email-masked]
Date: Tue, 16 Mar 2004 19:20:26 -0800 (PST)

> :parameter-value - do comparisons on parameter values only

I really don't care for this at all. Like it or not, sieve opted to define
three tests that act on headers: header/exists/address. Unless there is a very
compelling reason to alter this model - and I've seen no evidence that there is
such a reason - I think we should stick with it. And this argues for either of
the proposals I made previously: mimeheader/mimeexists/mimeaddress or an
additional parameter on the existing tests. NIgel has expressed a preference
for the latter, but I'm happy with either.

Think of it this way: Changing an existing script that employs tests on
the outer header to one that tests all headers in the MIME structure
shouldn't require switching to a completely different sort of test.
A simple addition should be sufficient, and whether that addition is
a test name prefix or a new parameter makes no difference to me.

				Ned

---

From: [email-masked]
Date: Tue, 16 Mar 2004 18:34:42 -0800 (PST)

> I've spent quite a lot of time thinking about this particular extension too
> and can't wait to implement it, but have never really felt comfortable with a
> set of syntax, and don't feel comfortable with any of the proposals so far; so
> here's another to throw into the pool for thought:

I like this proposal. But this is hardly surprising, since it differs only
slightly from some of the alternatives I proposed.

> I think MIME consists of two significant parts here; there's a set of new
> headers, and then there's the facility for multiple body parts.  Looking at the
> list of new headers, most of them seem to fit neatly into our existing tests
> (Mime-Version, Content-Id, etc), however the only one that has additional
> significant structure is the Content-Type header, which is defined as:

> So lets provide a tagged argument to the header, exists, address tests that
> parses out this structure and allows us to select exactly which bits we want
> to test against:

I think this particular extension only belongs on header.

>     HEADER-PART: ":value" / ":parameter" <param-names: string-list>

:parameter is fine but there's a problem with :value - it is already
defined in a different way by RFC 3431. How about :type instead?

> - If we specify the :parameter optional header-part parameter, then the
> string list describes the list of parameter values that we should search in.

Both of these sound good.

> entire header value as normal.

Has to be this way for backwards compatibility.

> with a different defined structure.

Right, but it also seems reasonable that if future attr=value sorts of headers
are defined it will be done with a similar syntax to the ones that already
exist and that the same tests can be brought to bear on them.

> If we think :value is too confusing for the "header value when with
> parameters" compared to the "whole header value", then perhaps we could use
> :valueonly, :noparameters or :mimevalue or something else?

I like :type. It matches up well with "type of disposition" and "media type".

> Maybe the prefix
> could be like a "namespace" defining the header parsing algorithm to use, and
> if we have other headers that have a common structure, we could define other
> namespaces that detail the header parsing method to use.

I think this probably goes too far.

> The above would test only in the "active body part" which is the top level
> body part, which is the email headers, which is what we've all been dealing
> with already.  It would NOT recursively look for headers in all child body
> parts.  That would be done with the second half of my proposal.  Where a server
> doesn't have a mime parser, or was worried about the extra overhead of parsing
> the mime structure, it wouldn't support this second part, but could still
> support Header-Parts.

The notion of two separate extension is interesting. I personally have no need
to make the distinction, but I have no problem with the split if others
think it is useful.

> The second significant half of MIME permits us to recursively define body
> parts, which each have a set of headers, and content.  So any solution that we
> have needs to cope with the potential recursive nature of the MIME structure. 
> So what if we define a new tagged argument for use with all of our existing
> tests that specifies that we should recursively look in the body parts too? 
> Call it :bodyparts.  So this means that if I write a test that says:

> Then this would only match if the message contains a single body part that is
> text/html.  However if I write the following, then this would match if there is
> ANY text/html body part anywhere in the legal MIME structure of the message:

>     if header :bodyparts :contains "Content-Type" "text/html"

Modulo the name of the parameter (which I don't particularly care about)
this is one of the alternatives I proposed.

> For more examples, I'll go through Cyrus examples and show how they would
> look for this proposal.  However before I do, I note that many look for an "in
> any header value" or an "in any parameter value" concept.  We currently haven't
> found a need for these, and I'm not sure we need them.  If we do, then I'd
> propose we have new tests like "anyheader", "anyexists" and a new header-part
> of ":anyparameter".

This all sounds reasonable, but as you say, let's wait for the demand before
we add it.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 17 Mar 2004 14:48:40 -0500

On Tue, Mar 16, 2004 at 12:10:30AM -0000, Nigel Swinson wrote:

   [ alternative mime tests description ]

This all mostly sounds very good.  Some random reflections:

> parameters" compared to the "whole header value", then perhaps we
> could use :valueonly, :noparameters or :mimevalue or something else?
> Maybe the prefix could be like a "namespace" defining the header
> parsing algorithm to use, and if we have other headers that have a
> common structure, we could define other namespaces that detail the
> header parsing method to use.

I too think that ":value" is not the best choice, for various reasons,
some of which have been already stated.  ":type" probably works for
the mime headers but might not be as meaningful if this is later used
to apply to other headers of similar form.  What there really are are
fixed parts and variable keyword=value parts.  This doesn't really
inspire any other good names, though.

> The above would test only in the "active body part" which is the top
> level body part, which is the email headers, which is what we've all
> been dealing with already.  It would NOT recursively look for headers
> in all child body parts.
   ...
> The second significant half of MIME permits us to recursively define
> body parts, which each have a set of headers, and content.  So any
> solution that we have needs to cope with the potential recursive
> nature of the MIME structure.  So what if we define a new tagged
> argument for use with all of our existing tests that specifies that we
> should recursively look in the body parts too?  Call it :bodyparts.
> So this means that if I write a test that says:
> 
> Then this would only match if the message contains a single body part
> that is text/html.  However if I write the following, then this would
> match if there is ANY text/html body part anywhere in the legal MIME
> structure of the message:
> 

Do you intend :bodyparts to select the mime parts in the message body,
or in the entire message (i.e., does it include or exclude the message
header?)  My preference would be the body only, so that one can have
the most flexibility.

> Then if we combine this with allof(), we could further define that
> multiple tests within an allof() must apply to the same body part.  So
> if we say:
> 

Syntactically this is interesting, although as I've said before I think
a full-fledged notion of "views" would be more so (but obviously that's a
whole nother track).  I wonder how various implementors feel about
connecting "allof" with its contained tests in this way -- especially
if they are allowed to nest.

> if header :bodyparts :anyparameter :contains "Content-Disposition" ".exe"

Rather than introduce another keyword, I'd suggest using a special
parameter value string to match any actual parameter.  e.g.:

    if header :bodyparts :parameter "" :contains "Content-Disposition" ".exe"
or
    if header :bodyparts :parameter "*" :contains "Content-Disposition" ".exe"

Perhaps even say that the ":parameter" value is tested using a wildcard
match (a la :matches).

> What do you think?

Very nice..

mm

---

From: "Nigel Swinson" <[email-masked]>
Date: Wed, 17 Mar 2004 21:54:45 -0000

> This all mostly sounds very good.  Some random reflections:

Thanks Mark :o)

> some of which have been already stated.  

To be honest I'm not a fan of :value either, so am more than happy for an alternative.

> ":type" probably works for

I don't mind :type but I'm wondering if :noparameters is best, as this pairs neatly with :parameters <string-list>?  

> header?)  My preference would be the body only, so that one can have

I had intended it to be the entire message, but not out of strong desire.  I guess if I was writing a test, I would care less about where in the email message the entity of interest was and more about it's prescense.  With our header test we aren't told about where in the headers the header is, and if you have a multipart/alternative structure or multipart/mixed then I'm not sure there is a logical distinction in the order.  So I think to neatly be able to say "is there any text/html body part in this email" is more useful than saying "is there a text/html body part in one of the child body parts?"

Were we to really need to know if the text/html body part was not the "root" body part, then we could use an allof test:

if allof (header :bodyparts :noparameters :contains "Content" "text/html",
          not header :noparameters :contains "Content" "text/html")

> if they are allowed to nest.

Originally I thought we should have a concept of "selection" of a body part and then be able to perform tests on it.  Couldn't get anywhere with the idea though, as I just thought it would end up in a hell of indexes into arrays of body parts, and also how would you "select" a body part?

>     if header :bodyparts :parameter "*" :contains "Content-Disposition" ".exe"

Good ideas :o)  As I said, I'm not sure a concept of "anyparameter" or "anyheader" is particularly core to this extension so would think we'd have to justify it's usefulness before deciding to add it to the extension.  Certainly anyheader probably shouldn't be in a mime extension, but anyparameter might be.
 
> Perhaps even say that the ":parameter" value is tested using a wildcard

We haven't seen the facility for using wildcards on header names, so I'm not sure we need it for parameter names either as I think the two concepts are very similair...

Nigel

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 17 Mar 2004 17:33:31 -0500

> I had intended it to be the entire message, but not out of strong
> desire.  I guess if I was writing a test, I would care less about
> where in the email message the entity of interest was and more about
> it's prescense.  With our header test we aren't told about where in
> the headers the header is, and if you have a multipart/alternative
> structure or multipart/mixed then I'm not sure there is a logical
> distinction in the order.  So I think to neatly be able to say "is
> there any text/html body part in this email" is more useful than
> saying "is there a text/html body part in one of the child body parts?"

I tend to coss the toin in the direction of more options.  As you say,
it's hard to predict why one would want to exclude the message header,
however one can't always predict these sorts of things.  There's a
tradeoff: on one hand having :bodypart exclude the message header gives
more options, but on the other, one would have to use more SIEVE code
in the overwhelmingly common case.

> Originally I thought we should have a concept of "selection" of a
> body part and then be able to perform tests on it.  Couldn't get
> anywhere with the idea though, as I just thought it would end up in a
> hell of indexes into arrays of body parts, and also how would you
> "select" a body part?

I would like to see a mechanism for creating views (by whatever term)
that would have applicability for a number of sieve functions; were
this available, it could be used in conjunction with the mime
extension.  That's yet another conundrum tho: practically speaking, I
wouldn't want to hold up the mime extension for that, yet if the mime
extension includes its own selection facility, it could collide with a
future views capability.  (Not that I expect 'views' to have wide
support.)

> We haven't seen the facility for using wildcards on header names, so
> I'm not sure we need it for parameter names either as I think the two
> concepts are very similair...

I've actually had people ask for that- and have had occasion to
wish for it myself.  

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 17 Mar 2004 17:33:31 -0500
To: Nigel Swinson <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, Cyrus Daboo <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Comments on draft-daboo-sieve-mime-00.txt
Sender: [email-masked]

> I had intended it to be the entire message, but not out of strong
> desire.  I guess if I was writing a test, I would care less about
> where in the email message the entity of interest was and more about
> it's prescense.  With our header test we aren't told about where in
> the headers the header is, and if you have a multipart/alternative
> structure or multipart/mixed then I'm not sure there is a logical
> distinction in the order.  So I think to neatly be able to say "is
> there any text/html body part in this email" is more useful than
> saying "is there a text/html body part in one of the child body parts?"

I tend to coss the toin in the direction of more options.  As you say,
it's hard to predict why one would want to exclude the message header,
however one can't always predict these sorts of things.  There's a
tradeoff: on one hand having :bodypart exclude the message header gives
more options, but on the other, one would have to use more SIEVE code
in the overwhelmingly common case.

> Originally I thought we should have a concept of "selection" of a
> body part and then be able to perform tests on it.  Couldn't get
> anywhere with the idea though, as I just thought it would end up in a
> hell of indexes into arrays of body parts, and also how would you
> "select" a body part?

I would like to see a mechanism for creating views (by whatever term)
that would have applicability for a number of sieve functions; were
this available, it could be used in conjunction with the mime
extension.  That's yet another conundrum tho: practically speaking, I
wouldn't want to hold up the mime extension for that, yet if the mime
extension includes its own selection facility, it could collide with a
future views capability.  (Not that I expect 'views' to have wide
support.)

> We haven't seen the facility for using wildcards on header names, so
> I'm not sure we need it for parameter names either as I think the two
> concepts are very similair...

I've actually had people ask for that- and have had occasion to
wish for it myself.  

mm

From: "Nigel Swinson" <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: "Cyrus Daboo" <[email-masked]>, "IETF MTA Filters List" <[email-masked]>
Subject: Re: Comments on draft-daboo-sieve-mime-00.txt
Date: Wed, 17 Mar 2004 21:54:45 -0000
Sender: [email-masked]

Thanks Mark :o)

 

Nigel

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 17 Mar 2004 15:52:28 -0500
To: Cyrus Daboo <[email-masked]>
Cc: Michael Haardt <[email-masked]>, [email-masked]
Subject: Re: Expiring/deleting old mail
Sender: [email-masked]

On Tue, Mar 16, 2004 at 12:11:03PM -0500, Cyrus Daboo wrote:
> Hi Michael,
> 
> --On Tuesday, March 16, 2004 2:22 PM +0100 Michael Haardt 
> <[email-masked]> wrote:
> 
> | 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:
> 
> I'm afraid I still think expiration like this belongs in the mailstore not 
> the delivery agent.

Unfortunately I can see both perspectives :-)

I do understand yours, or at least I think I do.  You want to have
mailstore attributes that control this particular combination of mail
folder operations.

The other one is that the agent acts just like I do, only I'm not
sitting at the keyboard.  I can sit down at my computer and access a
folder and make sure I have less than 100 messages in it when I
leave.  I do this using existing primitive access functions.
Similarly, I could tell my sieve-enabled LDA to follow this same
methodology.  The issue of "what if some other access access doesn't
do this" is a red herring.  I can manually open up the folder using a
mail client and treat the folder in a different way... so?  It's the
same thing: it's me doing the access whether I've told an agent to do
it, whether I access using my keyboard, or whether I told another
agent to do something else.  If I do conflicting things it's my
choice, and it may or may not be an error.  I don't think I need an
IMAP extension to allow primitive operations to be combined in these
ways.

Personally I wouldn't want to use a system that required me to
configure my folders for each kind of access I wanted to do, or each
way that I wanted to use them.  Nor would I want to use mail folders
that had side-effects when I accessed them.  I can respect that others
might want this, though-- it's just not my mindset.

I can also respect an opinion that SIEVE only operates on a single
message, and yeah, I see that point.  But if SIEVE is the filtering
language in my LDA of choice (and it is), and I would like to have
some interaction with an existing mailstore (and I do), some level of
access to an existing store is not really out of place.

Anyway, I'm not trying to repeat myself here, just providing what
I hope is a little more light.  I doubt anyone who has the other
perspective will be convinced, though.

Yours,
-mm-

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 17 Mar 2004 14:48:40 -0500
To: Nigel Swinson <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Comments on draft-daboo-sieve-mime-00.txt
Sender: [email-masked]

   ...

Very nice..

mm

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "Michael Haardt" <[email-masked]>
Subject: Re: Expiring/deleting old mail
Date: Wed, 17 Mar 2004 10:38:03 -0500
Organization: Santronics Software, Inc
Sender: [email-masked]

Maybe these can offer some insight. These are our mail server mail policy
attributes (per conference AKA folder).  Our mail server automatically
maintains the mail once per day between 1am and 5am (adjustable).

o Maximum Messages:
o Message Number to Trigger Renumber:
o Days to Keep Read Private Mail:
o Days to Keep Unread Private or Public Mail:
o Days to keep external user mail : (outgoing mail created by your users).
o Delete external user mail once delivered by SMTP:

Other folder/user profile group based options  that can have an effect on
the mail tracking/maintance.

o Allow Mail Previewing (Non-POP3 devices)
o Mark downloaded (POP3) Mail as Received:  Yes/No

In general, users have no say in our product mail policy design.  POP3/WEB
mail access has changed that over the years with users now having some
"leave on server" options in their MUA to help them with roaming.   However,
tracking, mail maintenance, mail receipt request, etc (Subscribers can't
claim they didn't get an expiration notice) is still important so our design
compromise was to have two Receive bits. One that is always recorded for
internal purposes and one that is used for the user.  This allows them to
Preview mail on lets say the Web without marking it read, and then via MUA
download the mail with direct mail
pointers retrieving the "unread user mail."    Same idea with the MUA
(POP3), option to not mark receive allows them to roam to around to other
machines.   However, the internal received bit still prevails for the normal
mail packing/maintenance options (Days to Key UnRead/Read Private Mail
options).   Users have no say on how long mail stays in storage, unless of
course, it is shorter than the server limits, in which case,  the MUA can
delete the message.

I guess my point with the note, that whole concept present a very difficult
PR/system policy issue where MUA clients were demanding new behaviors
conflict with some of the product's traditional strong mail security,
tracking and maintenance policies.  The #1 being subscription notices could
not be bypass with user's previews or non-marking downloads, and the 2nd was
the increase mail storage requirements in large systems because the triggers
were being bypassed.

Hope this provide some engineering insights.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message ----- 
From: "Michael Haardt" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 16, 2004 8:22 AM
Subject: Expiring/deleting old mail

>
> 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:
>
> 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.
>
> Michael
>
>

Date: Wed, 17 Mar 2004 09:53:06 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: Michael Haardt <[email-masked]>, [email-masked]
Subject: Re: Expiring/deleting old mail
Sender: [email-masked]

On Wed, 17 Mar 2004 [email-masked] wrote:

> > Though I also agree that the sanest way to do this is just with a
> > folder-wide attribute in IMAP, and leave sieve out of it.
>
> In other words, there are two fairly different models for how to handle
> expirations in a message store, and we need to pick the one that makes the most
> sense. Doesn't this sound like something store implementors might want to have
> a wee bit of say in?

Yes -- I agree that sieve is not the place to do this.  Certainly not at
first, anyway.

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

Date: Wed, 17 Mar 2004 06:48:16 -0800 (PST)
From: [email-masked]
Subject: Re: Expiring/deleting old mail
To: Rob Siemborski <[email-masked]>
Cc: [email-masked], Michael Haardt <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Tue, 16 Mar 2004 [email-masked] wrote:

> > 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 agree on the last one -- but message annotations can also be "this
> message expires on date xyz" which is not necessaraly related to when the
> next message in the mailbox expires.

Of course they can, but this is just the per-message way of doing it,
rather than the per-folder way.

> Though I also agree that the sanest way to do this is just with a
> folder-wide attribute in IMAP, and leave sieve out of it.

In other words, there are two fairly different models for how to handle
expirations in a message store, and we need to pick the one that makes the most
sense. Doesn't this sound like something store implementors might want to have
a wee bit of say in?

				Ned

Date: Wed, 17 Mar 2004 09:19:19 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Michael Haardt <[email-masked]>
cc: [email-masked]
Subject: Re: Expiring/deleting old mail
Sender: [email-masked]

On Wed, 17 Mar 2004, Michael Haardt wrote:

> That makes sense for folder or message attributes.  I don't want
> any attributes, because I do not like their overhead.  To answer the
> previous asked question of conflicting actions: There are no conflicts.
> "max-days 7" followed by a "max-days 6" leaves the last six days mail
> in the folder.

This seems like a very fast way for script authors to shoot themselves in
the foot.

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

Date: Wed, 17 Mar 2004 09:17:52 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: Michael Haardt <[email-masked]>, [email-masked]
Subject: Re: Expiring/deleting old mail
Sender: [email-masked]

On Tue, 16 Mar 2004 [email-masked] wrote:

> 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 agree on the last one -- but message annotations can also be "this
message expires on date xyz" which is not necessaraly related to when the
next message in the mailbox expires.

Though I also agree that the sanest way to do this is just with a
folder-wide attribute in IMAP, and leave sieve out of it.

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

To: [email-masked]
Subject: Re: Expiring/deleting old mail
From: Michael Haardt <[email-masked]>
Date: Wed, 17 Mar 2004 12:11:18 +0100
Sender: [email-masked]

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

This last approach does not add message or folder flags in any way.
The previous one did.  This is a modified action, which first cleans up
the folder and then delivers a message to it.

I could imagine to move that functionality into a new action (cleanup?),
but until I see where it could be useful apart from a following fileinto,
I talk about it as fileinto extension.

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

That makes sense for folder or message attributes.  I don't want
any attributes, because I do not like their overhead.  To answer the
previous asked question of conflicting actions: There are no conflicts.
"max-days 7" followed by a "max-days 6" leaves the last six days mail
in the folder.

Michael

Date: Tue, 16 Mar 2004 19:20:26 -0800 (PST)
From: [email-masked]
Subject: Re: Comments on draft-daboo-sieve-mime-00.txt
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], IETF MTA Filters List <[email-masked]>
Sender: [email-masked]

				Ned

Date: Tue, 16 Mar 2004 18:34:42 -0800 (PST)
From: [email-masked]
Subject: Re: Comments on draft-daboo-sieve-mime-00.txt
To: Nigel Swinson <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IETF MTA Filters List <[email-masked]>
Sender: [email-masked]

				Ned

Date: Tue, 16 Mar 2004 17:12:04 -0800 (PST)
From: [email-masked]
Subject: Re: Expiring/deleting old mail
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 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

Date: Tue, 16 Mar 2004 12:11:03 -0500
From: Cyrus Daboo <[email-masked]>
To: Michael Haardt <[email-masked]>, [email-masked]
Subject: Re: Expiring/deleting old mail
Sender: [email-masked]

Hi Michael,

--On Tuesday, March 16, 2004 2:22 PM +0100 Michael Haardt 
<[email-masked]> wrote:

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

I'm afraid I still think expiration like this belongs in the mailstore not 
the delivery agent. There are other ways for messages to be delivered into 
mailboxes other than sieve and expiration policy for those is just as 
relevant as it is for mailboxes with sieve delivery occurring. e.g. 
Mailboxes that are targets of IMAP COPY and APPEND commands should be able 
to have expiration behaviour as you describe.

So I think the right approach is to define an IMAP extension for setting 
expiration policies on mailboxes, utilizing ANNOTEMORE for controlling the 
per-mailbox settings. The expiration test/action would be triggered by any 
action that could change the mailbox (COPY, APPEND, SELECT and external 
delivery) or, if a server chooses to implement it, an automated timed 
expiry check at an interval specified by the user or dictated by the system.

Note that one could be quite sophisticated about the expiry checks - e.g. 
IMAP SEARCH criteria could be used in the annotation to specify which 
messages are to be expired - so I could setup criteria to exclude messages 
that have the important (\Flagged) flag set etc.

-- 
Cyrus Daboo

Date: Tue, 16 Mar 2004 11:46:09 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Michael Haardt <[email-masked]>
cc: [email-masked]
Subject: Re: Expiring/deleting old mail
Sender: [email-masked]

On Tue, 16 Mar 2004, Michael Haardt wrote:

>   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'd say that discussion is also needed about how to treat multiple,
conflicting, fileinto commands.

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

To: [email-masked]
Subject: Expiring/deleting old mail
From: Michael Haardt <[email-masked]>
Date: Tue, 16 Mar 2004 14:22:36 +0100
Sender: [email-masked]

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:

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.

Michael

From: "Nigel Swinson" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>
Cc: "IETF MTA Filters List" <[email-masked]>
Subject: Re: Comments on draft-daboo-sieve-mime-00.txt
Date: Tue, 16 Mar 2004 00:10:30 -0000
Sender: [email-masked]

 

 

 

What do you think?

Nigel

Date: Mon, 15 Mar 2004 14:59:36 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
cc: IETF MTA Filters List <[email-masked]>
Subject: Re: Comments on draft-daboo-sieve-mime-00.txt
Sender: [email-masked]

Hi Ned,

-- 
Cyrus Daboo

Date: Sat, 13 Mar 2004 20:37:59 -0800 (PST)
From: [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h - Request for feedback on Open Issues.
To: "Matthew Elvey (FM)" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> First of all, thanks to all for all the feedback so far.

> Alexey and I didn't receive any feedback on Section 13 'Open Issues for
> Discussion', items 2 or 3, so I'm sending this email to
> ask folks (who may have missed it because it was at the end after the
> boring boilerplate) to comment.

I note in passing that item 2 only appears in the -01 revision on your
web site - people looking at the -00 revision in the I-D directory
may be confused when they only find two open issues, not three.

Regarding item 2 -

   2) Should the following text be added to the draft? (Section 4.? ?)
   
   Systems that support the extension must encourage use (by their
   users) of "refuse" over "discard" and "reject" where it is an
   appropriate alternative.

I'm not entirely sure what it means to "encourage use", but I guess it could
refer to offering refuse actions preferentially in a GUI or something similar.
If so, I regard this as a somewhat dangerous promotion of nonportable scripts,
since refuse as presently constituted is an MTA-only sort of thing.

The real problem here has nothing to do with sieve and everything to do with
the architecture of email itself: For a variety of reasons the most effective
way to deal with spam is to reject it at the SMTP level prior to final
delivery, but an MUA by definition operates after that point. So even if
you "fix" the portability "problem" you do not and cannot get the desired
behavior on an MUA.

The logical direction this leads is that sieves are best run on MTAs just
before or during final delivery. But do we really want to say this? Perhaps
it would make sense to say it in a BCP talking about spam filtering best
practices, but not, I think, in a technical specification of a sieve
extension.

And regarding item 3 -

   3) Explicitly supporting Enhanced Error Codes (RFC 2034).
   
The suggested text talking about how to generate an appropriate enhanced error
code is definitely appropriate and should IMO be included in the document. The
broader question of whether or not it is appropriate to give users control over
what code is inserted is the interesting one here. After thinking about this
I've concluded that the benefits just don't outweigh the risks - there really
aren't that many other codes that would be appropriate to use with refuse. If
this were to be supported at all there would have to be a list of the codes a
user is allowed to specify, and anything else would be ignored.

This is a shame, because there are a few other codes that make some amount of
sense, e.g. 5.2.3, "message length exceeds administrative limit". There are
even some 4.x.y codes that make sense, e.g. 4.4.4, "unable to route", when,
say, a presence check fails and an urgent message needs to be returned
immediately. (Note that this last case is one where a 5xy 4.a.b sort of
response indicating "message returned due to a transient problem" may be
appropriate - one of the things done in the revision of the NOTARY document when
they moved to draft was to make it clear such combinations are allowed.)

				Ned

Date: Sat, 13 Mar 2004 18:44:22 -0800
From: "Matthew Elvey (FM)" <[email-masked]>
Cc: [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h - Request for feedback on Open Issues.
Sender: [email-masked]

First of all, thanks to all for all the feedback so far.

Alexey and I didn't receive any feedback on Section 13 'Open Issues for 
Discussion', items 2 or 3, so I'm sending this email to
ask folks (who may have missed it because it was at the end after the 
boring boilerplate) to comment.

We'll have a new draft out shortly (It's just waiting for any changes 
this post my lead to.)

On 2/12/2004 11:59 AM, Matthew Elvey (FM) sent forth electrons to convey:

>
> Hello, folks.  Please review and provide feedback on the "refuse" 
> extension, designed to mostly replace Sieve's "reject" command.
>
> ... please review and comment on what's at
> <http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt>
>
> We welcome feedback, particularly
>  -   changes that include replacement text or
>  -   suggestions from Sieve implementers.
>
> ...
>
> -Matthew & Alexey
>

Date: Fri, 12 Mar 2004 16:04:41 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve extension to expire mails?
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked], "Mark E. Mallett" <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Fri, Mar 12, 2004 at 03:13:51PM -0800, [email-masked] wrote:

> > Sure it does. Folders normally retain messages until they are deleted.
> > This changes that semantics rather completely, don't you think?

> I don't think so, and that's an opinion that I was trying to convey.
> Perhaps there's a distinction centering around "deleted by whom?"

Yes, and it is a very significant one. If I have a specialized client that
prowls through some set of folders and deletes things based on some criteria or
other, its operational parameters are by definition a client concern.  Clients
the semantics and so the issue of consistent semantics for store-based deletion
doesn't arise.

If, on the other hand, a store implements some sort of message expiration
system, it almost certainly will be provided to multiple users who will  want
to use multiple clients to control and manipulate the facility on multiple
servers. Failure to nail down the semantics properly is likely to lead to
problems -- messages won't be deleted when they should have been, and worse,
messages might be deleted when they should not have been. One of the reasons we
have standards is to try and prevent this sort of thing from happening.

It is entirely reasonable to talk about using sieve to control either
a client or server side expiration facility. But a client side facility
would logically be controlled through the use of private headers or
annotations or something similar. The only thing that would need to
be standardized in this case is the means to add headers or annotations
or whatever in sieve.

A server side facility, on the other hand, needs to have the server
side semantics nailed down first. I have alredy explained why I believe
this is the case in considerable detail.

> My
> attitude is that the owner of a mailbox could legitimately instruct a
> delivery agent to manipulate that mailbox as part of delivery.  One of
> those instructions could be "delete the oldest message [under some
> condition]".  I see no philosophical difference between that
> instruction and manually hitting the 'd' key.  This introduces no new
> storage semantics nor any new operational semantics.  It does wrap up
> a few primitive operations into a higher level function, but that
> doesn't make those operations new.  (Making them more granular would
> actually be to my liking.)

> Just me, I guess?

It certainly is not a view I share, nor is it a view that I feel is
likely to lead to a successful sieve extension. Again, I have
explained why I think this is the case.

				Ned

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 12 Mar 2004 18:49:55 -0500
To: [email-masked]
Cc: "Mark E. Mallett" <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

On Fri, Mar 12, 2004 at 03:13:51PM -0800, [email-masked] wrote:

> Sure it does. Folders normally retain messages until they are deleted.
> This changes that semantics rather completely, don't you think?

I don't think so, and that's an opinion that I was trying to convey.
Perhaps there's a distinction centering around "deleted by whom?"  My
attitude is that the owner of a mailbox could legitimately instruct a
delivery agent to manipulate that mailbox as part of delivery.  One of
those instructions could be "delete the oldest message [under some
condition]".  I see no philosophical difference between that
instruction and manually hitting the 'd' key.  This introduces no new
storage semantics nor any new operational semantics.  It does wrap up
a few primitive operations into a higher level function, but that
doesn't make those operations new.  (Making them more granular would
actually be to my liking.)

Just me, I guess?

-mm-

Date: Fri, 12 Mar 2004 15:13:51 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve extension to expire mails?
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked], "Mark E. Mallett" <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Thu, Mar 11, 2004 at 05:34:36PM -0800, [email-masked] wrote:
> >
> > >     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.

> One can always theorize extreme tangents for any discussion.

But these weren't extremes. They are both quite reasonable requests.

> Even so,
> it could be useful to have fundamental access to operations on
> existing mailstore when storing a new message.

Again, it depends on how those operations are organized. And the way to make
sure they are properly organized is to work out the semantics in a venue
appropriate for mail store semantic discussions. This isn't that venue.

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

> Obviously we disagree, because (re "like it or not") I do
> like it :-)  In the case of a rolling mailbox, the issues are not
> subtle.  One has a sliding window of the mailbox, where old
> messages are dropped to make room for new ones.  This is really
> not an outlandish idea, nor does it introduce any new folder
> semantics.

Sure it does. Folders normally retain messages until they are deleted.
This changes that semantics rather completely, don't you think?

				Ned

Date: Fri, 12 Mar 2004 17:16:59 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

On Fri, 12 Mar 2004, Mark E. Mallett wrote:

> > > That does look like that is what that script would do, and no, it's
> > > probably not useful.  I would call that a bad script.
> >
> > Well-defined syntax shouldn't let you write a "bad script".
>
> I would have to flat-out disagree with that.  But that's a whole
> nother conversation.

Semantics.  It's a syntacticly correct script that even has a valid
interpretation, which is logical, even if its not necessaraly what the
user would expect.  That does not at all make it a "bad script", as you
say.

> On a related note: do people who will be confused by languages write
> scripts by hand, anyway?

Its possible to write code in any language that is confusing, the point is
to minimize the confusion.  Even experienced users might not see what is
going on in a script that is a thousand lines long, with fileintos
into the same mailbox separated by a few hundred lines.

> I imagine that those people use some interface that generates scripts
> for them, and "power users" will write scripts by hand.  Neither of
> these groups should object to having powerful underlying facilities.

But they might object to the language making it easy to make mistakes.

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

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 12 Mar 2004 17:12:19 -0500
To: Rob Siemborski <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

> > That does look like that is what that script would do, and no, it's
> > probably not useful.  I would call that a bad script.
> 
> Well-defined syntax shouldn't let you write a "bad script".

I would have to flat-out disagree with that.  But that's a whole
nother conversation.

>  I'd argue
> that this particular addition to sieve is likely to be extraordinarly
> confusing to users.  If I have 10 places in a script where I can file into
> a particular mailbox, I shouldn't need to remember that in each of those
> places I need to set the *same* max storage limit.

I can sympathize with those comments even if I don't necessarily have
the same perspective as you.  Mine is to give the power to the script
writer, not protect them from that power.  On a related note: do people
who will be confused by languages write scripts by hand, anyway?  I
imagine that those people use some interface that generates scripts
for them, and "power users" will write scripts by hand.  Neither of
these groups should object to having powerful underlying facilities.

BTW I am not pushing this as a proposal; note that I am commenting in
a thread started by someone else.  But I do believe it is a good idea
that could either be implemented as-is or incorporated into a more
complete extension somewhere down the line.

Yours,
-mm-

Date: Fri, 12 Mar 2004 16:50:56 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

I suppose that's what I get for hitting the send key at the wrong time...

Let's try this again.

On Fri, 12 Mar 2004, Mark E. Mallett wrote:

>
> On Fri, Mar 12, 2004 at 12:11:19AM -0500, Rob Siemborski wrote:
> > In addition to Ned's comments (which I tend to agree with), does
> > implementing this sort of folder semantic on a per-message basis even
> > make any sense?
> >
> > Let's presume the script:
> >
> > if envelope :all :contains "to" "rjs3+a@" {
> >         fileinto "INBOX.foo";
> > } elsif envelope :all :contains "to" "rjs3+b@" {
> >         fileinto :keep-maximum-storage 100k "INBOX.foo";
> > }
> >
> > Does this mean the script only enforces the limit when an "rjs3+b" message
> > arrives?  If so, is that even useful?
>
> That does look like that is what that script would do, and no, it's
> probably not useful.  I would call that a bad script.

Well-defined syntax shouldn't let you write a "bad script".  I'd argue
that this particular addition to sieve is likely to be extraordinarly
confusing to users.  If I have 10 places in a script where I can file into
a particular mailbox, I shouldn't need to remember that in each of those
places I need to set the *same* max storage limit.

> There's always a conflict between exposing and encapsulating language
> facilities.  For example, the original poster had the notion of adding
> a folder definition that would ensure that all operations into that
> folder would operate the same way.  I wouldn't want that: I generally
> go for the low-level granularity that lets the script writer have
> complete control (and responsibility for their own errors).

If such an overriding defaults system existed, this problem wouldn't
exist.  You could even have both a default value, *and* allow people to
override it.

Though, in the end, I think this is something best left as a folder
attribute.

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

Date: Fri, 12 Mar 2004 16:48:16 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

On Fri, 12 Mar 2004, Mark E. Mallett wrote:

> On Fri, Mar 12, 2004 at 12:11:19AM -0500, Rob Siemborski wrote:
> > In addition to Ned's comments (which I tend to agree with), does
> > implementing this sort of folder semantic on a per-message basis even
> > make any sense?
> >
> > Let's presume the script:
> >
> > if envelope :all :contains "to" "rjs3+a@" {
> >         fileinto "INBOX.foo";
> > } elsif envelope :all :contains "to" "rjs3+b@" {
> >         fileinto :keep-maximum-storage 100k "INBOX.foo";
> > }
> >
> > Does this mean the script only enforces the limit when an "rjs3+b" message
> > arrives?  If so, is that even useful?
>
> That does look like that is what that script would do, and no, it's
> probably not useful.  I would call that a bad script.

Well-defined syntax shouldn't let you write a "bad script".

> When one
> provides facilities in a language, one is not personally expected to
> debug every script that can be written in it.

> There's always a conflict between exposing and encapsulating language
> facilities.  For example, the original poster had the notion of adding
> a folder definition that would ensure that all operations into that
> folder would operate the same way.  I wouldn't want that: I generally
> go for the low-level granularity that lets the script writer have
> complete control (and responsibility for their own errors).
>
> (In my own implementation I have other ways of dealing with that
> conflict anyway.)
>
> mm
>
>
>

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

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 12 Mar 2004 15:41:03 -0500
To: Rob Siemborski <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

On Fri, Mar 12, 2004 at 12:11:19AM -0500, Rob Siemborski wrote:
> In addition to Ned's comments (which I tend to agree with), does
> implementing this sort of folder semantic on a per-message basis even
> make any sense?
> 
> Let's presume the script:
> 
> if envelope :all :contains "to" "rjs3+a@" {
>         fileinto "INBOX.foo";
> } elsif envelope :all :contains "to" "rjs3+b@" {
>         fileinto :keep-maximum-storage 100k "INBOX.foo";
> }
> 
> Does this mean the script only enforces the limit when an "rjs3+b" message
> arrives?  If so, is that even useful?

That does look like that is what that script would do, and no, it's
probably not useful.  I would call that a bad script.  When one
provides facilities in a language, one is not personally expected to
debug every script that can be written in it.

There's always a conflict between exposing and encapsulating language
facilities.  For example, the original poster had the notion of adding
a folder definition that would ensure that all operations into that
folder would operate the same way.  I wouldn't want that: I generally
go for the low-level granularity that lets the script writer have
complete control (and responsibility for their own errors).

(In my own implementation I have other ways of dealing with that
conflict anyway.)

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 12 Mar 2004 15:31:42 -0500
To: [email-masked]
Cc: "Mark E. Mallett" <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

On Thu, Mar 11, 2004 at 05:34:36PM -0800, [email-masked] wrote:
> 
> >     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.

One can always theorize extreme tangents for any discussion.  Even so,
it could be useful to have fundamental access to operations on
existing mailstore when storing a new message.

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

Obviously we disagree, because (re "like it or not") I do
like it :-)  In the case of a rolling mailbox, the issues are not
subtle.  One has a sliding window of the mailbox, where old
messages are dropped to make room for new ones.  This is really
not an outlandish idea, nor does it introduce any new folder
semantics.  If it sparks other ideas or other ways to access mail
folders, so much the better-- any way to give owner of a mailstore
a little more control at delivery time.  That's one of the things
SIEVE is for.

mm

Date: Fri, 12 Mar 2004 10:55:20 +0100
From: =?ISO-8859-1?B?RGF2aWQgU+FuY2hleiBQ6XJleg==?= <[email-masked]>
To: Sieve list <[email-masked]>
Subject: Sieve to Maildrop
Sender: [email-masked]

Hello
I'd like to know if there is a tool for translating Sieve to Maildrop.

              Thanks
                 DvD

P.D.: Sorry my bad english

Date: Fri, 12 Mar 2004 00:11:19 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

On Thu, 11 Mar 2004, Mark E. Mallett wrote:

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

In addition to Ned's comments (which I tend to agree with), does
implementing this sort of folder semantic on a per-message basis even
make any sense?

Let's presume the script:

if envelope :all :contains "to" "rjs3+a@" {
        fileinto "INBOX.foo";
} elsif envelope :all :contains "to" "rjs3+b@" {
        fileinto :keep-maximum-storage 100k "INBOX.foo";
}

Does this mean the script only enforces the limit when an "rjs3+b" message
arrives?  If so, is that even useful?

Its entirely unclear to me that folder-wide attributes are useful to
employ in a sieve script.  Per-message expiration dates (and even generic
annotation-setting) seems fine, but folder-wide attributes just don't seem
like a good fit.

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

Date: Thu, 11 Mar 2004 17:34:36 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve extension to expire mails?
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 11 Mar 2004 18:37:35 -0500
To: [email-masked]
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

On Thu, Mar 11, 2004 at 06:42:24AM -0800, [email-masked] 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-

Date: Thu, 11 Mar 2004 09:06:31 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve extension to expire mails?
To: Rob Siemborski <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Thu, 11 Mar 2004 [email-masked] wrote:

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

> There's nothing that says we need an IMAP extension for expiration before
> defining a sieve extension for expiration.  Sieve can work in enviornments
> other than IMAP.

Perhaps, but if we decide on this course it will be the first time we've
created an action in sieve that isn't bound to a well understand protocol
semantic defined elsewhere. Every existing action (keep, reject, fileinto,
discard, redirect, and even addheader and refuse) depends normatively
on these sorts of semantics.

For example, folders exist independent of IMAP, but having IMAP there to define
the essential semantics of folders is very useful. Failing to capture the
semantics of message expiration outside the context of sieve would IMO be a
mistake.

> You could also have a sieve implementation that ran against the current
> contents of a mailbox iteratively, and threw out (or refiled) all messages
> older than the expiration date, for example [though I suppose this relies
> more on a date comparison extension than any particular "Expire"
> extension].

Sure, and I'm reasonably comfortable with this, although to be fair it does
extent the applicability of sieve past the use on or around the time of
delivery.

				Ned

From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Sieve extension to expire mails?
Date: Thu, 11 Mar 2004 16:53:37 +0100
Sender: [email-masked]

Rob Siemborski writes:
> On Thu, 11 Mar 2004 [email-masked] wrote:
>
>>  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.
>
> There's nothing that says we need an IMAP extension for expiration 
> before defining a sieve extension for expiration. Sieve can work in 
> enviornments other than IMAP.

It can. But since the two tend to go together in practice, I'd say that 
extensions should too, if only to lessen the chance of future gotchas. 
I would hate to stumble into another maze like ACL/2.

As I read the ANNOTATE draft, Freenet is free to say that 
/vendor/freenet/expiry is an integer containing some number of days, 
counting from the INTERNALDATE. No extension needed.

Arnt

Date: Thu, 11 Mar 2004 07:36:32 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve extension to expire mails?
To: Rick Block <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

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

> Expiration based on message age is common in voicemail systems.  Some
> such systems warn users about messages about to expire and allow users
> to "renew" messages, so although the expiration interval is typically
> per mailbox/folder the expiry process must be driven by a writable
> per message property (one of effective date or expiration date).

First, the fact that some (but by no means all) voice mail systems work this
way doesn't make it a good idea for email systems to work this way. My
voicemail is seriously stressed by my having 20 stored messages in it. In
contrast, my email handles more than 2,000,000 stored messages without
incident, and I routinely put more than 20,000 messages in a single folder.
Per-message expirations could easily have a deleterious effect on this sort of
scalability.

Second, even assuming per-message expiries are a good idea doesn't change the
fact that this proposal is being made in the wrong venue. An IMAP extension
needs to be specified first. Only after that is in place does it make sense to
consider whether or not a sieve extension makes sense. And this in turn
breaks down into three cases:

(1) Expiration is done per-folder or per-mailbox. Sieve deals with messages,
    not folders or mailboxes, so an extension is inappropriate.

(2) Expiration is done per-message using annotations. A sieve extension
    to deal with annotations makes sense in this case; a sieve extension
    to deal with expiration specifically does not.

(3) Expiration is done separately from annotations. A sieve extension may
    make sense in this case, but the odds of this being the way expirations
    get implemented are very, very low.

				Ned

Date: Thu, 11 Mar 2004 10:24:55 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

On Thu, 11 Mar 2004 [email-masked] wrote:

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

There's nothing that says we need an IMAP extension for expiration before
defining a sieve extension for expiration.  Sieve can work in enviornments
other than IMAP.

You could also have a sieve implementation that ran against the current
contents of a mailbox iteratively, and threw out (or refiled) all messages
older than the expiration date, for example [though I suppose this relies
more on a date comparison extension than any particular "Expire"
extension].

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

Date: Thu, 11 Mar 2004 10:22:46 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

On Thu, 11 Mar 2004 [email-masked] wrote:

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

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

Date: Thu, 11 Mar 2004 07:04:01 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve extension to expire mails?
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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

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

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

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

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

Date: Thu, 11 Mar 2004 08:05:27 -0700
From: Rick Block <[email-masked]>
To: [email-masked]
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Sieve extension to expire mails?
Sender: [email-masked]

[email-masked] wrote:
> 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.

Expiration based on message age is common in voicemail systems.  Some
such systems warn users about messages about to expire and allow users
to "renew" messages, so although the expiration interval is typically
per mailbox/folder the expiry process must be driven by a writable
per message property (one of effective date or expiration date).

-Rick

Date: Thu, 11 Mar 2004 06:42:24 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve extension to expire mails?
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Michael Haardt writes:
> > The idea of a folder property versus a message property is
> > interesting, but indeed I thought about a folder property to be
> > specified by Sieve. Expiring mails on delivery is way more efficient
> > than daily jobs, because on many systems (e.g. maildir) the folder
> > contents are already in the page cache. Sieve, as MDA filter,
> > controls local delivery on my systems and if local delivery includes
> > expiration, it feels natural to control that, too.

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

I agree 100%

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

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.

> If your implementation confuses delivery and expiry, that's okay. You
> have a privacy/security issue, that's all. But if the sieve language
> confuses them, all implementations do. Much worse.

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

Exactly right. If the expiration model is per-folder or per-mailbox sieve
has no business trying to muck with it.

				Ned

From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[email-masked]>
To: <[email-masked]>, "Michael Haardt" <[email-masked]>
Subject: Re: Sieve extension to expire mails?
Date: Thu, 11 Mar 2004 14:31:48 -0000
Sender: [email-masked]

> 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: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Sieve extension to expire mails?
Date: Thu, 11 Mar 2004 15:28:38 +0100
Sender: [email-masked]

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

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

To: [email-masked]
Subject: Re: Sieve extension to expire mails?
From: Michael Haardt <[email-masked]>
Date: Thu, 11 Mar 2004 15:01:05 +0100
Sender: [email-masked]

> 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]>
To: [email-masked]
Subject: Re: Sieve extension to expire mails?
Date: Thu, 11 Mar 2004 14:08:52 +0100
Sender: [email-masked]

Michael Haardt writes:
> The idea of a folder property versus a message property is 
> interesting, but indeed I thought about a folder property to be 
> specified by Sieve. Expiring mails on delivery is way more efficient 
> than daily jobs, because on many systems (e.g. maildir) the folder 
> contents are already in the page cache. Sieve, as MDA filter, 
> controls local delivery on my systems and if local delivery includes 
> expiration, it feels natural to control that, too.

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

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.

If your implementation confuses delivery and expiry, that's okay. You 
have a privacy/security issue, that's all. But if the sieve language 
confuses them, all implementations do. Much worse.

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

Arnt

To: [email-masked]
Subject: Re: Sieve extension to expire mails?
From: Michael Haardt <[email-masked]>
Date: Thu, 11 Mar 2004 12:12:24 +0100
Sender: [email-masked]

> This is usually a folder property that a mailstore process removes messages
> based on. Do you want this to be a message property? I really see no reason
> why a sieve extension is needed for this, if you mark a message and the user
> prefers to remove such messages after x hours/days then it should be a
> function
> in the delivery process and mailstore cleanup?
>
> Or is sieve now more than a mta filter language?

The idea of a folder property versus a message property is interesting,
but indeed I thought about a folder property to be specified by Sieve.
Expiring mails on delivery is way more efficient than daily jobs, because
on many systems (e.g. maildir) the folder contents are already in the page
cache.  Sieve, as MDA filter, controls local delivery on my systems and if
local delivery includes expiration, it feels natural to control that, too.

Michael

From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[email-masked]>
To: <[email-masked]>, "Michael Haardt" <[email-masked]>
Subject: Re: Sieve extension to expire mails?
Date: Thu, 11 Mar 2004 10:35:09 -0000
Sender: [email-masked]

This is usually a folder property that a mailstore process removes messages
based on. Do you want this to be a message property? I really see no reason
why a sieve extension is needed for this, if you mark a message and the user
prefers to remove such messages after x hours/days then it should be a
function
in the delivery process and mailstore cleanup?

Or is sieve now more than a mta filter language?

Rgds,
-GSH

----- Original Message ----- 
From: "Michael Haardt" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 11, 2004 10:13 AM
Subject: Sieve extension to expire mails?

>
> Hello,
>
> I use a spam scanner which tags mail, Sieve to filter it in folders and
> IMAP to access the folders, but I miss the function "keep mail up to n
> days in this folder", as offered by some mail providers, badly.
>
> For that reason, I would like opinions about a Sieve extension, which
> allows the mail system to expire mails older than a set amount of time.
> I say "allow", as the time of removal should not be specified.  Some
> systems may do so in daily cleanup jobs, others when delivering the mail.
>
> It is important that this function is not performed by the client,
> because I would like to come back from a longer vacation and have the
> last 7 days of a mailing list archived, not my mailbox flooded with it.
>
> I can think of different ways right now:
>
> Add an option to fileinto and keep, like:
>
>   fileinto :expire 7 "inbox.mailinglist";
>
> The advantage is probably easy implementation for cleanup on delivery,
> but the disadvantage is having to specify it multiple times, if a script
> files mail into that folder at different places, and more complicated
> implementation of daily clenaup jobs.  This approach is the opposite:
>
>   expire 7 "inbox.mailinglist";
>   [actual filter code inclduing fileinto ... ]
>
> Using expire to specify expiration times once at the beginning of the
> script is more modular.  Periodic jobs could extract that information
> easily and it separates folder attributes and filter logic.
>
> In case more attributes of folders are required, perhaps a generic
> statement would be useful:
>
>   folder :expire 7 "inbox.mailinglist";
>
> Do we need a better granularity than days? Does anybody have a better
> idea how to add this feature to Sieve?
>
> Michael
>
>

To: [email-masked]
Subject: Sieve extension to expire mails?
From: Michael Haardt <[email-masked]>
Date: Thu, 11 Mar 2004 11:13:06 +0100
Sender: [email-masked]

Hello,

I use a spam scanner which tags mail, Sieve to filter it in folders and
IMAP to access the folders, but I miss the function "keep mail up to n
days in this folder", as offered by some mail providers, badly.

For that reason, I would like opinions about a Sieve extension, which
allows the mail system to expire mails older than a set amount of time.
I say "allow", as the time of removal should not be specified.  Some
systems may do so in daily cleanup jobs, others when delivering the mail.

It is important that this function is not performed by the client,
because I would like to come back from a longer vacation and have the
last 7 days of a mailing list archived, not my mailbox flooded with it.

I can think of different ways right now:

Add an option to fileinto and keep, like:

  fileinto :expire 7 "inbox.mailinglist";

The advantage is probably easy implementation for cleanup on delivery,
but the disadvantage is having to specify it multiple times, if a script
files mail into that folder at different places, and more complicated
implementation of daily clenaup jobs.  This approach is the opposite:

  expire 7 "inbox.mailinglist";
  [actual filter code inclduing fileinto ... ]

Using expire to specify expiration times once at the beginning of the
script is more modular.  Periodic jobs could extract that information
easily and it separates folder attributes and filter logic.

In case more attributes of folders are required, perhaps a generic
statement would be useful:

  folder :expire 7 "inbox.mailinglist";

Do we need a better granularity than days? Does anybody have a better
idea how to add this feature to Sieve? 

Michael

Date: Mon, 08 Mar 2004 09:22:25 -0800 (PST)
From: [email-masked]
Subject: Comments on draft-daboo-sieve-mime-00.txt
To: Cyrus Daboo <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Sender: [email-masked]

				Ned