Re: Last Call: Sieve -- Subaddress Extension to Proposed Standard

[Ken Murchison <[e-mail]>]

Ken Murchison wrote:
> 
> The IESG wrote:
> >
> > The IESG has received a request to consider Sieve -- Subaddress
> > Extension <draft-murchison-sieve-subaddress-05.txt> as a Proposed
> > Standard.  This has been reviewed in the IETF but is not the product
> > of an IETF Working Group.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > [e-mail] or [e-mail] mailing lists by 2003-4-25.

Just sent in an update.  You can grab it from here until it gets posted:

ftp://ftp.oceana.com/pub/drafts/draft-murchison-sieve-subaddress-06.txt
http://www.oceana.com/ftp/drafts/draft-murchison-sieve-subaddress-06.txt

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VGx4JM028949 for <[e-mail]>; Mon, 31 Mar 2003 08:59:04 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VGx4Pg028948 for ietf-mta-filters-bks; Mon, 31 Mar 2003 08:59:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VGx3JM028944 for <[e-mail]>; Mon, 31 Mar 2003 08:59:03 -0800 (PST)
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.9/8.12.9) with ESMTP id h2VGwxTN029155 for <[e-mail]>; Mon, 31 Mar 2003 11:58:59 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 31 Mar 2003 12:01:50 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: Sieve -- Subaddress Extension to Proposed Standard
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ken Murchison wrote:
> 
> The IESG wrote:
> >
> > The IESG has received a request to consider Sieve -- Subaddress
> > Extension <draft-murchison-sieve-subaddress-05.txt> as a Proposed
> > Standard.  This has been reviewed in the IETF but is not the product
> > of an IETF Working Group.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > [e-mail] or [e-mail] mailing lists by 2003-4-25.

Just sent in an update.  You can grab it from here until it gets posted:

ftp://ftp.oceana.com/pub/drafts/draft-murchison-sieve-subaddress-06.txt
http://www.oceana.com/ftp/drafts/draft-murchison-sieve-subaddress-06.txt

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VGpSJM028703 for <[e-mail]>; Mon, 31 Mar 2003 08:51:28 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VGpS2i028702 for ietf-mta-filters-bks; Mon, 31 Mar 2003 08:51:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VGpPJM028695 for <[e-mail]>; Mon, 31 Mar 2003 08:51:26 -0800 (PST)
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.9/8.12.9) with ESMTP id h2VGpLTN029027 for <[e-mail]>; Mon, 31 Mar 2003 11:51:22 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 31 Mar 2003 11:54:12 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: Sieve -- Subaddress Extension to Proposed Standard
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ken Murchison wrote:
> 
> The IESG wrote:
> >
> > The IESG has received a request to consider Sieve -- Subaddress
> > Extension <draft-murchison-sieve-subaddress-05.txt> as a Proposed
> > Standard.  This has been reviewed in the IETF but is not the product
> > of an IETF Working Group.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > [e-mail] or [e-mail] mailing lists by 2003-4-25.

Just sent in an update.  You can grab it from here until it gets posted:

ftp://ftp.oceana.com/pub/drafts/draft-murchison-sieve-subaddress-06.txt
http://www.oceana.com/ftp/drafts/draft-murchison-sieve-subaddress-06.txt

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2UM6qJM015782 for <[e-mail]>; Sun, 30 Mar 2003 14:06:52 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2UM6qEU015781 for ietf-mta-filters-bks; Sun, 30 Mar 2003 14:06:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2UM6oJM015774 for <[e-mail]>; Sun, 30 Mar 2003 14:06:51 -0800 (PST)
Received: from oceana.com (ny-kenton4a-b-98.buf.adelphia.net [24.51.29.98]) (authenticated bits=0) by eagle.oceana.com (8.12.9/8.12.9) with ESMTP id h2UM6gTO009725 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Sun, 30 Mar 2003 17:06:48 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sun, 30 Mar 2003 17:05:17 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: Sieve -- Subaddress Extension to Proposed Standard
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ken Murchison wrote:
> 
> The IESG wrote:
> >
> > The IESG has received a request to consider Sieve -- Subaddress
> > Extension <draft-murchison-sieve-subaddress-05.txt> as a Proposed
> > Standard.  This has been reviewed in the IETF but is not the product
> > of an IETF Working Group.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > [e-mail] or [e-mail] mailing lists by 2003-4-25.

Just sent in an update.  You can grab it from here until it gets posted:

ftp://ftp.oceana.com/pub/drafts/draft-murchison-sieve-subaddress-06.txt
http://www.oceana.com/ftp/drafts/draft-murchison-sieve-subaddress-06.txt

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SJmUg14960 for ietf-mta-filters-bks; Fri, 28 Mar 2003 11:48:30 -0800 (PST)
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SJmSg14955 for <[e-mail]>; Fri, 28 Mar 2003 11:48:28 -0800 (PST)
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.8/8.12.8) with ESMTP id h2SJmPhH010216; Fri, 28 Mar 2003 14:48:25 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 28 Mar 2003 14:51:13 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Last Call: Sieve -- Subaddress Extension to Proposed Standard
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:
> 
> > The IESG wrote:
> > >
> > > The IESG has received a request to consider Sieve -- Subaddress
> > > Extension <draft-murchison-sieve-subaddress-05.txt> as a Proposed
> > > Standard.  This has been reviewed in the IETF but is not the product
> > > of an IETF Working Group.
> > >
> > > The IESG plans to make a decision in the next few weeks, and solicits
> > > final comments on this action.  Please send any comments to the
> > > [e-mail] or [e-mail] mailing lists by 2003-4-25.
> > >
> > > Files can be obtained via http://www.ietf.org/internet-drafts/draft-murchison-sieve-subaddress-05.txt
> 
> > Since somebody has asked for a last call on this before I was able to
> > update the draft (norm/inform refs, IANA registration), how do I go
> > about updating it now?
> 
> That was me. Sorry -- I didn't catch that you intended to fix this stuff.

No problem.

> As far as revisions go, just do it. While you're at it yu might as well add the
> IPR boilerplate per RFC 2026. The IESG has recently started wanting this in all
> documents.

OK, thanks.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SJCQP12459 for ietf-mta-filters-bks; Fri, 28 Mar 2003 11:12:26 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SJCPg12453 for <[e-mail]>; Fri, 28 Mar 2003 11:12:25 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 28 Mar 2003 11:12:22 -0800 (PST)
Date: Fri, 28 Mar 2003 11:08:28 -0800 (PST)
From: [e-mail]
Subject: Re: Last Call: Sieve -- Subaddress Extension to Proposed Standard
In-reply-to: "Your message dated Fri, 28 Mar 2003 13:36:44 -0500" <[e-mail]>
To: Ken Murchison <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> The IESG wrote:
> >
> > The IESG has received a request to consider Sieve -- Subaddress
> > Extension <draft-murchison-sieve-subaddress-05.txt> as a Proposed
> > Standard.  This has been reviewed in the IETF but is not the product
> > of an IETF Working Group.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > [e-mail] or [e-mail] mailing lists by 2003-4-25.
> >
> > Files can be obtained via http://www.ietf.org/internet-drafts/draft-murchison-sieve-subaddress-05.txt


> Since somebody has asked for a last call on this before I was able to
> update the draft (norm/inform refs, IANA registration), how do I go
> about updating it now?

That was me. Sorry -- I didn't catch that you intended to fix this stuff.

As far as revisions go, just do it. While you're at it yu might as well add the
IPR boilerplate per RFC 2026. The IESG has recently started wanting this in all
documents.

> Or, should I just wait for the editor to spit it back to me?

It would probably take the form of an RFC Editor note, but a revised draft
is always better.

				Ned


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SIY2110552 for ietf-mta-filters-bks; Fri, 28 Mar 2003 10:34:02 -0800 (PST)
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SIY0g10548 for <[e-mail]>; Fri, 28 Mar 2003 10:34:00 -0800 (PST)
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.8/8.12.8) with ESMTP id h2SIXvhH006665 for <[e-mail]>; Fri, 28 Mar 2003 13:33:57 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 28 Mar 2003 13:36:44 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: Sieve -- Subaddress Extension to Proposed Standard
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG wrote:
> 
> The IESG has received a request to consider Sieve -- Subaddress
> Extension <draft-murchison-sieve-subaddress-05.txt> as a Proposed
> Standard.  This has been reviewed in the IETF but is not the product
> of an IETF Working Group.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [e-mail] or [e-mail] mailing lists by 2003-4-25.
> 
> Files can be obtained via http://www.ietf.org/internet-drafts/draft-murchison-sieve-subaddress-05.txt


Since somebody has asked for a last call on this before I was able to
update the draft (norm/inform refs, IANA registration), how do I go
about updating it now?

Or, should I just wait for the editor to spit it back to me?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2O0RQH10335 for ietf-mta-filters-bks; Sun, 23 Mar 2003 16:27:26 -0800 (PST)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2O0ROg10331 for <[e-mail]>; Sun, 23 Mar 2003 16:27:24 -0800 (PST)
Received: from messagingdirect.com (actually [66.222.133.179]) by woozle.isode.com (remote) with ESMTP; Mon, 24 Mar 2003 00:27:09 +0000
Message-ID: <[e-mail]>
Date: Sun, 23 Mar 2003 17:27:04 -0700
From: Alexey Melnikov <[e-mail]>
Organization: ACI WorldWide / MessagingDirect
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Matthew Elvey (FM)" <[e-mail]>
CC: [e-mail]
Subject: Re: Progressing draft-melnikov-sieve-imapflags-04
References: <[e-mail]>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Matthew Elvey (FM)" wrote:

> Five suggestions to the draft.

[Sorry, I had problems with my laptop this week].

> Way back On Tue, 2002-07-16, Tim Showalter wrote:
>
> >Cyrus Daboo wrote:
> >>
> >> | Tim thought that in order to do this right, we need to introduce
> >> | variables in Sieve.
> >> | So I am waiting for either:
> >> | 1). draft that adds Sieve variables
> >> | 2). a desire to standardize draft-melnikov-sieve-imapflags-04.txt as is
> >> | (with an implicit variable).
> >>
> >> One option might be to get rid of the ':globalflags...' tagged arguments
> >> and all the actions and instead only rely on the ':flags' tagged argument
> >> for fileinto and keep. I believe that gets rid of the need to have any
> >> variables during the lifetime of the script, and provides a basic
> >> implementation that can be built on later if variables are introduced.
> >
> >I agree with this.  :globalflags mostly bothered me with respect to
> >variables.
>
> Suggestion 1:
>
> I suggest :globalflags not be removed at least unless a draft and
> implementation adding Sieve variables is well underway.
> -As Ken has said, being able to set a flag once is useful,
>  and with variables, something like
>
>    keep [VariableName, "\\Answered", "$MDNSent"];
>
> would work.
>
> This example makes a complexity of variables evident though - could VariableName be a string-list?
> Adding variables isn't trivial.
>
> Suggestion 2, regarding 3.4, quoted below (Of course, if all implicit
> variables are to done away with, 3.4 mark and unmark would need to go
> too, so these changes are moot.):
>
> 3.4. Mark and Unmark Actions
>
>    Syntax:   mark
>
>    Syntax:   unmark
>
>    The mark action allows a message to be marked as urgent. Conformant implementation MUST
>    set \Flagged [IMAP] flag, but MAY also set other [IMAP] flags as well. Thus the mark  action is
>    semantically equivalent to 'addflag "\\Flagged"'.
>
>    The unmark action allows the flag previously  set  by  the Mark action to be unset.
>    Unmark MUST unset the [IMAP] \Flagged flag and all other flags that could be added with mark.
>    Unmark MUST NOT unset any other flags. This means that the following script does nothing:
>
>       mark;
>       unmark;
>
>    The unmark action is semantically equivalent to 'removeflag "\\Flagged"'.
>
> Several little problems: if mark sets more than one flag,
> then the last sentence is false.  If the message is already marked, then
> mark; unmark; does SOMETHING.  It Removes the flag(s) the first mark set.

Yes, unmark shouldn't remove any flags not settable by mark.

> Does the \Flagged flag necessarily imply the message is "urgent",

I believe the consensus of IMAP community is that this is the case.

> as the first sentence claims?
> Also, why would mark want to set other flags?
> Lastly, unmark cannot unset flags other than \Flagged set by other
> implementations, because it cannot know what they are.
>
> Suggested replacement text:
>
> 3.4. Mark and Unmark Actions
>
>    Syntax:   mark
>
>    Syntax:   unmark
>
>    The mark action allows a message to be marked. Conformant implementation MUST
>    set \Flagged [IMAP] flag, but MAY also set other [IMAP] flags as well.
>
>
>    The unmark action allows the flag previously set by the Mark action to be unset.
>    Unmark MUST unset the [IMAP] \Flagged flag and all other flags that could be added with mark by the implementation.
>    Unmark MUST NOT unset any other flags.

Ok, I agree with all your comments regarding mark/unmark. However, as mentioned earlier these two commands will be dropped
from the document.

> Suggestion 3:
> IMHO, the RFC would be useful if the following was added:
>
> I would follow the sentence in 5. "The SIEVE interpreter MUST ignore these
>    commands when no keep (implicit or explicit) or fileinto actions will be taken."
> with "Thus, for example, scripts should set flags before fileinto, not after!"
>
> Why: it's non-obvious to sieve script writers, who get caught by this 'gotcha'.
>
> #A counterexample:
> #The following doesn't make sense: the Seen flag isn't set in any message store,
> #because it isn't followed by a keep or fileinto which would cause it to do so.
> #If you want the copy in test1 to be marked as seen, reverse the order of the fileinto
> #and addflag commands.  Perhaps an implementation SHOULD flag this as an error.
> #But perhaps not; I think an implementation couldn't catch all such errors,
> #except at runtime, so trying to catch some isn't very helpful.
> if header "subject" :contains "test1"
> {
>    fileinto "test1 folder";
>    addflag "\\Seen";
>    stop;
> }

Ok, I've updated my copy. But once again, as the decision was to use variables, this will be dropped in the future
(however I keep a copy of all changes if somebody comes up with a counter argument

> Suggestion 4:
>
> There's a typo : "If non of the 4" should read "If none of the 4"

Fixed.

> Suggestion 5:
>
> address :all :contains
>                   ["To", "Cc", "Bcc"] "[e-mail] <mailto:[e-mail]>",
>
> is nonsensical; it should be changed to
>
> address :all :contains
>                   ["To", "Cc"] "[e-mail] <mailto:[e-mail]>",
>
> because there is no Bcc header in received email.

Changed.

Regards,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: [phone]
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2MKfXq07712 for ietf-mta-filters-bks; Sat, 22 Mar 2003 12:41:33 -0800 (PST)
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2MKfVg07708 for <[e-mail]>; Sat, 22 Mar 2003 12:41:31 -0800 (PST)
Received: from einn.ifi.uio.no ([129.240.65.201]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18wpo2-0002AW-00 for [e-mail]; Sat, 22 Mar 2003 21:41:30 +0100
Received: (from kjetilho@localhost) by einn.ifi.uio.no ; Sat, 22 Mar 2003 21:41:29 +0100 (MET)
To: [e-mail]
Subject: Re: sieve lunch meeting notes
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 22 Mar 2003 21:41:29 +0100
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 53
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Matthew Elvey (FM)]:
>
>   Any demand or support for reject: logging of some sort?  Perhaps
>   an option to log the emails without the body to a folder would be
>   simplest.

extend fileinto ?

this could also be a job for NOTIFY.

btw, the syntax for variables available in NOTIFY should be reconciled
with the variables draft.  this could go either way, of course.  my
preferred tack would be to add an action to the notify draft which
creates the variables "from", "env_from", "subject", and "text".  the
variables draft could also use a substring modifier.  this isn't
strictly necessary, since with regex you can express it like this:

    require [ "regex", "variables", "notify" ];
    if string :regex "${text}" "(.{,100})" {
        notify :low "${from}: ${1}";
    }

this is a bit awkward for the user and doesn't lend itself to
efficient implementation, though.  unfortunately, the
variable-modifier is limited to function name, with no way of
specifying an argument.  that may be too inflexible for future
expansion, but on the other hand, string interpolation shouldn't
become too complex either.

changing variable-modifier syntax:
  "${substr(0,200):text}"

adding slice explicitly to the syntax:
  "${text[0..199]}"
or even
  "${text[0-4,5,6-199]}"

>   The variables draft has an editing error in 3.2:
>   
>              if header :regex "From" "^
>   
>   is missing the regexp and close quote.

thanks, I should read my roff output more carefully.  it was supposed
to say
           if header :regex "From" "^\"?([^ \"]*).*<" {

(it's not a good example, really, the regex is cryptic and becomes the
focus of attention.)

-- 
Kjetil T.			|  read and make up your own mind
				|  http://www.cactus48.com/truth.html


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2MJfBQ05529 for ietf-mta-filters-bks; Sat, 22 Mar 2003 11:41:11 -0800 (PST)
Received: from smtp.us2.messagingengine.com (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2MJfAg05522 for <[e-mail]>; Sat, 22 Mar 2003 11:41:10 -0800 (PST)
Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id E0E6424E7E for <[e-mail]>; Sat, 22 Mar 2003 14:41:08 -0500 (EST)
Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Sat, 22 Mar 2003 14:41:08 -0500
X-Epoch: 1048362068
X-Sasl-enc: bfyEhVdhjoYNjlP+K25KZQ
Received: from elvey.fastmail.fm (adsl-64-165-199-135.dsl.snfc21.pacbell.net [64.165.199.135]) by www.fastmail.fm (Postfix) with ESMTP id 94677269DD for <[e-mail]>; Sat, 22 Mar 2003 14:41:07 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sat, 22 Mar 2003 11:41:07 -0800
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: sieve lunch meeting notes
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Matthew Elvey wrote:

> From notes:
>
>> [12:02]<leg> Jutta: want to set From address for vacations
>
> I've seen that it's a popular request of users to be able to set the 
> From (in both Header and Envelope, to answer the later question) for 
> reject:,  so here's a thumbs up for that. 

Any demand or support for reject: logging of some sort?  Perhaps an 
option to log the emails without the body to a folder would be simplest.

> A timezone-aware DateDiff type function would be MOST useful; with it, 
> I'm thinking that explicit TZ and other conversion, extraction, and 
> comparator functions would not be needed! 

:datediff would be an addition to relational extension.  Any support for 
that?

> Re. Simon's comment:... 

variables aren't inherently dangerous per the variables draft.

The variables draft has an editing error in 3.2:

           if header :regex "From" "^

is missing the regexp and close quote.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2MGfZv27337 for ietf-mta-filters-bks; Sat, 22 Mar 2003 08:41:35 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2MGfYg27333 for <[e-mail]>; Sat, 22 Mar 2003 08:41:34 -0800 (PST)
Received: from [10.0.1.2] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA07034 for <[e-mail]>; Sat, 22 Mar 2003 11:38:12 -0500 (EST)
Date: Sat, 22 Mar 2003 08:41:34 -0800
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Re: variables draft
Message-ID: <2147483647.1048322493@[10.0.1.2]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/3.0.3 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI I have added this draft and updated links for other drafts on our SIEVE 
page at <http://www.cyrusoft.com/sieve/>. This includes copies of some 
expired drafts in the current internet-drafts repository. If there are any 
that I have missed please email me privately.

If there is anything else you would like to see on this page (e.g. SIEVE 
implementations we have missed, example scripts etc), or anything that is 
not right, please let me know privately.

-- 
Cyrus Daboo


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2MFqL325737 for ietf-mta-filters-bks; Sat, 22 Mar 2003 07:52:21 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2MFqKg25731 for <[e-mail]>; Sat, 22 Mar 2003 07:52:20 -0800 (PST)
Received: from [10.0.1.2] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA06719; Sat, 22 Mar 2003 10:48:56 -0500 (EST)
Date: Sat, 22 Mar 2003 10:52:17 -0800
From: Cyrus Daboo <[e-mail]>
To: "Matthew Elvey (FM)" <[e-mail]>, [e-mail]
Subject: Re: sieve lunch meeting notes
Message-ID: <1361113183.1048330337@[10.0.1.2]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.0.3 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Matthew,

--On Friday, March 21, 2003 5:06 PM -0800 "Matthew Elvey (FM)" 
<[e-mail]> wrote:

| Oh and one more vote for ManageSieve.  LDAP and ACAP are cooler (as
| ManageSieve admits, IIRC) but the explanations of why ManageSieve is
| necessary win me over.

Agreed.

A client that already implements IMAP is not going to have much work to do 
to support ManageSIEVE. Its worth noting that ManageSIEVE does not preclude 
storage of SIEVE scripts in LDAP - ManageSIEVE can simply be a front-end 
for the LDAP store and hide the complexity of any LDAP schema from the 
client.

-- 
Cyrus Daboo


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2M16B126816 for ietf-mta-filters-bks; Fri, 21 Mar 2003 17:06:11 -0800 (PST)
Received: from smtp.us2.messagingengine.com (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2M16Ag26811 for <[e-mail]>; Fri, 21 Mar 2003 17:06:10 -0800 (PST)
Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id 8824F49B30 for <[e-mail]>; Fri, 21 Mar 2003 20:06:10 -0500 (EST)
Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Fri, 21 Mar 2003 20:06:10 -0500
X-Epoch: 1048295170
X-Sasl-enc: brIO1WcIfiqK0WGBjvfMRA
Received: from elvey.fastmail.fm (adsl-64-165-199-135.dsl.snfc21.pacbell.net [64.165.199.135]) by www.fastmail.fm (Postfix) with ESMTP id 4BED21EF0D for <[e-mail]>; Fri, 21 Mar 2003 20:06:09 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 21 Mar 2003 17:06:11 -0800
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: sieve lunch meeting notes
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>[12:02]<leg> Jutta: want to set From address for vacations
I've seen that it's a popular request of users to be able to set the 
 From (in both Header and Envelope, to answer the later question) for 
reject:,  so here's a thumbs up for that.


Re Timestamps: There are many in a given email and I can see a potential 
use for all of 'em.
 From most to least important:
1)The one in the top (most trusted) Received: header, and the (often 
incorrect/forged) one in the Date: Header.  (Some MUAs sort by the 
latter; the former should be used IMO)
2)The one in the bottom Received header and
3)The others (which can show time delays)
 A timezone-aware DateDiff type function would be MOST useful; with it, 
I'm thinking that explicit TZ and other conversion, extraction, and 
comparator functions would not be needed!


Re. Simon's comment: are variables inherently dangerous/CPU 
hogs/contrary to the original SIEVE CPU-safe goals?  Why?  I don't see 
it.  Obviously "while" and less obviously regexps are not safe.  Perhaps 
someone could make these clearer.  (Sorry if I'm jumping in way late on 
this one.)



Oh and one more vote for ManageSieve.  LDAP and ACAP are cooler (as 
ManageSieve admits, IIRC) but the explanations of why ManageSieve is 
necessary win me over.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2M0xfL26554 for ietf-mta-filters-bks; Fri, 21 Mar 2003 16:59:41 -0800 (PST)
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2M0xcg26549 for <[e-mail]>; Fri, 21 Mar 2003 16:59:39 -0800 (PST)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18wXMI-0004fG-00 for [e-mail]; Sat, 22 Mar 2003 01:59:38 +0100
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Sat, 22 Mar 2003 01:59:38 +0100
To: [e-mail]
Subject: variables draft
From: Kjetil Torgrim Homme <[e-mail]>
Date: 22 Mar 2003 01:59:38 +0100
Message-ID: <[e-mail]>
Lines: 17
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=-=-=

hi, I have previously sent a couple of drafts suggesting a variables
extension.  unfortunately these have accidentally been dropped by the
drafts maintainer.  to be accepted into the database now, my draft
must be numbered -00.  this should not be confused with my earlier -00
draft, which was quite a bit different.  I am told it will be
available from the Internet-Drafts on Monday, but since this seems a
hot topic for debate, I figured I'd post it here now.  hope you don't
mind the 500 line message.

the draft includes backreferences implicitly when regex is in effect.


--=-=-=
Content-Disposition: attachment;
  filename=draft-homme-sieve-variables-00.txt
Content-Description: variables extension draft







Network Working Group                                        K. T. Homme
Document: draft-homme-sieve-variables-00.txt          University of Oslo
Expires September 21, 2003                                   21 Mar 2003

                      Sieve -- Variables Extension

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   Distribution of this memo is unlimited.


Abstract

   In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension adds an action to
   store data in variables, changes the interpolation of double quoted
   strings, and supplies a new test so that the value of a string can be
   examined.

0     Meta-information on this draft

   This information is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.


0.1   Discussion

   This draft is intended to be an extension to the Sieve mail filtering
   language, available from the RFC repository as



Homme                                                           [Page 1]





Internet Draft        Sieve -- Variables Extension           20 Mar 2003


   <ftp://ftp.ietf.org/rfc/rfc3028.txt>.

   This draft and the Sieve language itself are being discussed on the
   MTA Filters mailing list at <[e-mail]>.  Subscription
   requests can be sent to <[e-mail]> (send an
   email message with the word "subscribe" in the body).  More
   information on the mailing list along with a WWW archive of back
   messages is available at <http://www.imc.org/ietf-mta-filters/>.

0.2   Noted Changes

   a) "setdate" now has an optional timezone argument, and the default
   timezone is UTC.

   b) the first two revisions of this document went into a bitbucket at
   IETF.  the numbering has to revert to -00 to accomodate their
   database.

0.3   Open Issues

   a) Should we include more predefined variables to access the time?
   (timezone, weekday, week number (US, EU and/or ISO?), name of month,
   name of weekday, ...)  Could use strftime(3c) as a list of what to
   offer, but the names should be in English.

   b) This extension is particularily useful if fileinto is extended to
   create new folders on demand.

   Example:
            setdate "+0200"
            fileinto :makefolder "archive.${year}-${month}";

   This will be proposed in a separate extension.

   c) Should the modifier syntax be prefix or postfix?  ${var.lower} may
   be more natural than ${lower:var}, since the order of evaluation runs
   the same way as the syntax, rather than in the opposite direction.

   d) The modifiers for changing to upper or lower case are dependent on
   language, e.g. in Turkish the upper case of "i" is capital dotted I
   and the lower case of "I" is "i" without the dot.  There is no way of
   specifying what locale to use in the modifiers toupper et al.  A user
   can't rely on this being handled perfectly, anyway, so it may be
   acceptable to leave the choice of locale to the server administrator.


1.  Introduction




Homme                                                           [Page 2]





Internet Draft        Sieve -- Variables Extension           20 Mar 2003


   This is an extension to the Sieve language defined by [SIEVE].  It
   adds support for storing and referencing data in string variables.

   Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS].

2.  Capability Identifier

   The capability string associated with the extension defined in this
   document is "variables".

3.  Interpretation of strings

   This extension changes the semantics of quoted-string, multi-line-
   literal and multi-line-dotstuff found in [SIEVE] to enable the
   inclusion of the value of variables.  The syntax follows [ABNF].


              variable-ref  =  "${" *variable-modifier variable-name "}"
         variable-modifier  =  1*ALPHA ":"
             variable-name  =  num-variable / user-variable
              num-variable  =  1*DIGIT
             user-variable  =  ALPHA *(ALPHA / DIGIT / "_")

   When the string is evaluated, substrings matching variable-ref shall
   be replaced by the value of variable-name.  Variable names are case
   insensitive.  Unknown variables are replaced by the empty string.  As
   per the grammar, illegal variable names leaves the would-be variable-
   ref verbatim, since it doesn't match the variable-ref syntax.

   Examples:
           "&%${}!"     => unchanged, as the empty string is an illegal
                           identifier
           "${doh!}"    => unchanged, as "!" is illegal in identifiers

           The variable company holds the value "ACME".  No other
           variables are set.

           "${full}"    => the empty string
           "${company}" => "ACME"
           "${President, ${Company} Inc.}"
                        => "${President, ACME Inc.}"

   Strings SHOULD be evaluated every time control reaches the statement
   it is a part of, to make sure the expanded variable values are up-to-
   date.

3.1 Quoting



Homme                                                           [Page 3]





Internet Draft        Sieve -- Variables Extension           20 Mar 2003


   The semantics of quoting using backslash are not changed.  Backslash
   quoting is resolved before doing variable substitution.

   Examples:
           "${fo\o}"  => ${foo}  => the expansion of variable foo.
           "${fo\\o}" => ${fo\o} => illegal identifier => left verbatim.
           "\${foo}"  => ${foo}  => the expansion of variable foo.
           "\\${foo}" => \${foo} => a backslash character followed by the
                                    expansion of variable foo.

   If it is required to include a character sequence such as "${beep}"
   verbatim in a text literal, the user can define a variable to
   circumvent expansion to the empty string.

   Example:
        set dollar "$"
        set text "regarding ${dollar}{beep}"

3.2 Numeric variables

   Unless the extension "regex" is in use, all variables whose names are
   all digits MUST evaluate to the empty string.

   The decimal value of the numeric variable name will index the list of
   matching strings from the each of the group operators in the latest
   regular expression match.  The first pair of grouping parentheses has
   index 1.  If the index is out of range, the empty string will be
   substituted.  Index 0 returns the number of matching groups.

   Example:
           require [ "fileinto", "regex", "variables", "vacation" ];

           if header :regex "List-ID" "<(.*)@" {
             fileinto "lists.${1}"; stop;
           }

           if header :regex "From" "^
             set greeting "Dear ${1},";
           }
           if header :regex "Subject" "(.*)" {
                set subject " on ${1}";
           }

        vacation text:
           ${greeting}

           Thank you for your mail${subject}.
           I'm away from office for a few days, but I will get back to



Homme                                                           [Page 4]





Internet Draft        Sieve -- Variables Extension           20 Mar 2003


           you as soon as possible.
           .
           ;

3.3  Modifiers

   Modifiers change the expansion of the variable.  More than one can be
   specified, in which case they are applied from right to left.
   Modifier names are case insensitive.  Unknown modifiers MUST yield a
   syntax error.

   Examples:
           set string "juMBlEd lETteRS"
           "${length:string}" => "15"
           "${lower:string}" => "jumbled letters"
           "${upperfirst:string}" => "JuMBlEd lETteRS"
           "${upperfirst:lower:string}" => "Jumbled letters"

3.3.1 Modifier "length:"

   The expansion is replaced by the number of letters in the
   expansion.

3.3.2 Case modifiers

   These modifiers change the letters of the text from upper to lower
   case or vice versa.  The implementation MUST support US-ASCII, but
   is not required to handle the entire Unicode repertoire.

   3.3.2.1 Modifier "upper:"

   All lower case letters are converted to their upper case counterpart.

   3.3.2.2 Modifier "lower:"

   All upper case letters are converted to their lower case counterpart.

   3.3.2.3 Modifier "upperfirst:"

   The first character of the expansion is converted to upper case if it
   is a letter and set in lower case.  The rest of the expansion is left
   unchanged.

   3.3.2.4 Modifier "lowerfirst:"

   The first character of the expansion is converted to lower case if it
   is a letter and set in upper case.  The rest of the expansion is left
   unchanged.



Homme                                                           [Page 5]





Internet Draft        Sieve -- Variables Extension           20 Mar 2003


4.  Action set

   Syntax:   set <name: user-variable> <value: string>

   The "set" action stores the specified value in the variable.
   Assignment to a reserved variable name or an illegal identifier MUST
   cause a syntax error.  All variables have global scope.  Variable
   names are case insensitive.

   Example:
           set honorific  "Mr";
           set first_name "Wile";
           set last_name  "Coyote";
           set vacation text:
           Dear ${HONORIFIC} ${last_name},
           I'm out, please leave a message after the beep.
           .
           ;

   "set" does not affect the implicit keep.

5.  Action setdate

   Syntax: setdate [time-zone]

           time-zone  =  ( "+" / "-" ) 4DIGIT

   The action setdate initialises a few variables:

          ${year}   => the current year, "0000" .. "9999"
          ${month}  => the current month, "01" .. "12"
          ${day}    => the current day, "01" .. "31"
          ${hour}   => the current hour, "00" .. "23"
          ${minute} => the current hour, "00" .. "59"
          ${second} => the current second, "00" .. "59"

   These variables SHOULD reference the time when execution of the Sieve
   script reaches the statement.

   The default time zone is UTC.  The time-zone should be interpreted
   the same way as "zone" in [IMAIL].


6.  Test string

       Syntax:  string [MATCH-TYPE] [COMPARATOR]
                <source: string-list> <key-list: string-list>




Homme                                                           [Page 6]





Internet Draft        Sieve -- Variables Extension           20 Mar 2003


   The "string" test evaluates to true if any of the strings matches any
   key.  The type of match defaults to ":is".


7.  Security Considerations

   When combined with the regex extension, strings can contain arbitrary
   values controlled by the sender of the e-mail if the author of the
   script isn't careful.

   The introduction of variables makes advanced decision making easier
   to write, but since no looping construct is provided, all Sieve
   scripts will terminate orderly.


8.  Acknowledgments

   Thanks to Jutta Degener, Peder Stray and Nigel Swinson for valuable
   feedback.

8.  Author's Address

   Kjetil T. Homme
   Frydens g 5B
   0564 Oslo, Norway

   Phone: [phone]
   E-mail: [e-mail]

Appendix A.  References

   [ABNF] D. Crocker, Ed., "Augmented BNF for Syntax Specifications:
       ABNF", Internet Mail Consortium, RFC 2234, November 1997

   [IMAIL] P. Resnick, Ed., "Internet Message Format", QUALCOMM
       Incorporated, April 2001.

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
       Requirement Levels", Harvard University, RFC 2119, March 1997.

   [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Mirapoint,
       RFC 3028, January 2001.

Appendix B.  Full Copyright Statement

   Copyright (C) The Internet Society 2002. All Rights Reserved.

   This document and translations of it may be copied and furnished to



Homme                                                           [Page 7]





Internet Draft        Sieve -- Variables Extension           20 Mar 2003


   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as
   required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.






























Homme                                                           [Page 8]



--=-=-=


-- 
Kjetil T.			|  read and make up your own mind
				|  http://www.cactus48.com/truth.html

--=-=-=--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2LNGlP21422 for ietf-mta-filters-bks; Fri, 21 Mar 2003 15:16:47 -0800 (PST)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LNGjg21415 for <[e-mail]>; Fri, 21 Mar 2003 15:16:45 -0800 (PST)
Received: from messagingdirect.com (actually [142.59.130.5]) by woozle.isode.com (remote) with ESMTP; Fri, 21 Mar 2003 23:16:24 +0000
Message-ID: <[e-mail]>
Date: Fri, 21 Mar 2003 16:16:20 -0700
From: Alexey Melnikov <[e-mail]>
Organization: ACI WorldWide / MessagingDirect
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Simon Josefsson <[e-mail]>
CC: [e-mail]
Subject: Re: sieve lunch meeting notes
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[As a person who was actually taking notes for this meeting I though I should
comment]

Simon Josefsson wrote:

> Lawrence Greenfield <[e-mail]> writes:
>
> >    [12:37]<leg> Why not use LDAP instead of Managesieve? Rant, rant, rant
>
> How would LDAP return a useful error message when the Sieve script
> doesn't parse correctly?  How would LDAP switch among active scripts?
> It seems LDAP would have to be profiled to provide these features,
> which effectively creates a new protocol, one that would be more
> complicated than Managesieve.  Implementation wise, except for
> profiling the LDAP implementation, it would also have to interact with
> a Sieve parser.  It just seems bloated to me, since this LDAP server
> isn't likely to be reused for any other purpose, which supposedly was
> the point of using LDAP in the first place.

Exactly. You need at least some schema and probably some integration with Sieve
engine.

ACAP was also mentioned, with a comment that nobody implemented it.

> Generally I'm glad to see that there are thoughts about making Sieve a
> turing complete language (which I believe it should have been from the
> start), with variables and regexps.  To cater for big sites that
> doesn't want to spend CPU time on behalf of their customers, the
> inefficient language constructs could be made optional [1].  No need
> to rule out useful language constructs for everyone just because
> someone can't implement them.
>
> [1] require ["variables", "while", "backreferences"]

There is a fair interest in introducing variables, so join the discussion.

Regards,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: [phone]
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2LHJHv03020 for ietf-mta-filters-bks; Fri, 21 Mar 2003 09:19:17 -0800 (PST)
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LHJFg03015 for <[e-mail]>; Fri, 21 Mar 2003 09:19:16 -0800 (PST)
Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.8/8.12.8) with ESMTP id h2LHIoZG002799 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 21 Mar 2003 18:18:51 +0100
To: Lawrence Greenfield <[e-mail]>
Cc: [e-mail]
Subject: Re: sieve lunch meeting notes
X-Payment: hashcash 1.2 0:030321:[e-mail]:ca20ecb69bbe5c05
X-Hashcash: 0:030321:[e-mail]:ca20ecb69bbe5c05
X-Payment: hashcash 1.2 0:030321:[e-mail]:5e045e48274ac605
X-Hashcash: 0:030321:[e-mail]:5e045e48274ac605
From: Simon Josefsson <[e-mail]>
Date: Fri, 21 Mar 2003 18:18:50 +0100
In-Reply-To: <[e-mail]> (Lawrence Greenfield's message of "Thu, 20 Mar 2003 15:27:20 -0800")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.3.50 (gnu/linux)
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham	version=2.50
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lawrence Greenfield <[e-mail]> writes:

>    [12:37]<leg> Why not use LDAP instead of Managesieve? Rant, rant, rant

How would LDAP return a useful error message when the Sieve script
doesn't parse correctly?  How would LDAP switch among active scripts?
It seems LDAP would have to be profiled to provide these features,
which effectively creates a new protocol, one that would be more
complicated than Managesieve.  Implementation wise, except for
profiling the LDAP implementation, it would also have to interact with
a Sieve parser.  It just seems bloated to me, since this LDAP server
isn't likely to be reused for any other purpose, which supposedly was
the point of using LDAP in the first place.

Generally I'm glad to see that there are thoughts about making Sieve a
turing complete language (which I believe it should have been from the
start), with variables and regexps.  To cater for big sites that
doesn't want to spend CPU time on behalf of their customers, the
inefficient language constructs could be made optional [1].  No need
to rule out useful language constructs for everyone just because
someone can't implement them.

[1] require ["variables", "while", "backreferences"]



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2KNwL724617 for ietf-mta-filters-bks; Thu, 20 Mar 2003 15:58:21 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KNwKg24612 for <[e-mail]>; Thu, 20 Mar 2003 15:58:20 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 20 Mar 2003 15:58:11 -0800 (PST)
Date: Thu, 20 Mar 2003 15:57:08 -0800 (PST)
From: [e-mail]
Subject: Re: sieve lunch meeting notes
In-reply-to: "Your message dated Thu, 20 Mar 2003 15:27:20 -0800" <[e-mail]>
To: Lawrence Greenfield <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Our Sieve lunch meeting was surprisingly productive. Many drafts were
> discussed---pretty much the only thing we missed was "notify".

FYI, I'm trying a little experiment with the datatracker on these
drafts -- I've entered the meeting results as comments for all of them into
tracker.

				Ned


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2KNRdn23662 for ietf-mta-filters-bks; Thu, 20 Mar 2003 15:27:39 -0800 (PST)
Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KNRbg23655 for <[e-mail]>; Thu, 20 Mar 2003 15:27:37 -0800 (PST)
Received: from majormajor.ietf56.ietf.org (wl-142-65.wireless.ietf56.ietf.org [130.129.142.65]) (user=leg mech=GSSAPI (0 bits)) by smtp6.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h2KNRb6t031951 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 20 Mar 2003 18:27:39 -0500
Date: Thu, 20 Mar 2003 15:27:20 -0800
From: Lawrence Greenfield <[e-mail]>
To: [e-mail]
Subject: sieve lunch meeting notes
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.0.3 (Win32)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========191933570=========="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--==========191933570==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Our Sieve lunch meeting was surprisingly productive. Many drafts were 
discussed---pretty much the only thing we missed was "notify".

We danced around variables a lot and there is deep suspicion of variables 
but also a clear idea that they could make certain operations significantly 
easier.

Larry

--==========191933570==========
Content-Type: text/html; charset=iso-8859-1;
 name="sieve_conference.ietf.jabber.com.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="sieve_conference.ietf.jabber.com.html"; size=19719

<p><font size=3D+1><b>New Conversation at: 3/20/2003 11:44:52 =
AM</b></font><br />
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:44]</span><span style=3D"color: =
green;">leg has arrived.</span></div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:47]</span><span style=3D"color: =
green;">kmurchison has arrived.</span></div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:47]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> New proposal for examining MIME headers. This =
is a separate from BODY</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:49]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Talking about Binary filtering (sorry, =
can&apos;t be more precise)</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:49]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Tim: this is not a good idea</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:50]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Searching for binary data encoded in base64 is =
ugly: need 3 combinations for different offset of NUL character</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:51]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> BODY extention is good for last call, but need =
to add comparator so it can handle binary comparison</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:52]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Make comparator mandatory</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:52]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Ned: let&apos;s talk about spam test</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:53]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Do we want to add capability to return spam =
categories and list of rules as used by some spam tools?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:58]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Modify spam test to return number (1 to 10) =
and text string. Text string is implementation defined and can contain spam =
category or something else</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:58]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Do we need variables in SIEVE.</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:59]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> This would be great for spamtest</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[11:59]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Ned: Vacation draft</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:00]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> give time a &quot;poke&quot; for me  =
:)</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:00]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> ^time^tim</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:01]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Ned: Change list of headers: remove BCC, add =
Resent-To, Resent-CC</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:02]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Tim: he is saying &quot;hi&quot;</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:02]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Jutta: want to send From address for =
vacations</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:04]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> s/send/set</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:04]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> envelope or header?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:05]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Larry was talking about CMU hack, but you =
probably know about it</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:05]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> yes</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:05]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Header in vacation reply</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:05]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Ned: let&apos;s talk about regex</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:05]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> il8n issues</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:06]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Ned: I have some code for posix regex and can =
share it</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:06]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> great.  how do we handle il8n in the =
text?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:08]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Nobody knows, but we have Ned</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:08]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> &apos;s support</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:08]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> also, people have expressed interest in =
backreferences (y/n)?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:09]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Sorry, can you elaborate?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:10]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> i think this would dovetail with =
variables.  match part of an address and then use a backref variable as =
part of fileinto, or something</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:10]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> ask Simon, if he is there (looking at =
mailing list archives)</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:11]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Larry: regex without variables is bad</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:11]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Tim, Jutta: we disagree</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:12]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Tim: we can reserve $1 .. $9</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:12]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> ... for regex</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:12]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> it seems to work for me without =
variables  :)</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:13]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> shouldn&apos;t  $1..$9 only be reserved =
under the scope of a regex?  or is that too confusing?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:13]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Dave Crocker: don&apos;t reinvent the =
wheel</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:14]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> can you elaborate on Daves&apos;s =
comment?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:14]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> There is no consensus on $1 .. $9 yet</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:14]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Dave is commenting about hot discussion about =
&quot;variables: good or evil&quot;</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:15]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> do we have consensus on strict POSIX =
regexes?  ie, we don&apos;t allow \w, \s, etc?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:15]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> No idea</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:16]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Decision: regex is not ready, take to the =
list</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:17]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Ned will help you with i18n.</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:17]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> ok</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:18]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> what about subaddress?  is it a keeper? =
 is it ready for last call?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:19]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> subaddress is the next on the list. Just wait =
a second</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:20]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Ned: let&apos;s talk about subaddress. I =
implemented it.</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:21]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Ned doesn&apos;t remember any comments on =
subaddress</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:21]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> either do I</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:21]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> there was discussion on the usefullness =
of :detail</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:21]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> it migth be useful in the presence of =
variables however</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:22]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> The only pushback can be on describing which =
character is delimiter (&quot;-&quot;, &quot;+&quot;, ...)</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:23]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> do we want it standardized, or =
configureable (either in the script, or byt site/implementation)?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:24]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Yep, but nobody want&apos;s to write =
&quot;variable&quot; draft. Jutta has a draft</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:25]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Flags draft: remove mark/unmark</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:25]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Post your question to the list.</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:25]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> ok</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:26]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Problem: associating flag state with =
keep/fileinto</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:28]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> addflags/removeflags is ugly in UI</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:29]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Proposal to drop addflags/.. also, preserve =
:globalflags only</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:31]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Coming back to &quot;do we want it =
standardized ...&quot; question. If your were talking about delimiter =
character, just tell that it is implementation dependent and people believe =
your text is good as is (?)</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:32]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> ok</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:33]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Variable draft will fix =
addflags/replaceflags</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:34]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Managesieve: ready for last call?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:35]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Larry: Managesieve has defined a new URI =
scheme. I am confused though</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:37]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Why not use LDAP instead of Managesieve? Rant, =
rant, rant ...</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:37]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> i believe there are outstanding text =
fixes need w.r.t STARTTLS and auto-capability response (tmartin is aware of =
these)</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:38]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> i also believe that Rob and I extended =
the URL syntax</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:39]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Send changes to URL to the list, please.</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:39]</span><span style=3D"color: =
#FF0000;">&lt;kmurchison&gt;</span> ok</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:43]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Jutta: add parameter to fileinto: if the =
folder doesn&apos;t exist, create it.</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:43]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Ok</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:44]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Ned: Add Date extention: date in date/received =
header or current date</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:44]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Add comparator for date?</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:45]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Also need timezone information</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:52]</span><span style=3D"color: =
green;">leg has arrived.</span></div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:53]</span><span style=3D"color: =
#FF0000;">&lt;leg&gt;</span> Sorry, laptop powered off. But we are done =
anyway!</div>
<div style=3D"background-color: #FFFFFF;font-family: Arial; font-size: =
10pt;"><span style=3D"color: gray;">[12:56]</span><span style=3D"color: =
green;">kmurchison has arrived.</span></div>

--==========191933570==========--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2KIT0H06859 for ietf-mta-filters-bks; Thu, 20 Mar 2003 10:29:00 -0800 (PST)
Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KISxg06854 for <[e-mail]>; Thu, 20 Mar 2003 10:28:59 -0800 (PST)
Received: from majormajor.ietf56.ietf.org (wl-142-65.wireless.ietf56.ietf.org [130.129.142.65]) (user=leg mech=GSSAPI (0 bits)) by smtp7.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h2KISwpf013609 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 20 Mar 2003 13:28:59 -0500
Date: Thu, 20 Mar 2003 10:28:42 -0800
From: Lawrence Greenfield <[e-mail]>
To: "Matthew Elvey (FM)" <[e-mail]>, [e-mail]
Subject: Re: sieve lunch @IETF 56; imapflags
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.0.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Thursday, March 20, 2003 7:39 AM -0800 "Matthew Elvey (FM)" 
<[e-mail]> wrote:

> Also, I heard no response to
> http://www.imc.org/ietf-mta-filters/mail-archive/msg02584.html
> Progressing draft-melnikov-sieve-imapflags-04
>
> How's the imapflags draft going? (Paging Alexey Melnikov...)

I think we have a lot of questions about how to add variables and it seems 
premature to progress imapflags until we understand something about 
variables.

Larry



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2KFcel29831 for ietf-mta-filters-bks; Thu, 20 Mar 2003 07:38:40 -0800 (PST)
Received: from smtp.us2.messagingengine.com (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KFccg29825 for <[e-mail]>; Thu, 20 Mar 2003 07:38:38 -0800 (PST)
Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id C859E4C1CB for <[e-mail]>; Thu, 20 Mar 2003 10:38:37 -0500 (EST)
Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Thu, 20 Mar 2003 10:38:37 -0500
X-Epoch: 1048174717
X-Sasl-enc: G953EdfGZNJI9dVwIXYIOQ
Received: from elvey.fastmail.fm (adsl-64-165-199-135.dsl.snfc21.pacbell.net [64.165.199.135]) by www.fastmail.fm (Postfix) with ESMTP id 4AA5717095 for <[e-mail]>; Thu, 20 Mar 2003 10:38:36 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 20 Mar 2003 07:39:24 -0800
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: sieve lunch @IETF 56; imapflags
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------060307040300000908070007"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------060307040300000908070007
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Philip Guenther wrote:

>I wrote:
>  
>
>>We will be meeting to talk about sieve and sieve extensions (especially
>>those in draft: regexp, body, spamtest) after the spam meeting on
>>Thursday, at 11:30am, in the back of Continental 8/9.
>>    
>>
>
>As a heads up, I note that the spam meeting has apparently been moved
>from Continental 8/9 to Continental 6.
>
>Philip Guenther
>
>  
>
Any offsite/Bar BOF's planned?  I'm in SF, and keen to attend, but I'm 
not keen to register just to come to one meeting.  

Also, I heard no response to
http://www.imc.org/ietf-mta-filters/mail-archive/msg02584.html
*Progressing draft-melnikov-sieve-imapflags-04
<http://www.imc.org/ietf-mta-filters/mail-archive/msg02584.html>*
How's the imapflags draft going? (Paging Alexey Melnikov...)

--------------060307040300000908070007
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Philip Guenther wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">I wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">We will be meeting to talk about sieve and sieve extensions (especially
those in draft: regexp, body, spamtest) after the spam meeting on
Thursday, at 11:30am, in the back of Continental 8/9.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
As a heads up, I note that the spam meeting has apparently been moved
from Continental 8/9 to Continental 6.

Philip Guenther

  </pre>
</blockquote>
Any offsite/Bar BOF's planned? &nbsp;I'm in SF, and keen to attend, but I'm
not keen to register just to come to one meeting. &nbsp;<br>
<br>
Also, I heard no response to <br>
<a class="moz-txt-link-freetext" href="http://www.imc.org/ietf-mta-filters/mail-archive/msg02584.html">http://www.imc.org/ietf-mta-filters/mail-archive/msg02584.html</a><br>
<strong><a name="02584"
 href="http://www.imc.org/ietf-mta-filters/mail-archive/msg02584.html">Progressing
draft-melnikov-sieve-imapflags-04<br>
</a></strong><br>
How's the imapflags draft going? (Paging Alexey Melnikov...)<br>
</body>
</html>

--------------060307040300000908070007--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K45kE03565 for ietf-mta-filters-bks; Wed, 19 Mar 2003 20:05:46 -0800 (PST)
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K45jg03561 for <[e-mail]>; Wed, 19 Mar 2003 20:05:45 -0800 (PST)
Received: by mail-green.research.att.com (Postfix, from userid 612) id 6DB8F1D7440; Wed, 19 Mar 2003 23:06:37 -0500 (EST)
Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mail-green.research.att.com (Postfix) with ESMTP id DE4C71D741A; Wed, 19 Mar 2003 23:06:36 -0500 (EST)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h2K45GVq023931; Wed, 19 Mar 2003 23:05:16 -0500 (EST)
From: Bill Fenner <[e-mail]>
Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h2K45gE26628; Wed, 19 Mar 2003 20:05:42 -0800 (PST)
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail]
Subject: Re: is it allowed to discuss client side filtering here?
Cc: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 19 Mar 2003 20:05:41 -0800
Versions: dmail (solaris) 2.5a/makemail 2.9d
X-Spam-Status: No, hits=-113.1 required=5.0 tests=BAYES_01,REFERENCES,USER_IN_WHITELIST autolearn=ham	version=2.50
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I did some work hooking up the CMU sieve implementation with the UW
imap code; I did not finish it because it turned out my IMAP server
munged all the headers that I wanted to filter on.  If someone would
find it useful and wants to finish it off I'd be happy to pass it on.

  Bill


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K3jLT03198 for ietf-mta-filters-bks; Wed, 19 Mar 2003 19:45:21 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K3jKg03194 for <[e-mail]>; Wed, 19 Mar 2003 19:45:20 -0800 (PST)
Received: from wl-135-225.wireless.ietf56.ietf.org (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id WAA17805; Wed, 19 Mar 2003 22:41:53 -0500 (EST)
Date: Wed, 19 Mar 2003 19:45:14 -0800
From: Cyrus Daboo <[e-mail]>
To: Tim Showalter <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: is it allowed to discuss client side filtering here?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.0.3 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Tim,

--On Wednesday, March 19, 2003 6:43 PM -0800 Tim Showalter 
<[e-mail]> wrote:

| I know there would be interest in client-side Sieve filtering, but I
| don't know anyone who has really worked on it.

Our client does have both client-side filtering support and SIEVE support 
(via ManageSIEVE for uploading to the server). Right now SIEVE is not as 
'expressive' as client-side filters need to be - regex, body etc would go a 
long way to help with that.  Certainly to be effective we would need to at 
least add a 'flagtest' test for testing flag status on the message being 
processed. There are also other client-specific actions that need to be 
considered - e.g. print, save, alert etc. We would also have to define what 
things like 'discard' mean in the context of a client-side filter. That may 
well depend on when the filter is being invoked (e.g. on new mail delivery, 
on message copy, on new mail arrival etc).

I have been considering adding our own private XML rules/filter 
import/export capability which would be expressive enough to capture 
client-side filters and SIEVE. Being able to use a client-side sieve script 
that would be portable between clients would be good too.

| Personally I'd love if there was a Sieve implementation that had an
| externally procmail-like interface, and mailbox names could be file names.



-- 
Cyrus Daboo


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K3Ykk02945 for ietf-mta-filters-bks; Wed, 19 Mar 2003 19:34:46 -0800 (PST)
Received: from toq8-srv.bellnexxia.net ([209.226.175.204]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K3Yig02939 for <[e-mail]>; Wed, 19 Mar 2003 19:34:44 -0800 (PST)
Received: from ensemble.local ([64.229.89.113]) by tomts19-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 19 Mar 2003 22:34:15 -0500
Received: from ensemble.local (localhost [127.0.0.1]) by ensemble.local (8.12.7/8.12.6) with ESMTP id h2K3YBOn010676 for <[e-mail]>; Wed, 19 Mar 2003 22:34:11 -0500 (EST)
Received: (from sam@localhost) by ensemble.local (8.12.7/8.12.2/Submit) id h2K3YBFN010675 for [e-mail]; Wed, 19 Mar 2003 22:34:11 -0500 (EST)
X-Authentication-Warning: ensemble.local: sam set sender to [e-mail] using -f
Date: Wed, 19 Mar 2003 22:34:11 -0500
From: Sam Roberts <[e-mail]>
To: [e-mail]
Subject: Re: is it allowed to discuss client side filtering here?
Message-ID: <[e-mail].>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Checkout GNU mailutils.

It has a sieve engine, and that engine will sieve mailboxes, and you can
specify the mailboxes as:

 imap://[e-mail]
 ~/mbox
 +some_mbox

Cheers,
Sam

Quoteing [e-mail], on Wed, Mar 19, 2003 at 06:43:06PM -0800:
> 
> >
> >
> >I'd love to give my software a SIEVE grammar front-end,
> >but I somehow fear the effort.
> >
> >----------
> >
> >Does somebody want to discuss this?
> > 
> >
> I know there would be interest in client-side Sieve filtering, but I 
> don't know anyone who has really worked on it.
> 
> Personally I'd love if there was a Sieve implementation that had an 
> externally procmail-like interface, and mailbox names could be file names.
> 
> Tim
> 
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K2fI301823 for ietf-mta-filters-bks; Wed, 19 Mar 2003 18:41:18 -0800 (PST)
Received: from sift.mirapoint.com (IDENT:[e-mail] [63.107.133.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K2fGg01819 for <[e-mail]>; Wed, 19 Mar 2003 18:41:16 -0800 (PST)
Received: from mirapoint.com (gw.mirapoint.com [63.107.133.2]) by sift.mirapoint.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABP22060; Wed, 19 Mar 2003 18:40:35 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 19 Mar 2003 18:43:06 -0800
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030304
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: is it allowed to discuss client side filtering here?
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>
>
>I'd love to give my software a SIEVE grammar front-end,
>but I somehow fear the effort.
>
>----------
>
>Does somebody want to discuss this?
>  
>
I know there would be interest in client-side Sieve filtering, but I 
don't know anyone who has really worked on it.

Personally I'd love if there was a Sieve implementation that had an 
externally procmail-like interface, and mailbox names could be file names.

Tim




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K11JQ25904 for ietf-mta-filters-bks; Wed, 19 Mar 2003 17:01:19 -0800 (PST)
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K11Hg25900 for <[e-mail]>; Wed, 19 Mar 2003 17:01:17 -0800 (PST)
Received: from oceana.com (ny-kenton4a-b-98.buf.adelphia.net [24.51.29.98]) (authenticated bits=0) by eagle.oceana.com (8.12.8/8.12.8) with ESMTP id h2K114hI028751 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 19 Mar 2003 20:01:11 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 19 Mar 2003 20:01:03 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: [e-mail]
Subject: Re: sieve lunch @IETF 56
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Philip Guenther wrote:
> 
> I wrote:
> >We will be meeting to talk about sieve and sieve extensions (especially
> >those in draft: regexp, body, spamtest) after the spam meeting on
> >Thursday, at 11:30am, in the back of Continental 8/9.
> 
> As a heads up, I note that the spam meeting has apparently been moved
> from Continental 8/9 to Continental 6.

I can be available on Jabber to discuss regex if you tell me which
"room" to join.  Perhaps someone can track down Marshall Rose and see if
he can get an mta-filters room created.  Either way, please post any
notes from the meeting to the list.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K0M6Z24131 for ietf-mta-filters-bks; Wed, 19 Mar 2003 16:22:06 -0800 (PST)
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K0M4g24127 for <[e-mail]>; Wed, 19 Mar 2003 16:22:05 -0800 (PST)
Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2K0M7815043 for <[e-mail]>; Wed, 19 Mar 2003 16:22:07 -0800 (PST)
Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h2K0NZV09251 for <[e-mail]>; Wed, 19 Mar 2003 16:23:35 -0800 (PST)
Message-Id: <[e-mail]>
From: Philip Guenther <[e-mail]>
To: [e-mail]
Subject: Re: sieve lunch @IETF 56 
In-reply-to: <[e-mail]> 
References: <[e-mail]> 
Date: Wed, 19 Mar 2003 16:05:34 -0800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I wrote:
>We will be meeting to talk about sieve and sieve extensions (especially
>those in draft: regexp, body, spamtest) after the spam meeting on
>Thursday, at 11:30am, in the back of Continental 8/9.

As a heads up, I note that the spam meeting has apparently been moved
from Continental 8/9 to Continental 6.

Philip Guenther


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K0FV824019 for ietf-mta-filters-bks; Wed, 19 Mar 2003 16:15:31 -0800 (PST)
Received: from vementry.enterprise.ucs.ed.ac.uk (vementry.enterprise.ucs.ed.ac.uk [129.215.200.96]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K0FSg24015 for <[e-mail]>; Wed, 19 Mar 2003 16:15:28 -0800 (PST)
Received: from nigelhome (unverified [80.195.14.206]) by vementry.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.2.5) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 20 Mar 2003 00:15:02 +0000
Message-ID: <008501c2ee76$13130380$ce0ec350@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: extensions and sieve
Date: Thu, 20 Mar 2003 00:17:20 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Here's a hasty first draft:
>
> Test mimeheader
>
>    Syntax: mimeheader [:param <params:string-list>] [COMPARATOR]
[MATCH-TYPE]
>              <header-names: string-list> <key-list: string-list>
>
>    The "mimeheader" test evaluates to true if any of the values of
>    the named MIME headers match any of the keys.  The type of match
>    is specified by the optional [MATCH-TYPE] argument, which defaults
>    to ":is", as specified in section 2.6 of [SIEVE].

Given that I won't be in San Fransisco for tommorow's 11:30am meeting, I
thought I'd throw in my 2p (or should I say 2cents) and say that I like
Jutta's draft.  It solves part of the problem that my cheap and dirty
"x_body" test offers :o)

However I think I preferred my "recursive" extension that I suggested in
http://www.imc.org/ietf-mta-filters/mail-archive/msg01070.html.  Nobody
seemed to respond to that suggestion (perhaps cos you all hated it?).  Mime
structure is pretty recursive after all....

So I'd recon we should have two extensions:

:param - which allows you to split off this stuff
    *(token / <tspecial other than ;>) *(; name=value)

    [We should allow some way of matching only the "token" bit, so if the
header is:
        Content-Type: text/plain;  charset="US-ASCII"
    Then we only match the "text/plain" bit.  Maybe a blank param?  ie
:param "" ?]

:recursive - which operates recursively on main mail headers through to all
body part headers, but could also apply to the exists and size tests too.

Ideally you'd be able to have some kind of "select" test that would select a
body part, then filter on only that content.  Maybe a "with".  So rather
than the "allof" test that looks for a message that matches all criteria,
the "with" would look for a single body part that matches all the criteria.
So you could say:

    if with (header :recursive :param "charset" :is "Content-Type"
"US-ASCII",
                header :recursive :param "" :contains "Content-Type" "text",
                body :contains "sex")
        {}

It seems like we really want to get our body and our header tests all
working well together rather than in isolation.  Hope you have a productive
meeting tommorow!

Cheers

Nigel



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JN6rJ20809 for ietf-mta-filters-bks; Wed, 19 Mar 2003 15:06:53 -0800 (PST)
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JN6qg20805 for <[e-mail]>; Wed, 19 Mar 2003 15:06:52 -0800 (PST)
Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JN6s808057 for <[e-mail]>; Wed, 19 Mar 2003 15:06:54 -0800 (PST)
Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h2JN8MV00800 for <[e-mail]>; Wed, 19 Mar 2003 15:08:22 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: sieve lunch @IETF 56
Date: Wed, 19 Mar 2003 14:50:21 -0800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We will be meeting to talk about sieve and sieve extensions (especially
those in draft: regexp, body, spamtest) after the spam meeting on
Thursday, at 11:30am, in the back of Continental 8/9.

Philip Guenther


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IKllg04865 for ietf-mta-filters-bks; Tue, 18 Mar 2003 12:47:47 -0800 (PST)
Received: from esslingen.shuttle.de (esslingen.shuttle.de [194.95.249.240]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IKlfg04861 for <[e-mail]>; Tue, 18 Mar 2003 12:47:41 -0800 (PST)
Received: by esslingen.shuttle.de (Postfix, from userid 11573) id 4BA687F7C; Tue, 18 Mar 2003 21:47:43 +0100 (MET)
To: [e-mail]
Subject: is it allowed to discuss client side filtering here?
Organization: Hayek@Berlin
Reply-To: [e-mail]
From: [e-mail]
X-Attribution: JoHa
References: <[e-mail]> <[e-mail]>
Date: Tue, 18 Mar 2003 21:47:39 +0100
Message-ID: <[e-mail]>
User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alright, I was "welcomed" with a message says this:

    [...]
    The ietf-mta-filters mailing list is used 
    to discuss and develop open standards
    for server-side filtering of mail
    in the SMTP->delivery->[mailstore/IMAP] loop.
    [...]

>>>>> On Sat, 11 Jan 97 17:06:43 PST,
>>>>> Neal McBurnett
>>>>> (whose comments are cited below with "    BOF-19961212> "),
>>>>> had this to say in article <[e-mail]>
>>>>> concerning the subject of minutes for the filtering meeting...

    BOF-19961212> Here is a copy of the minutes of the mail filtering ("anti-spam") BOF
    BOF-19961212> at the 37th IETF meeting in San Jose, Thu 12 Dec 1996.

    BOF-19961212> [...]
    BOF-19961212> - Seattle BOF did not want to consider client side filtering
    BOF-19961212> [...]

Well, if you regard the discussion of client side filtering here
as "not allowed" pls skip the rest!

>From the 1998 SIEVE draft:

    [...]
    It is designed to be independent of protocol,
    and implementable on either a mail client or mail server.  
    [...]
    This document  doesn't dictate how SIEVE interpreter
    can set [IMAP] flags. 
    In particular, SIEVE interpreter may work as an IMAP client,
    or may have direct access to the mailstore.
    [...]

>From draft-melnikov-sieve-imapflags-04.txt:

    [...]
    In particular, the SIEVE interpreter may work as an IMAP client,
    or may have direct access to the mailstore.
    [...]

I browsed through the entire archive of this mailing list ("entire-arch.txt"),
but I could not find a hint on any existing client side implementation.

Did I miss anything?

>>>>> On Mon, 12 Jan 1998 16:28:19 -0700 (MST),
>>>>> Lyndon Nerenberg
>>>>> who can be reached at: [e-mail]
>>>>> (whose comments are cited below with "    LN> "),
>>>>> had this to say in article <[e-mail]>
>>>>> concerning the subject of Re: MTA Filters BOF request, LA IETF; Proposed Charter

    LN> [...]

    LN> Procmail is a very dangerous thing in the wrong hands.
    LN> The fact that people use these dangerous tools
    LN> regardless tells me there is a requirement for the functionality.
 
    LN> [...]

    LN> Having a standard language means 
    LN> that I can reuse the same ruleset on different clients
    LN>  -- a *very* important criteria for mobile users 
    LN> who have no choice
    LN> but to use disparate UA's 
    LN> when on the road vs. being at the office.
 
    LN> [...]

Because I also could not find any client side SIEVE implementation a couple of years ago,
I started an effort then myself,
that I "modestly" ;-)     called "JHimap_utils".
A python script (making use of somebody else's IMAP interface library),
implementing a couple of utilities,
mainly for move messages from the IMAP INBOX to whatever other IMAP folder
depending on header fields.

I seriously needed such a thing then,
as my "IMAP providers" then did not let me make use of procmail.

My current "IMAP" provider provides me with a UNIX account
(they let me do IMAP with pre-authentication over ssh!),
and they let me use procmail for server side mail splitting.

Actually there would *not* be an urgent need for me
to address this issue these days,
as I got a lot of other issues to care for,
but somebody picked my software (mentioned above) up on the web
and keeps asking me questions,
so that thing awoke again somehow.

----------

What's the current status on client side mail splitting these days?

----------

I'd love to give my software a SIEVE grammar front-end,
but I somehow fear the effort.

----------

Does somebody want to discuss this?

JH


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ELZf306325 for ietf-mta-filters-bks; Fri, 14 Mar 2003 13:35:41 -0800 (PST)
Received: from server2.fastmail.fm (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ELZeg06317 for <[e-mail]>; Fri, 14 Mar 2003 13:35:40 -0800 (PST)
Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id 62B3B26AC4 for <[e-mail]>; Fri, 14 Mar 2003 16:35:40 -0500 (EST)
Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Fri, 14 Mar 2003 16:35:40 -0500
X-Epoch: 1047677740
X-Sasl-enc: 7kQFIdx/x/tOLyuGaDvUGQ
Received: from elvey.com (adsl-64-165-199-135.dsl.snfc21.pacbell.net [64.165.199.135]) by www.fastmail.fm (Postfix) with ESMTP id 3224B22606 for <[e-mail]>; Fri, 14 Mar 2003 16:35:39 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 14 Mar 2003 13:36:19 -0800
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Progressing draft-melnikov-sieve-imapflags-04
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Five suggestions to the draft.  

Way back On Tue, 2002-07-16, Tim Showalter wrote:

>Cyrus Daboo wrote:
>> 
>> | Tim thought that in order to do this right, we need to introduce
>> | variables in Sieve.
>> | So I am waiting for either:
>> | 1). draft that adds Sieve variables
>> | 2). a desire to standardize draft-melnikov-sieve-imapflags-04.txt as is
>> | (with an implicit variable).
>> 
>> One option might be to get rid of the ':globalflags...' tagged arguments 
>> and all the actions and instead only rely on the ':flags' tagged argument 
>> for fileinto and keep. I believe that gets rid of the need to have any 
>> variables during the lifetime of the script, and provides a basic 
>> implementation that can be built on later if variables are introduced.
>
>I agree with this.  :globalflags mostly bothered me with respect to
>variables.
>

Suggestion 1:

I suggest :globalflags not be removed at least unless a draft and 
implementation adding Sieve variables is well underway.
-As Ken has said, being able to set a flag once is useful, 
 and with variables, something like 

   keep [VariableName, "\\Answered", "$MDNSent"]; 

would work.  

This example makes a complexity of variables evident though - could VariableName be a string-list?  
Adding variables isn't trivial.




Suggestion 2, regarding 3.4, quoted below (Of course, if all implicit 
variables are to done away with, 3.4 mark and unmark would need to go 
too, so these changes are moot.):

3.4. Mark and Unmark Actions

   Syntax:   mark

   Syntax:   unmark

   The mark action allows a message to be marked as urgent. Conformant implementation MUST
   set \Flagged [IMAP] flag, but MAY also set other [IMAP] flags as well. Thus the mark  action is
   semantically equivalent to 'addflag "\\Flagged"'.

   The unmark action allows the flag previously  set  by  the Mark action to be unset.
   Unmark MUST unset the [IMAP] \Flagged flag and all other flags that could be added with mark.
   Unmark MUST NOT unset any other flags. This means that the following script does nothing:

      mark;
      unmark;

   The unmark action is semantically equivalent to 'removeflag "\\Flagged"'.

Several little problems: if mark sets more than one flag, 
then the last sentence is false.  If the message is already marked, then 
mark; unmark; does SOMETHING.  It Removes the flag(s) the first mark set.  
Does the \Flagged flag necessarily imply the message is "urgent", 
as the first sentence claims? 
Also, why would mark want to set other flags?
Lastly, unmark cannot unset flags other than \Flagged set by other 
implementations, because it cannot know what they are.

Suggested replacement text:

3.4. Mark and Unmark Actions

   Syntax:   mark

   Syntax:   unmark

   The mark action allows a message to be marked. Conformant implementation MUST
   set \Flagged [IMAP] flag, but MAY also set other [IMAP] flags as well.  
 

   The unmark action allows the flag previously set by the Mark action to be unset.
   Unmark MUST unset the [IMAP] \Flagged flag and all other flags that could be added with mark by the implementation.
   Unmark MUST NOT unset any other flags. 


Suggestion 3:
IMHO, the RFC would be useful if the following was added:

I would follow the sentence in 5. "The SIEVE interpreter MUST ignore these
   commands when no keep (implicit or explicit) or fileinto actions will be taken."
with "Thus, for example, scripts should set flags before fileinto, not after!"

Why: it's non-obvious to sieve script writers, who get caught by this 'gotcha'.

#A counterexample:
#The following doesn't make sense: the Seen flag isn't set in any message store, 
#because it isn't followed by a keep or fileinto which would cause it to do so.
#If you want the copy in test1 to be marked as seen, reverse the order of the fileinto 
#and addflag commands.  Perhaps an implementation SHOULD flag this as an error.  
#But perhaps not; I think an implementation couldn't catch all such errors, 
#except at runtime, so trying to catch some isn't very helpful. 
if header "subject" :contains "test1"
{
   fileinto "test1 folder";
   addflag "\\Seen";
   stop;
}



Suggestion 4:

There's a typo : "If non of the 4" should read "If none of the 4"



Suggestion 5:

address :all :contains
                  ["To", "Cc", "Bcc"] "[e-mail] <mailto:[e-mail]>",

is nonsensical; it should be changed to 

address :all :contains
                  ["To", "Cc"] "[e-mail] <mailto:[e-mail]>",

because there is no Bcc header in received email.