Re: spamtest/virustest "NIL" behaviour

["Nigel Swinson" <[e-mail]>]

> I did just think of one other state that might be interesting to enumerate
> and that is 'virus was detected but removed - message is now safe'. That
> could simply be handled as a comment in the 'text' part of the result, or
> by inserting it into the enumeration at index 1. I know a number of
> anti-virus tools are able to 'clean' messages and being able to detect
that
> in sieve might be useful. Would this be useful to add?
>
> I do think virustest should be restricted to a very limited set of values
> as the potential for damage caused by letting some through is much more
> significant than spamtest.

Well with the F-Secure scanner (the one I'm most familiar with) the possible
return values are:

- Valid,
- Infected,
- Cured, (The sent content was disinfected.)
- Replaced, (The sent content is infected. The server replaced the original
content.)
- Error.

And probably add to that:

- Untested

So somehow I gotta map to the virustest values....   so I guess if we have

> >0 - definitely clear of viruses
> >1 - possibly contains a virus/unchecked
> >2 - definitely contains a virus

Then I could map valid, cured and replaced to 0, infected to 2, and error
and untested to 1.  I suppose we could move to:

0 - contains no known viruses
1 - contained a known virus but the virus was replaced with harmless content
2 - contained a known virus but the conent was "cured" such that it is now
harmless
3 - possibly contains a virus
4 - unchecked
5 - definately contains a known virus.

But it's not clear to be that the above is the right order, but separating
them all is at least explicit, but then what if we get new results in the
future?  I'm happy enough with the three values and using the string part to
work out if it was cured/replaced, or possibly/unchecked.

On a related point, the draft shouldn't say:

    The virustest result is a string starting with a numeric value in
    the range "0" (zero) through "2", with "0" meaning the message is
    definitely clear of viruses, ....

As you can only say "clear of all known viruses given the set of AV updates
currently deployed".  (sorry if this point has been made already :o/ )

Nigel



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UJNKi2092111 for <[e-mail]>; Wed, 30 Apr 2003 12:23:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UJNKuX092110 for ietf-mta-filters-bks; Wed, 30 Apr 2003 12:23:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UJNEi2092103 for <[e-mail]>; Wed, 30 Apr 2003 12:23:19 -0700 (PDT) (envelope-from [e-mail])
Received: from nigelhome (unverified [80.195.14.206]) by starship.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.3.3) with ESMTP id <[e-mail]>; Wed, 30 Apr 2003 20:22:15 +0100
Message-ID: <059001c30f4e$60f43a30$6401a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <04a001c30f13$f2d95330$6401a8c0@nigelhome> <[e-mail]> <2147483647.1051709264@[63.163.82.24]> <053601c30f42$16467400$6401a8c0@nigelhome> <2147483647.1051711803@[63.163.82.24]>
Subject: Re: spamtest/virustest "NIL" behaviour
Date: Wed, 30 Apr 2003 20:26:20 +0100
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.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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 just think of one other state that might be interesting to enumerate
> and that is 'virus was detected but removed - message is now safe'. That
> could simply be handled as a comment in the 'text' part of the result, or
> by inserting it into the enumeration at index 1. I know a number of
> anti-virus tools are able to 'clean' messages and being able to detect
that
> in sieve might be useful. Would this be useful to add?
>
> I do think virustest should be restricted to a very limited set of values
> as the potential for damage caused by letting some through is much more
> significant than spamtest.

Well with the F-Secure scanner (the one I'm most familiar with) the possible
return values are:

- Valid,
- Infected,
- Cured, (The sent content was disinfected.)
- Replaced, (The sent content is infected. The server replaced the original
content.)
- Error.

And probably add to that:

- Untested

So somehow I gotta map to the virustest values....   so I guess if we have

> >0 - definitely clear of viruses
> >1 - possibly contains a virus/unchecked
> >2 - definitely contains a virus

Then I could map valid, cured and replaced to 0, infected to 2, and error
and untested to 1.  I suppose we could move to:

0 - contains no known viruses
1 - contained a known virus but the virus was replaced with harmless content
2 - contained a known virus but the conent was "cured" such that it is now
harmless
3 - possibly contains a virus
4 - unchecked
5 - definately contains a known virus.

But it's not clear to be that the above is the right order, but separating
them all is at least explicit, but then what if we get new results in the
future?  I'm happy enough with the three values and using the string part to
work out if it was cured/replaced, or possibly/unchecked.

On a related point, the draft shouldn't say:

    The virustest result is a string starting with a numeric value in
    the range "0" (zero) through "2", with "0" meaning the message is
    definitely clear of viruses, ....

As you can only say "clear of all known viruses given the set of AV updates
currently deployed".  (sorry if this point has been made already :o/ )

Nigel



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UIlZi2090844 for <[e-mail]>; Wed, 30 Apr 2003 11:47:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UIlZN7090843 for ietf-mta-filters-bks; Wed, 30 Apr 2003 11:47:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UIlXi2090838 for <[e-mail]>; Wed, 30 Apr 2003 11:47:34 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 30 Apr 2003 11:47:27 -0700 (PDT)
Date: Wed, 30 Apr 2003 11:47:13 -0700 (PDT)
From: [e-mail]
Subject: Re: spamtest/virustest "NIL" behaviour
In-reply-to: "Your message dated Wed, 30 Apr 2003 11:17:59 -0700" <[e-mail]>
To: Jutta Degener <[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: <04a001c30f13$f2d95330$6401a8c0@nigelhome> <[e-mail]> <2147483647.1051709264@[63.163.82.24]> <[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>

> On Wed, Apr 30, 2003 at 10:48:04AM -0700, [e-mail] quoted:
> > >It may be OK to do that for spamtest, but I don't think its valid for
> > >virustest. What we could do is:
> >
> > >spamtest value:
> >
> > >0 - unchecked
> > >1 - definitely clear of spam
> > >...
> > >10 - definitely contains spam
> >
> > >virustest value:
> >
> > >0 - definitely clear of viruses
> > >1 - possibly contains a virus/unchecked
> > >2 - definitely contains a virus
> >
> > >That would eliminate NIL entirely.
> >
> > I like it -- the current situation where NIL sorts at the end is very
> > awkward.
> > What do other people think?

> Looks like a workable compromise that'll make the world a little safer.
> Are we keeping the NIL suffix?  Otherwise I'd ask to have a virustest
> number reserved only for untested messages (not for a mix of untested
> and unclear).

Keeping the suffix is fine with me.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UIIIi2090074 for <[e-mail]>; Wed, 30 Apr 2003 11:18:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UIIH99090073 for ietf-mta-filters-bks; Wed, 30 Apr 2003 11:18:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UIIGi2090067 for <[e-mail]>; Wed, 30 Apr 2003 11:18:17 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3UIIHFe005930 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Wed, 30 Apr 2003 11:18:17 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3UIIHqu018654 for <[e-mail]>; Wed, 30 Apr 2003 11:18:17 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 40820179BB; Wed, 30 Apr 2003 11:17:59 -0700 (PDT)
Date: Wed, 30 Apr 2003 11:17:59 -0700
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: Re: spamtest/virustest "NIL" behaviour
Message-ID: <[e-mail]>
References: <04a001c30f13$f2d95330$6401a8c0@nigelhome> <[e-mail]> <2147483647.1051709264@[63.163.82.24]> <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3UIIHqu018654
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 Wed, Apr 30, 2003 at 10:48:04AM -0700, [e-mail] quoted:
> >It may be OK to do that for spamtest, but I don't think its valid for
> >virustest. What we could do is:
> 
> >spamtest value:
> 
> >0 - unchecked
> >1 - definitely clear of spam
> >...
> >10 - definitely contains spam
> 
> >virustest value:
> 
> >0 - definitely clear of viruses
> >1 - possibly contains a virus/unchecked
> >2 - definitely contains a virus
> 
> >That would eliminate NIL entirely.
> 
> I like it -- the current situation where NIL sorts at the end is very 
> awkward.
> What do other people think?

Looks like a workable compromise that'll make the world a little safer.
Are we keeping the NIL suffix?  Otherwise I'd ask to have a virustest
number reserved only for untested messages (not for a mix of untested
and unclear).

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UIAji2089861 for <[e-mail]>; Wed, 30 Apr 2003 11:10:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UIAj4c089860 for ietf-mta-filters-bks; Wed, 30 Apr 2003 11:10:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UIAii2089853 for <[e-mail]>; Wed, 30 Apr 2003 11:10:44 -0700 (PDT) (envelope-from [e-mail])
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA23071; Wed, 30 Apr 2003 14:06:35 -0400 (EDT)
Date: Wed, 30 Apr 2003 14:10:03 -0400
From: Cyrus Daboo <[e-mail]>
To: Nigel Swinson <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: spamtest/virustest "NIL" behaviour
Message-ID: <2147483647.1051711803@[63.163.82.24]>
In-Reply-To: <053601c30f42$16467400$6401a8c0@nigelhome>
References: <04a001c30f13$f2d95330$6401a8c0@nigelhome> <[e-mail]> <2147483647.1051709264@[63.163.82.24]> <053601c30f42$16467400$6401a8c0@nigelhome>
X-Mailer: Mulberry/3.1.0b1 (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 Nigel,

--On Wednesday, April 30, 2003 6:58 PM +0100 Nigel Swinson 
<[e-mail]> wrote:

|> virustest value:
|>
|> 0 - definitely clear of viruses
|> 1 - possibly contains a virus/unchecked
|> 2 - definitely contains a virus
|>
|> That would eliminate NIL entirely.
|
| Sounds good to me too :o)
|
| I do wonder though if we should just use 0-10 for virustest too, so that
| it's the same range as spam test.  It might be more "intuative" to users.
| So you'd have varying degrees of suspicion.  If implementations just map
| to the values 0, 5 and 10 then that's fine, but I don't know if there are
| anti virus implementations that give a "score" in the same way as anti
| spam does... or will there be such an implementation in the future?  Just
| an idea... I'm not completely sold on it myself I have to say.

I did just think of one other state that might be interesting to enumerate 
and that is 'virus was detected but removed - message is now safe'. That 
could simply be handled as a comment in the 'text' part of the result, or 
by inserting it into the enumeration at index 1. I know a number of 
anti-virus tools are able to 'clean' messages and being able to detect that 
in sieve might be useful. Would this be useful to add?

I do think virustest should be restricted to a very limited set of values 
as the potential for damage caused by letting some through is much more 
significant than spamtest.

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHxGi2089431 for <[e-mail]>; Wed, 30 Apr 2003 10:59:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UHxG2C089430 for ietf-mta-filters-bks; Wed, 30 Apr 2003 10:59:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHxFi2089423 for <[e-mail]>; Wed, 30 Apr 2003 10:59:15 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3UHxFFe004073 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Wed, 30 Apr 2003 10:59:16 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3UHxFqu016002 for <[e-mail]>; Wed, 30 Apr 2003 10:59:15 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 7EB46179BB; Wed, 30 Apr 2003 10:58:57 -0700 (PDT)
Date: Wed, 30 Apr 2003 10:58:57 -0700
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: Re: variables: greedy or non-greedy matching
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3UHxFqu016002
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 Tue, Apr 29, 2003 at 06:01:19PM -0700, [e-mail] wrote:
> > [Ned Freed]:
> > >
> > >   [Jutta Degener]:
> > >   > So let's stay greedy; thanks for setting me straight!
> > >
> > >   No problem ;-) And let's also remember that a necessary corollary
> > >   here is that the regexp we end up choosing needs to support both
> > >   greedy and non-greedy matching.
> 
> > why?  I thought we only needed that if :matches was non-greedy.
> 
> > I wouldn't mind having non-greedy regexps, but they're not in POSIX.2
> > which the regex draft refers to.
> 
> Jutta's argument, which I believe is valid, is that expectations can only
> be met by having both types available.

Most cases of it can also be met with character classes.

That's why I said "let's stay greedy" in the piece you quote above --
I realized that I wanted to solve problems with non-greed that can
be solved with regexes.

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHtJi2089120 for <[e-mail]>; Wed, 30 Apr 2003 10:55:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UHtJAC089119 for ietf-mta-filters-bks; Wed, 30 Apr 2003 10:55:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHtHi2089108 for <[e-mail]>; Wed, 30 Apr 2003 10:55:17 -0700 (PDT) (envelope-from [e-mail])
Received: from nigelhome (unverified [80.195.14.206]) by starship.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.3.3) with ESMTP id <[e-mail]>; Wed, 30 Apr 2003 18:54:16 +0100
Message-ID: <053601c30f42$16467400$6401a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>, "Cyrus Daboo" <[e-mail]>
Cc: <[e-mail]>
References: <04a001c30f13$f2d95330$6401a8c0@nigelhome> <[e-mail]> <2147483647.1051709264@[63.163.82.24]>
Subject: Re: spamtest/virustest "NIL" behaviour
Date: Wed, 30 Apr 2003 18:58:20 +0100
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.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

> It may be OK to do that for spamtest, but I don't think its valid for
> virustest. What we could do is:
>
> spamtest value:
>
> 0 - unchecked
> 1 - definitely clear of spam
> ...
> 10 - definitely contains spam
>
> virustest value:
>
> 0 - definitely clear of viruses
> 1 - possibly contains a virus/unchecked
> 2 - definitely contains a virus
>
> That would eliminate NIL entirely.

Sounds good to me too :o)

I do wonder though if we should just use 0-10 for virustest too, so that
it's the same range as spam test.  It might be more "intuative" to users.
So you'd have varying degrees of suspicion.  If implementations just map to
the values 0, 5 and 10 then that's fine, but I don't know if there are anti
virus implementations that give a "score" in the same way as anti spam
does... or will there be such an implementation in the future?  Just an
idea... I'm not completely sold on it myself I have to say.

Nigel



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHnRi2088055 for <[e-mail]>; Wed, 30 Apr 2003 10:49:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UHnRn3088054 for ietf-mta-filters-bks; Wed, 30 Apr 2003 10:49:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHnPi2088042 for <[e-mail]>; Wed, 30 Apr 2003 10:49:26 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 30 Apr 2003 10:49:18 -0700 (PDT)
Date: Wed, 30 Apr 2003 10:48:04 -0700 (PDT)
From: [e-mail]
Subject: Re: spamtest/virustest "NIL" behaviour
In-reply-to: "Your message dated Wed, 30 Apr 2003 13:27:44 -0400" <2147483647.1051709264@[63.163.82.24]>
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail], Nigel Swinson <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <04a001c30f13$f2d95330$6401a8c0@nigelhome> <[e-mail]> <2147483647.1051709264@[63.163.82.24]>
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 Ned,

> --On Wednesday, April 30, 2003 9:27 AM -0700 [e-mail] wrote:

> |> I'd also suggest that we use a different value to "NIL", perhaps "5 NIL"
> |> so that the 5 is mid range 50/50 spam/virus and the "NIL" as the string
> |> to say that scanning failed to protect users from making the fairly
> |> subtle mistake of treating scan failures as either "definately not spam"
> |> or "definately spam".
> |
> | I dislike assigning a default value in the middle of the range when no
> | check has been done. I guess I could live with making 0 a special "no
> | check has been done" value.

> It may be OK to do that for spamtest, but I don't think its valid for
> virustest. What we could do is:

> spamtest value:

> 0 - unchecked
> 1 - definitely clear of spam
> ...
> 10 - definitely contains spam

> virustest value:

> 0 - definitely clear of viruses
> 1 - possibly contains a virus/unchecked
> 2 - definitely contains a virus

> That would eliminate NIL entirely.

I like it -- the current situation where NIL sorts at the end is very awkward.
What do other people think?

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHXQi2087270 for <[e-mail]>; Wed, 30 Apr 2003 10:33:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UHXP4w087269 for ietf-mta-filters-bks; Wed, 30 Apr 2003 10:33:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHXOi2087264 for <[e-mail]>; Wed, 30 Apr 2003 10:33:25 -0700 (PDT) (envelope-from [e-mail])
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA22659; Wed, 30 Apr 2003 13:24:15 -0400 (EDT)
Date: Wed, 30 Apr 2003 13:27:44 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail], Nigel Swinson <[e-mail]>
cc: [e-mail]
Subject: Re: spamtest/virustest "NIL" behaviour
Message-ID: <2147483647.1051709264@[63.163.82.24]>
In-Reply-To: <[e-mail]>
References: <04a001c30f13$f2d95330$6401a8c0@nigelhome> <[e-mail]>
X-Mailer: Mulberry/3.1.0b1 (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 Ned,

--On Wednesday, April 30, 2003 9:27 AM -0700 [e-mail] wrote:

|> I'd also suggest that we use a different value to "NIL", perhaps "5 NIL"
|> so that the 5 is mid range 50/50 spam/virus and the "NIL" as the string
|> to say that scanning failed to protect users from making the fairly
|> subtle mistake of treating scan failures as either "definately not spam"
|> or "definately spam".
|
| I dislike assigning a default value in the middle of the range when no
| check has been done. I guess I could live with making 0 a special "no
| check has been done" value.

It may be OK to do that for spamtest, but I don't think its valid for 
virustest. What we could do is:

spamtest value:

0 - unchecked
1 - definitely clear of spam
...
10 - definitely contains spam

virustest value:

0 - definitely clear of viruses
1 - possibly contains a virus/unchecked
2 - definitely contains a virus

That would eliminate NIL entirely.

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHMJi2086424 for <[e-mail]>; Wed, 30 Apr 2003 10:22:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UHMJJn086423 for ietf-mta-filters-bks; Wed, 30 Apr 2003 10:22:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UHMIi2086415 for <[e-mail]>; Wed, 30 Apr 2003 10:22:18 -0700 (PDT) (envelope-from [e-mail])
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA22602; Wed, 30 Apr 2003 13:17:48 -0400 (EDT)
Date: Wed, 30 Apr 2003 13:21:16 -0400
From: Cyrus Daboo <[e-mail]>
To: Nigel Swinson <[e-mail]>, [e-mail]
Subject: Re: spamtest/virustest "NIL" behaviour
Message-ID: <2147483647.1051708876@[63.163.82.24]>
In-Reply-To: <04a001c30f13$f2d95330$6401a8c0@nigelhome>
References:  <04a001c30f13$f2d95330$6401a8c0@nigelhome>
X-Mailer: Mulberry/3.1.0b1 (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 Nigel,

--On Wednesday, April 30, 2003 1:28 PM +0100 Nigel Swinson 
<[e-mail]> wrote:

| When the virus scanner or the anti spam scanner fail, I presume we give
| the spamtest/virustest a "NIL" value as though it never even passed
| through the scanner.  So according to RFC2244, when we use ascii-numeric,
| that seems to imply that "NIL" turns into a very large number.  Is that
| right?

Yes - Ned pointed this out and I did fix the example and add some comments 
about this situation.

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UGUPi2084360 for <[e-mail]>; Wed, 30 Apr 2003 09:30:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UGUP1E084359 for ietf-mta-filters-bks; Wed, 30 Apr 2003 09:30:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UGULi2084351 for <[e-mail]>; Wed, 30 Apr 2003 09:30:23 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 30 Apr 2003 09:30:15 -0700 (PDT)
Date: Wed, 30 Apr 2003 09:27:56 -0700 (PDT)
From: [e-mail]
Subject: Re: spamtest/virustest "NIL" behaviour
In-reply-to: "Your message dated Wed, 30 Apr 2003 13:28:04 +0100" <04a001c30f13$f2d95330$6401a8c0@nigelhome>
To: Nigel Swinson <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <04a001c30f13$f2d95330$6401a8c0@nigelhome>
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>

> In the spamtest/virustest draft there is the following example:

>         if spamtest :value "ge" :comparator "i;ascii-numeric" "3"
>         {
>             fileinto "INBOX.spam-trap";
>         }
>         elsif spamtest :is "NIL"
>         {
>             fileinto "INBOX.unclassified";
>         }

I pointed out that this is broken in an earlier email.

> When the virus scanner or the anti spam scanner fail, I presume we give the
> spamtest/virustest a "NIL" value as though it never even passed through the
> scanner.  So according to RFC2244, when we use ascii-numeric, that seems to
> imply that "NIL" turns into a very large number.  Is that right?

Yes.

> Does that mean that the "NIL" value gets a score of higher than 10 and is
> therefore really really really definately spam/a virus?

Yes.

> Is the example therefore not better written as:

>         if spamtest :is "NIL"
>         {
>             fileinto "INBOX.unclassified";
>         }
>         elsif spamtest :value "ge" :comparator "i;ascii-numeric" "3"
>         {
>             fileinto "INBOX.spam-trap";
>         }

Yes.

> I'd also suggest that we use a different value to "NIL", perhaps "5 NIL" so
> that the 5 is mid range 50/50 spam/virus and the "NIL" as the string to say
> that scanning failed to protect users from making the fairly subtle mistake
> of treating scan failures as either "definately not spam" or "definately
> spam".

I dislike assigning a default value in the middle of the range when no check
has been done. I guess I could live with making 0 a special "no check has been
done" value.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UCU4i2071415 for <[e-mail]>; Wed, 30 Apr 2003 05:30:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UCU4aq071414 for ietf-mta-filters-bks; Wed, 30 Apr 2003 05:30:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UCU2i2071405 for <[e-mail]>; Wed, 30 Apr 2003 05:30:03 -0700 (PDT) (envelope-from [e-mail])
Received: from nigelhome (unverified [80.195.14.206]) by starship.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.3.3) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 30 Apr 2003 13:24:02 +0100
Message-ID: <04a001c30f13$f2d95330$6401a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Subject: spamtest/virustest "NIL" behaviour
Date: Wed, 30 Apr 2003 13:28:04 +0100
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.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

In the spamtest/virustest draft there is the following example:

        if spamtest :value "ge" :comparator "i;ascii-numeric" "3"
        {
            fileinto "INBOX.spam-trap";
        }
        elsif spamtest :is "NIL"
        {
            fileinto "INBOX.unclassified";
        }

When the virus scanner or the anti spam scanner fail, I presume we give the
spamtest/virustest a "NIL" value as though it never even passed through the
scanner.  So according to RFC2244, when we use ascii-numeric, that seems to
imply that "NIL" turns into a very large number.  Is that right?

RFC 2244                          ACAP                     November 1997
      i;ascii-numeric
           Operations: Ordering, Equality

           The i;ascii-numeric comparator interprets strings as decimal
           positive integers represented as US-ASCII digits.  All values
           which do not begin with a US-ASCII digit are considered equal
           with an ordinal value higher than all non-NIL single-valued
           attributes.  Otherwise, all US-ASCII digits (octet values
           0x30 to 0x39) are interpreted starting from the beginning of
           the string to the first non-digit or the end of the string.

That being said, we would never file anything to the "unclassified" folder
as "a very large number" is greater than "3".  Also If we define the
spamtest/virustest values as:

Internet Draft    SIEVE Spamtest and Virustest Extensions    April 2003
    The spamtest result is a string starting with a numeric value in the
    range "0" (zero) through "10", with "0" meaning the message is
    definitely clear of spam, and "10" meaning the message is definitely
    spam.  The underlying SIEVE implementation will map whatever spam
    check is done into this numeric range, as appropriate.  If the
    message has not been categorised by any spam checking tools, then
    the spamtest result is "NIL".

Does that mean that the "NIL" value gets a score of higher than 10 and is
therefore really really really definately spam/a virus?

Is the example therefore not better written as:

        if spamtest :is "NIL"
        {
            fileinto "INBOX.unclassified";
        }
        elsif spamtest :value "ge" :comparator "i;ascii-numeric" "3"
        {
            fileinto "INBOX.spam-trap";
        }

I'd also suggest that we use a different value to "NIL", perhaps "5 NIL" so
that the 5 is mid range 50/50 spam/virus and the "NIL" as the string to say
that scanning failed to protect users from making the fairly subtle mistake
of treating scan failures as either "definately not spam" or "definately
spam".

Or did I misunderstand somewhere.... :o/

Nigel



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UACWi2061538 for <[e-mail]>; Wed, 30 Apr 2003 03:12:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UACWZq061537 for ietf-mta-filters-bks; Wed, 30 Apr 2003 03:12:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UACVi2061531 for <[e-mail]>; Wed, 30 Apr 2003 03:12:31 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19AoZi-0006fj-00 for [e-mail]; Wed, 30 Apr 2003 12:12:30 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Wed, 30 Apr 2003 12:12:30 +0200
To: [e-mail]
Subject: Re: Three new drafts and a question
References: <[e-mail]> <[e-mail]> <01fd01c30e35$08db4830$6401a8c0@nigelhome> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 30 Apr 2003 12:12:30 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 41
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>

[Arnt Gulbrandsen]:
>
>   Kjetil Torgrim Homme writes:
>   > good point. most GUI's will only need to understand their own
>   > Sieve code,
>   
>   Oh?

sorry, I should say "their own idioms".

>   When a program is about to parse a sieve script, it cannot know
>   whether that script was written by itself. Right? That's more or
>   less a design decision. There's nothing like the postscript
>   Creator field in sieve.
>   
>   Because of that, a program cannot enable or disable its 'parse
>   existing sieve script' command depending on who wrote the sieve
>   script.

agreed, it must _always_ give a functionally equivalent
representation.  if you select "lower case Subject" in one editor, it
may emit

    if header :matches "Subject" "*" {
        set :lower "_lc" "${1}";
        deleteheader "Subject";
        addheader "Subject" "${_lc}";
    }

it is OK for a different editor to present this differently, say:

   lower case content of header Subject and store in variable _lc
   delete header Subject
   add header Subject with content from variable _lc

I think most users will stick to one editor, or edit the code
directly, so they will be happy even if it lacks advanced code pattern
matching.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U9ubi2060433 for <[e-mail]>; Wed, 30 Apr 2003 02:56:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U9ubPc060432 for ietf-mta-filters-bks; Wed, 30 Apr 2003 02:56:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U9uZi2060427 for <[e-mail]>; Wed, 30 Apr 2003 02:56:36 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19AoKJ-0004vI-00 for [e-mail]; Wed, 30 Apr 2003 11:56:35 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Wed, 30 Apr 2003 11:56:35 +0200
To: [e-mail]
Subject: Re: Three new drafts and a question
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 30 Apr 2003 11:56:33 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 32
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>

[Marc Mutz]:
>
>   On Wednesday 30 April 2003 01:07, Kjetil Torgrim Homme wrote:
>   > I know you wanted a failed match to not influence the numeric
>   > variables, Ned, it seems like you were right.
>   
>   Well, _obviously_ this particular problem stems from
>   unconditionally executing deleteheader+addheader. The correct way
>   to do this would be:
>   
>   if header :matches "Subject" "[ietf] *" {
>   	deleteheader "Subject";
>   	addheader "Subject" "${1}";
>   }

it is always possible to add code to avoid the problem, e.g.,

   set "oldsubj" "${1}"

the question is which behaviour is more convenient.  my previous
example omitted the classifying test, it could look like this:

   if header :contains "List-ID" "ietf" {
      deleteheader :matches "Subject" "[ietf] *";
      deleteheader :matches "Subject" "Re: [ietf] *";
      addheader "Subject" "${1}";
   }

another test inside the block is a bit more verbose, but it may be
clearer code.
-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U8eHi2056485 for <[e-mail]>; Wed, 30 Apr 2003 01:40:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U8eHwN056484 for ietf-mta-filters-bks; Wed, 30 Apr 2003 01:40:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U8eGi2056473 for <[e-mail]>; Wed, 30 Apr 2003 01:40:16 -0700 (PDT) (envelope-from [e-mail])
Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:22949 "ehlo melkebalanse.gulbrandsen.priv.no" ident: "NO-IDENT-SERVICE[2]") by bra.gulbrandsen.priv.no with ESMTP id <S108587AbTD3IkH>; Wed, 30 Apr 2003 10:40:07 +0200
Message-Id: <[e-mail]>
From: Arnt Gulbrandsen <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Subject: Re: Three new drafts and a question
Cc: [e-mail]
References: <[e-mail]> <[e-mail]> <01fd01c30e35$08db4830$6401a8c0@nigelhome> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Date:   Wed, 30 Apr 2003 10:41:04 +0200
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>

Kjetil Torgrim Homme writes:
> [Ned Freed]:
>
>>    [Nigel Swinson]:
>>
>>    > One other thing to say is complexity for guis.  If the intention
>>    > is to "replace header" and you have to do this via removeheader
>>    > and addheader, then it becomes much more difficult to "extract"
>>    > from the script.
>
> good point. most GUI's will only need to understand their own Sieve code,

Oh?

When a program is about to parse a sieve script, it cannot know whether 
that script was written by itself. Right? That's more or less a design 
decision. There's nothing like the postscript Creator field in sieve.

Because of that, a program cannot enable or disable its 'parse existing 
sieve script' command depending on who wrote the sieve script.

> but it is important that the constructs we provide lend themselves 
> easily to common idioms.

Agree wholeheartedly.

--Arnt


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U8PLi2052853 for <[e-mail]>; Wed, 30 Apr 2003 01:25:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U8PLlO052851 for ietf-mta-filters-bks; Wed, 30 Apr 2003 01:25:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U8PKi2052838 for <[e-mail]>; Wed, 30 Apr 2003 01:25:20 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.0.3 (pD9E11020.dip.t-dialin.net [217.225.16.32]) by max.kde.org (Postfix) with ESMTP id B533CAFC6A for <[e-mail]>; Wed, 30 Apr 2003 10:25:19 +0200 (CEST)
From: Marc Mutz <[e-mail]>
Organization: "Old Europe" - and proud
To: [e-mail]
Subject: Re: Three new drafts and a question
Date: Wed, 30 Apr 2003 10:11:02 +0200
User-Agent: KMail/1.5.9
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_XU4r+KZV4u61h4M"; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <[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>

--Boundary-02=_XU4r+KZV4u61h4M
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Wednesday 30 April 2003 01:22, [e-mail] wrote:
<snip>
> That's not an excuse for turning sieve so heavy that many if not most
> service providers will be unwilling to provide support for it.
<snip>

Not every ISP will want to support all Sieve extensions. They don't need=20
to. Many ISP will probably refrain from allowing regex use, of=20
variables, for that matter. I think it's perfectly OK to create Sieve=20
extensions that are explicitely not suitable for all Sieve use cases.=20
E.g. the envelope extension can't be used in MUAs since that=20
information in general is lost on final delivery. OTOH, people will=20
want to have execute command/play sound actions (the latter could be=20
added to notify) on the client.

I agree, though, that the I-Ds currently floating around should first be=20
advanced to RFCs before proposing even more extensions. It's a bit too=20
much currently ;-)

Marc

=2D-=20
They [RIAA,MPAA] are trying to invent a new crime:
interference with a business model.
                           --Bruce Schneier, Crypto-Gram 08/2002

--Boundary-02=_XU4r+KZV4u61h4M
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2rc2 (GNU/Linux)

iD8DBQA+r4UX3oWD+L2/6DgRAtmeAKDjBDWpDVqbNSLYPe6Msv2/ZBiRiACgytWH
pChEo6JmBnCOE7XPSxdVHAg=
=GDd1
-----END PGP SIGNATURE-----

--Boundary-02=_XU4r+KZV4u61h4M--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U7w2i2049834 for <[e-mail]>; Wed, 30 Apr 2003 00:58:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U7w2Qv049833 for ietf-mta-filters-bks; Wed, 30 Apr 2003 00:58:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U7w0i2049825 for <[e-mail]>; Wed, 30 Apr 2003 00:58:00 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.0.3 (pD9E11020.dip.t-dialin.net [217.225.16.32]) by max.kde.org (Postfix) with ESMTP id 32D24AFC6A for <[e-mail]>; Wed, 30 Apr 2003 09:57:59 +0200 (CEST)
From: Marc Mutz <[e-mail]>
Organization: "Old Europe" - and proud
To: [e-mail]
Subject: Re: Three new drafts and a question
Date: Wed, 30 Apr 2003 09:43:19 +0200
User-Agent: KMail/1.5.9
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_r63r+yVSx+2/oyf"; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <[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>

--Boundary-02=_r63r+yVSx+2/oyf
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Wednesday 30 April 2003 01:07, Kjetil Torgrim Homme wrote:
<snip>
> I know you wanted a failed match to not influence the numeric
> variables, Ned, it seems like you were right.
<snip>

Well, _obviously_ this particular problem stems from unconditionally=20
executing deleteheader+addheader. The correct way to do this would be:

if header :matches "Subject" "[ietf] *" {
	deleteheader "Subject";
	addheader "Subject" "${1}";
}

Marc

=2D-=20
If free-software authors lose the right to disclaim all warranties and
find themselves getting sued over the performance of the programs
they've written, they'll stop contributing free software to the world.
 -- Bruce Perens: Open Sources: Voices from the Open Source Revolution

--Boundary-02=_r63r+yVSx+2/oyf
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2rc2 (GNU/Linux)

iD8DBQA+r36r3oWD+L2/6DgRApHqAJ9ojxxVPD+O1WxkWzdxSgAAYRJfEQCfcvtx
ucgAYdy75onaiVQ5kadTfjA=
=A2R7
-----END PGP SIGNATURE-----

--Boundary-02=_r63r+yVSx+2/oyf--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U12wi2016374 for <[e-mail]>; Tue, 29 Apr 2003 18:02:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U12wFE016373 for ietf-mta-filters-bks; Tue, 29 Apr 2003 18:02:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U12si2016367 for <[e-mail]>; Tue, 29 Apr 2003 18:02:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 29 Apr 2003 18:02:52 -0700 (PDT)
Date: Tue, 29 Apr 2003 18:01:19 -0700 (PDT)
From: [e-mail]
Subject: Re: variables: greedy or non-greedy matching
In-reply-to: "Your message dated Wed, 30 Apr 2003 01:13:50 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[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]> <[e-mail]> <[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>

> [Ned Freed]:
> >
> >   [Jutta Degener]:
> >   > So let's stay greedy; thanks for setting me straight!
> >
> >   No problem ;-) And let's also remember that a necessary corollary
> >   here is that the regexp we end up choosing needs to support both
> >   greedy and non-greedy matching.

> why?  I thought we only needed that if :matches was non-greedy.

> I wouldn't mind having non-greedy regexps, but they're not in POSIX.2
> which the regex draft refers to.

Jutta's argument, which I believe is valid, is that expectations can only
be met by having both types available. As for the reference to POSIX, I thought
that had already been determined to be unsufficient and there was a suggestion
to replace it with something else (ECMAScript maybe?).

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U02Si2014880 for <[e-mail]>; Tue, 29 Apr 2003 17:02:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U02SMu014879 for ietf-mta-filters-bks; Tue, 29 Apr 2003 17:02:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U02Qi2014874 for <[e-mail]>; Tue, 29 Apr 2003 17:02:27 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19Af3M-00006n-00; Wed, 30 Apr 2003 02:02:28 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Wed, 30 Apr 2003 02:02:26 +0200
To: [e-mail]
Cc: [e-mail]
Subject: Re: Three new drafts and a question
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 30 Apr 2003 02:02:21 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 23
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>

[Ned Freed]:
>
>   [Kjetil T Homme]:
>   > I do feel that keeping the header name separate is best, if only for
>   > consistency with deleteheader and replaceheader.
>   
>   Consistency with header is actually more important IMO.

agreed, but I don't think a list of header names is very useful.  the
following is the best I can come up with :-)

    addheader ["Precedence", "X-Priority"] "cosmic top important";

>   [...] it begs the question of why deleteheader/addheader aren't
>   sufficient in the same way that a sequence of addheader actions is
>   sufficient to avoid the use of lists in addheader.

the only point I can see in favour of keeping replaceheader, is
Nigel's (general) point on idioms for GUIs.  and it doesn't seem very
compelling here.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNaMi2014327 for <[e-mail]>; Tue, 29 Apr 2003 16:36:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TNaMIb014326 for ietf-mta-filters-bks; Tue, 29 Apr 2003 16:36:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNaIi2014319 for <[e-mail]>; Tue, 29 Apr 2003 16:36:21 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 29 Apr 2003 16:36:15 -0700 (PDT)
Date: Tue, 29 Apr 2003 16:29:20 -0700 (PDT)
From: [e-mail]
Subject: Re: Three new drafts and a question
In-reply-to: "Your message dated Wed, 30 Apr 2003 00:52:06 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail], [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]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> [Ned Freed]:
> >
> >   > I don't follow.  could you write an example?
> >
> >   addheader ["Comment: 1", "Comment: 2"];

> I don't like mixing the header name and the content.  I don't see what
> this buys you compared to two calls to addheader.

OK, I'm now convinced this was a bad idea on my part. Having multiple
addheaders also seems preferable to me given that we don't really want
to encourage wholesalle header additions.

> >   > list of header names makes sense with deleteheader, but for
> >   > addheader I think it makes more sense to only support a list of
> >   > values.
> >   >
> >   >   addheader "Comment" ["1", "2"];
> >
> >   Ick. This merely adds complexity without actually adding the issue:
> >
> >   addheader ["Comment: 1", "Content-description: 2"];

> see above :-).  adding two instances of a header is very uncommon, so
> it's not a very useful feature.  it's more of a general design
> principle: do we want to support lists rather than single strings
> wherever we can give the action a useful meaning?

> I do feel that keeping the header name separate is best, if only for
> consistency with deleteheader and replaceheader.

Consistency with header is actually more important IMO.

> >   I think replaceheader is too complex. Think for a bit about the
> >   right way to handle modifications to encoded words. It gets very
> >   very nasty in a great big hurry.  For example, suppose I have an
> >   encoded-word in iso-8859-1

> "invisible" to Sieve.  the string will be in Unicode.

Yes, that's one way to implement it, and probably the approach I'd take. But
now when you apply replaceheader it ends up affecting parts of the field that
weren't specified in the action. Least astonishment principle and all that.

Of course a deleteheader/addheader sequence has the same characteristics.
But in this case it is very clear that the old header is gone and has 
been replaced with something else.

> >   and I use replaceheader to change an a with an accent grave to an
> >   a with an ogonek.  What does the result look like?  Are adjacent
> >   encoded-words affected? Should they be?

> I think a fresh re-encoding is the way to go.  regrettably there are
> some clients with limited support for charsets, so it would be nice if
> the Sieve implementation tried to use the same charset as was used
> originally, if only one charset suffices.  encoding it all as UTF-8
> should be good enough, though.  remember that the user must explicitly
> request this munging.  if his e-mail client can't handle it, he should
> turn it off.

I agree with this implementation choice, but it begs the question of why
deleteheader/addheader aren't sufficient in the same way that
a sequence of addheader actions is sufficient to avoid the use of lists
in addheader.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNNxi2014044 for <[e-mail]>; Tue, 29 Apr 2003 16:23:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TNNxPx014043 for ietf-mta-filters-bks; Tue, 29 Apr 2003 16:23:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNNui2014036 for <[e-mail]>; Tue, 29 Apr 2003 16:23:57 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 29 Apr 2003 16:23:51 -0700 (PDT)
Date: Tue, 29 Apr 2003 16:22:28 -0700 (PDT)
From: [e-mail]
Subject: Re: Three new drafts and a question
In-reply-to: "Your message dated Wed, 30 Apr 2003 00:25:54 +0200" <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail], Marc Mutz <[e-mail]>, [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]> <[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>

> [e-mail] writes:

> >> Deleteheader/addheader will likely not maintain sort order, but a
> >> replaceheader ought to (which is useful).
> >
> >> I agree it is complex, but I have always wanted Sieve to be a real
> >> language (= complex) so I don't consider that a problem.
> >
> > This is not a desire I share. In fact one of the original design goals of sieve
> > was that it not be "a real language". If I want a real language I'll use one.
> > There are plenty of them around; no need to invent another.

> The only standardized language, used for mail handling, which has
> multi-vendor support in MUAs and MTAs, that I know of, is Sieve.
> There are not plenty of them around.

That's not an excuse for turning sieve so heavy that many if not most service
providers will be unwilling to provide support for it.

> I agree with you that there is no need to invent another language,
> fortunately, but my reason is that I believe Sieve is being enhanced
> into a complex language.

Not if I have anything to say about it.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNEFi2013797 for <[e-mail]>; Tue, 29 Apr 2003 16:14:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TNEF2d013796 for ietf-mta-filters-bks; Tue, 29 Apr 2003 16:14:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNEDi2013789 for <[e-mail]>; Tue, 29 Apr 2003 16:14:14 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19AeIh-0003oe-00 for [e-mail]; Wed, 30 Apr 2003 01:14:15 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Wed, 30 Apr 2003 01:14:00 +0200
To: [e-mail]
Subject: Re: variables: greedy or non-greedy matching
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 30 Apr 2003 01:13:50 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 16
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>

[Ned Freed]:
>
>   [Jutta Degener]:
>   > So let's stay greedy; thanks for setting me straight!
>   
>   No problem ;-) And let's also remember that a necessary corollary
>   here is that the regexp we end up choosing needs to support both
>   greedy and non-greedy matching.

why?  I thought we only needed that if :matches was non-greedy.

I wouldn't mind having non-greedy regexps, but they're not in POSIX.2
which the regex draft refers to.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TN7Ri2013541 for <[e-mail]>; Tue, 29 Apr 2003 16:07:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TN7RIl013540 for ietf-mta-filters-bks; Tue, 29 Apr 2003 16:07:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TN7Pi2013535 for <[e-mail]>; Tue, 29 Apr 2003 16:07:26 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19AeC7-0003Jj-00 for [e-mail]; Wed, 30 Apr 2003 01:07:27 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Wed, 30 Apr 2003 01:07:12 +0200
To: [e-mail]
Subject: Re: Three new drafts and a question
References: <[e-mail]> <[e-mail]> <01fd01c30e35$08db4830$6401a8c0@nigelhome> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 30 Apr 2003 01:07:02 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 64
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>

[Ned Freed]:
>
>   [Nigel Swinson]:

>   > One other thing to say is complexity for guis.  If the intention
>   > is to "replace header" and you have to do this via removeheader
>   > and addheader, then it becomes much more difficult to "extract"
>   > from the script.

good point.  most GUI's will only need to understand their own Sieve
code, but it is important that the constructs we provide lend
themselves easily to common idioms.

>   > The intention being to populate a control that has an array of
>   > desired actions, one of which is "Prepend the following
>   > substring to the Subject line".
>   >
>   > ie either:
>   >
>   > if spamtest :value "ge" :comparator "i;ascii-numeric" "3" {
>   >     replaceheader :newvalue "[SPAM] ${1}" :matches "Subject" "*";
>   > }
>   >
>   > or:
>   >
>   > if spamtest :value "ge" :comparator "i;ascii-numeric" "3" {
>   >     deleteheader :matches "Subject" "*";
>   >     addheader "Subject" "[SPAM] ${1}";
>   > }
>   
>   I actually prefer the second. It makes it clear a new header is
>   being generated with all that implies (changes to encoded words,
>   etc.). The former implies that the operation may only be a simple
>   prepend. The world isn't this simple.

Nigel's second example is quite clever.  the reverse, removing a
prefix, exposes unintuitive behaviour in my draft, though:

    deleteheader :matches "Subject" "[ietf] *";
    addheader "Subject" "${1}";
    fileinto "INBOX.lists.ietf";

consider this message:

    Subject: [ietf] meeting on Thursday
    Subject: buggy header

the result will actually be:

    Subject: buggy header
    Subject: 

since the failed match will empty the numeric variables.  two Subject
headers is a bit obscure, so a better example may be:

    deleteheader :matches "Subject" "[ietf] *";
    deleteheader :matches "Subject" "Re: [ietf] *";
    addheader "Subject" "${1}";

I know you wanted a failed match to not influence the numeric
variables, Ned, it seems like you were right.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMq8i2013244 for <[e-mail]>; Tue, 29 Apr 2003 15:52:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMq8m9013243 for ietf-mta-filters-bks; Tue, 29 Apr 2003 15:52:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMq6i2013238 for <[e-mail]>; Tue, 29 Apr 2003 15:52:07 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19AdxI-0001gj-00; Wed, 30 Apr 2003 00:52:08 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Wed, 30 Apr 2003 00:52:06 +0200
To: [e-mail]
Cc: [e-mail]
Subject: Re: Three new drafts and a question
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 30 Apr 2003 00:52:06 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 48
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>

[Ned Freed]:
>
>   > I don't follow.  could you write an example?
>   
>   addheader ["Comment: 1", "Comment: 2"];

I don't like mixing the header name and the content.  I don't see what
this buys you compared to two calls to addheader.

>   > list of header names makes sense with deleteheader, but for
>   > addheader I think it makes more sense to only support a list of
>   > values.
>   >
>   >   addheader "Comment" ["1", "2"];
>   
>   Ick. This merely adds complexity without actually adding the issue:
>   
>   addheader ["Comment: 1", "Content-description: 2"];

see above :-).  adding two instances of a header is very uncommon, so
it's not a very useful feature.  it's more of a general design
principle: do we want to support lists rather than single strings
wherever we can give the action a useful meaning?

I do feel that keeping the header name separate is best, if only for
consistency with deleteheader and replaceheader.

>   I think replaceheader is too complex. Think for a bit about the
>   right way to handle modifications to encoded words. It gets very
>   very nasty in a great big hurry.  For example, suppose I have an
>   encoded-word in iso-8859-1

"invisible" to Sieve.  the string will be in Unicode.

>   and I use replaceheader to change an a with an accent grave to an
>   a with an ogonek.  What does the result look like?  Are adjacent
>   encoded-words affected? Should they be?

I think a fresh re-encoding is the way to go.  regrettably there are
some clients with limited support for charsets, so it would be nice if
the Sieve implementation tried to use the same charset as was used
originally, if only one charset suffices.  encoding it all as UTF-8
should be good enough, though.  remember that the user must explicitly
request this munging.  if his e-mail client can't handle it, he should
turn it off.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMQQi2012819 for <[e-mail]>; Tue, 29 Apr 2003 15:26:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMQQJ7012818 for ietf-mta-filters-bks; Tue, 29 Apr 2003 15:26:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMQOi2012811 for <[e-mail]>; Tue, 29 Apr 2003 15:26:25 -0700 (PDT) (envelope-from [e-mail])
Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3TMPtbU030474 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 30 Apr 2003 00:25:56 +0200
To: [e-mail]
Cc: Marc Mutz <[e-mail]>, [e-mail]
Subject: Re: Three new drafts and a question
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Simon Josefsson <[e-mail]>
X-Payment: hashcash 1.2 0:030429:[e-mail]:6caa2e354dfdc0e7
X-Hashcash: 0:030429:[e-mail]:6caa2e354dfdc0e7
X-Payment: hashcash 1.2 0:030429:[e-mail]:458a7c0c4823c275
X-Hashcash: 0:030429:[e-mail]:458a7c0c4823c275
X-Payment: hashcash 1.2 0:030429:[e-mail]:b0e260ebacfaa226
X-Hashcash: 0:030429:[e-mail]:b0e260ebacfaa226
Date: Wed, 30 Apr 2003 00:25:54 +0200
In-Reply-To: <[e-mail]> (ned freed's message of "Mon, 28 Apr 2003 19:42:21 -0700 (PDT)")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.09002 (Oort Gnus v0.20) Emacs/21.3.50 (gnu/linux)
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>

[e-mail] writes:

>> Deleteheader/addheader will likely not maintain sort order, but a
>> replaceheader ought to (which is useful).
>
>> I agree it is complex, but I have always wanted Sieve to be a real
>> language (= complex) so I don't consider that a problem.
>
> This is not a desire I share. In fact one of the original design goals of sieve
> was that it not be "a real language". If I want a real language I'll use one.
> There are plenty of them around; no need to invent another.

The only standardized language, used for mail handling, which has
multi-vendor support in MUAs and MTAs, that I know of, is Sieve.
There are not plenty of them around.

I agree with you that there is no need to invent another language,
fortunately, but my reason is that I believe Sieve is being enhanced
into a complex language.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TFYNi2099066 for <[e-mail]>; Tue, 29 Apr 2003 08:34:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TFYNIm099065 for ietf-mta-filters-bks; Tue, 29 Apr 2003 08:34:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TFYKi2099058 for <[e-mail]>; Tue, 29 Apr 2003 08:34:22 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 29 Apr 2003 08:34:16 -0700 (PDT)
Date: Tue, 29 Apr 2003 08:32:08 -0700 (PDT)
From: [e-mail]
Subject: Re: Three new drafts and a question
In-reply-to: "Your message dated Tue, 29 Apr 2003 10:52:23 +0100" <01fd01c30e35$08db4830$6401a8c0@nigelhome>
To: Nigel Swinson <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <01fd01c30e35$08db4830$6401a8c0@nigelhome>
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>

> > > Please explain why you cannot use deleteheader/addheader for this.
> >
> > I don't think this is the example Marc had in mind, but anyway:

> One other thing to say is complexity for guis.  If the intention is to
> "replace header" and you have to do this via removeheader and addheader,
> then it becomes much more difficult to "extract" from the script.  The
> intention being to populate a control that has an array of desired actions,
> one of which is "Prepend the following substring to the Subject line".

> ie either:

> if spamtest :value "ge" :comparator "i;ascii-numeric" "3" {
>     replaceheader :newvalue "[SPAM] ${1}" :matches "Subject" "*";
> }

> or:

> if spamtest :value "ge" :comparator "i;ascii-numeric" "3" {
>     deleteheader :matches "Subject" "*";
>     addheader "Subject" "[SPAM] ${1}";
> }

I actually prefer the second. It makes it clear a new header is being
generated with all that implies (changes to encoded words, etc.). The
former implies that the operation may only be a simple prepend. The 
world isn't this simple.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TFUGi2098985 for <[e-mail]>; Tue, 29 Apr 2003 08:30:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TFUG2T098984 for ietf-mta-filters-bks; Tue, 29 Apr 2003 08:30:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TFUEi2098978 for <[e-mail]>; Tue, 29 Apr 2003 08:30:15 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 29 Apr 2003 08:30:02 -0700 (PDT)
Date: Tue, 29 Apr 2003 08:28:31 -0700 (PDT)
From: [e-mail]
Subject: Re: Three new drafts and a question
In-reply-to: "Your message dated Tue, 29 Apr 2003 10:14:18 +0200" <[e-mail]>
To: Marc Mutz <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: message/rfc822
References: <[e-mail]> <[e-mail]> <[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>

Content-transfer-encoding: 7BIT


> <snip>
> > I'm afraid I don't find this to be a credible example. Sieve is
> > intended to be a language used in or around delivery time so users
> > can exercise some control over delivery processing. It is not
> > intended to be a general purpose message alteration facility.
> <snip>

> It isn't? The whitepaper mentions not only final delivery uses, but also
> periodic sweeps through a message store for administrative purposes
> (aka cron jobs) as well as client-side filtering.

This was for filtering and redirection purposes, not for message alteration.

> Esp. the editheader draft is one that is mandatory for client-side
> filtering, b/c many clients provide that functionality now and it is
> used where offered.

> I'd even welcome a shell-out (execute_command/pipe_trough) extension,
> even if it was never ever implemented on a server (and shouldn't), but
> only in clients and local tools (like GNU mailutils' sieve).

I object in the strongest possible terms to this.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TA9xi2077065 for <[e-mail]>; Tue, 29 Apr 2003 03:09:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TA9xoL077064 for ietf-mta-filters-bks; Tue, 29 Apr 2003 03:09:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TA9vi2077058 for <[e-mail]>; Tue, 29 Apr 2003 03:09:58 -0700 (PDT) (envelope-from [e-mail])
Received: from nigelhome (unverified [80.195.14.206]) by starship.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.3.3) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 29 Apr 2003 10:48:29 +0100
Message-ID: <01fd01c30e35$08db4830$6401a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Three new drafts and a question
Date: Tue, 29 Apr 2003 10:52:23 +0100
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.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

> > Please explain why you cannot use deleteheader/addheader for this.
>
> I don't think this is the example Marc had in mind, but anyway:

One other thing to say is complexity for guis.  If the intention is to
"replace header" and you have to do this via removeheader and addheader,
then it becomes much more difficult to "extract" from the script.  The
intention being to populate a control that has an array of desired actions,
one of which is "Prepend the following substring to the Subject line".

ie either:

if spamtest :value "ge" :comparator "i;ascii-numeric" "3" {
    replaceheader :newvalue "[SPAM] ${1}" :matches "Subject" "*";
}

or:

if spamtest :value "ge" :comparator "i;ascii-numeric" "3" {
    deleteheader :matches "Subject" "*";
    addheader "Subject" "[SPAM] ${1}";
}

Cheers

Nigel



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T8QGi2069123 for <[e-mail]>; Tue, 29 Apr 2003 01:26:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T8QGLD069122 for ietf-mta-filters-bks; Tue, 29 Apr 2003 01:26:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T8QEi2069110 for <[e-mail]>; Tue, 29 Apr 2003 01:26:15 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.0.3 (p5082BC5B.dip.t-dialin.net [80.130.188.91]) by max.kde.org (Postfix) with ESMTP id C9D01B4F77 for <[e-mail]>; Tue, 29 Apr 2003 10:26:13 +0200 (CEST)
From: Marc Mutz <[e-mail]>
Organization: "Old Europe" - and proud
To: [e-mail]
Subject: Re: Three new drafts and a question
Date: Tue, 29 Apr 2003 10:14:18 +0200
User-Agent: KMail/1.5.9
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_nRjr+1/9uI82Jxk"; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <[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>

--Boundary-02=_nRjr+1/9uI82Jxk
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Tuesday 29 April 2003 04:42, [e-mail] wrote:
<snip>
> I'm afraid I don't find this to be a credible example. Sieve is
> intended to be a language used in or around delivery time so users
> can exercise some control over delivery processing. It is not
> intended to be a general purpose message alteration facility.
<snip>

It isn't? The whitepaper mentions not only final delivery uses, but also=20
periodic sweeps through a message store for administrative purposes=20
(aka cron jobs) as well as client-side filtering.

Esp. the editheader draft is one that is mandatory for client-side=20
filtering, b/c many clients provide that functionality now and it is=20
used where offered.

I'd even welcome a shell-out (execute_command/pipe_trough) extension,=20
even if it was never ever implemented on a server (and shouldn't), but=20
only in clients and local tools (like GNU mailutils' sieve).

Marc

=2D-=20
Eternal vigilance is the price of liberty   -- Thomas Jefferson

--Boundary-02=_nRjr+1/9uI82Jxk
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+rjRn3oWD+L2/6DgRApnMAKDhQ9gW6lAUjotcCTlWxUNsDwXB9gCdHr0I
KdPpnFGOu8YhaXzXahO9cKI=
=CSzD
-----END PGP SIGNATURE-----

--Boundary-02=_nRjr+1/9uI82Jxk--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T2kHi2038267 for <[e-mail]>; Mon, 28 Apr 2003 19:46:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T2kHiY038266 for ietf-mta-filters-bks; Mon, 28 Apr 2003 19:46:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T2kEi2038261 for <[e-mail]>; Mon, 28 Apr 2003 19:46:15 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 28 Apr 2003 19:46:10 -0700 (PDT)
Date: Mon, 28 Apr 2003 19:42:21 -0700 (PDT)
From: [e-mail]
Subject: Re: Three new drafts and a question
In-reply-to: "Your message dated Tue, 29 Apr 2003 02:33:23 +0200" <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail], Marc Mutz <[e-mail]>, [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>

> [e-mail] writes:

> >> On Sunday 27 April 2003 19:17, [e-mail] wrote:
> >> <snip>
> >> > I think replaceheader is too complex.
> >
> >> But it's needed in the real world. Adding/removing the [mailing list]
> >> tag to/from the subject line and fixing mangled/mangling reply-to
> >> headers is popular among people who need to handle large (or large
> >> amounts of) mailing list traffic.
> >
> > Please explain why you cannot use deleteheader/addheader for this.

> I don't think this is the example Marc had in mind, but anyway:

> Consider if you want to replace the obscure MTA identification strings
> in Received: headers with the full name of the MTA product.

I'm afraid I don't find this to be a credible example. Sieve is intended to be
a language used in or around delivery time so users can exercise some control
over delivery processing. It is not intended to be a general purpose message
alteration facility.

> Deleteheader/addheader will likely not maintain sort order, but a
> replaceheader ought to (which is useful).

> I agree it is complex, but I have always wanted Sieve to be a real
> language (= complex) so I don't consider that a problem.

This is not a desire I share. In fact one of the original design goals of sieve
was that it not be "a real language". If I want a real language I'll use one.
There are plenty of them around; no need to invent another.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T0nJi2035540 for <[e-mail]>; Mon, 28 Apr 2003 17:49:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T0nJxE035539 for ietf-mta-filters-bks; Mon, 28 Apr 2003 17:49:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T0nHi2035534 for <[e-mail]>; Mon, 28 Apr 2003 17:49:18 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.0.3 (pD9525752.dip.t-dialin.net [217.82.87.82]) by max.kde.org (Postfix) with ESMTP id E8040B4F77 for <[e-mail]>; Tue, 29 Apr 2003 02:49:19 +0200 (CEST)
From: Marc Mutz <[e-mail]>
Organization: "Old Europe" - and proud
To: [e-mail]
Subject: Re: Three new drafts and a question
Date: Tue, 29 Apr 2003 02:38:20 +0200
User-Agent: KMail/1.5.9
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_9lcr+wtNFQGeQTq"; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <[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>

--Boundary-02=_9lcr+wtNFQGeQTq
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Tuesday 29 April 2003 01:43, [e-mail] wrote:
<snip>
> Please explain why you cannot use deleteheader/addheader for this.
<snip>

OK, if the variables extension is present, you can of course emulate=20
this with a :regex/:matches test and a deleteheader/addheader pair.

If the variables extension isn't available, the replaceheader itself is=20
pretty limited, too, since
  replaceheader :newvalue "" :regex "Subject" "^\[ml-name\] *";
doesn't work (should it? Probably, since without it, how does one write=20
the equivalent of perl's s///g?).

The arguments that remains, then, is that replaceheader is easier to=20
write for a script author and that it can't be that complex if it's=20
functionality is already present in addheader/deleteheader/variables...=20
In addition, replaceheader :index <num> has no equivalent due to lack=20
of indexing support in the header test.

Marc

=2D-=20
The first casualty of war is the truth.

--Boundary-02=_9lcr+wtNFQGeQTq
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+rcl93oWD+L2/6DgRAlNfAJ99tsQlIIOVpUVwQ/rnu6e3LTi+AACg9bEw
MH4B5Jp9lqBpw0CeV7nZitw=
=2j5l
-----END PGP SIGNATURE-----

--Boundary-02=_9lcr+wtNFQGeQTq--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T0XPi2035303 for <[e-mail]>; Mon, 28 Apr 2003 17:33:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T0XPx8035302 for ietf-mta-filters-bks; Mon, 28 Apr 2003 17:33:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T0XNi2035297 for <[e-mail]>; Mon, 28 Apr 2003 17:33:24 -0700 (PDT) (envelope-from [e-mail])
Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3T0XNbU005952 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 29 Apr 2003 02:33:23 +0200
To: [e-mail]
Cc: Marc Mutz <[e-mail]>, [e-mail]
Subject: Re: Three new drafts and a question
References: <[e-mail]>
From: Simon Josefsson <[e-mail]>
X-Payment: hashcash 1.2 0:030429:[e-mail]:492cfffce460e2e3
X-Hashcash: 0:030429:[e-mail]:492cfffce460e2e3
X-Payment: hashcash 1.2 0:030429:[e-mail]:4ec96f1ffd11673b
X-Hashcash: 0:030429:[e-mail]:4ec96f1ffd11673b
X-Payment: hashcash 1.2 0:030429:[e-mail]:c77a97385181192e
X-Hashcash: 0:030429:[e-mail]:c77a97385181192e
Date: Tue, 29 Apr 2003 02:33:23 +0200
In-Reply-To: <[e-mail]> (ned freed's message of "Mon, 28 Apr 2003 16:43:02 -0700 (PDT)")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.09002 (Oort Gnus v0.20) Emacs/21.3.50 (gnu/linux)
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>

[e-mail] writes:

>> On Sunday 27 April 2003 19:17, [e-mail] wrote:
>> <snip>
>> > I think replaceheader is too complex.
>
>> But it's needed in the real world. Adding/removing the [mailing list]
>> tag to/from the subject line and fixing mangled/mangling reply-to
>> headers is popular among people who need to handle large (or large
>> amounts of) mailing list traffic.
>
> Please explain why you cannot use deleteheader/addheader for this.

I don't think this is the example Marc had in mind, but anyway:

Consider if you want to replace the obscure MTA identification strings
in Received: headers with the full name of the MTA product.

Deleteheader/addheader will likely not maintain sort order, but a
replaceheader ought to (which is useful).

I agree it is complex, but I have always wanted Sieve to be a real
language (= complex) so I don't consider that a problem.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3SNmYi2034519 for <[e-mail]>; Mon, 28 Apr 2003 16:48:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3SNmYB3034518 for ietf-mta-filters-bks; Mon, 28 Apr 2003 16:48:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3SNmVi2034513 for <[e-mail]>; Mon, 28 Apr 2003 16:48:32 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 28 Apr 2003 16:48:30 -0700 (PDT)
Date: Mon, 28 Apr 2003 16:43:02 -0700 (PDT)
From: [e-mail]
Subject: Re: Three new drafts and a question
In-reply-to: "Your message dated Mon, 28 Apr 2003 20:02:24 +0200" <[e-mail]>
To: Marc Mutz <[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>

> On Sunday 27 April 2003 19:17, [e-mail] wrote:
> <snip>
> > I think replaceheader is too complex.

> But it's needed in the real world. Adding/removing the [mailing list]
> tag to/from the subject line and fixing mangled/mangling reply-to
> headers is popular among people who need to handle large (or large
> amounts of) mailing list traffic.

Please explain why you cannot use deleteheader/addheader for this.

> > Think for a bit about the right
> > way to handle modifications to encoded words. It gets very very nasty
> > in a great big hurry.  For example, suppose I have an encoded-word in
> > iso-8859-1 and I use replaceheader to change an a with an accent
> > grave to an a with an ogonek. What does the result look like? Are
> > adjacent encoded-words affected? Should they be?

> The base Sieve spec deals with recognizing encoded-words and IMO all
> that this extension needs to say is that if the result of the
> replaceheader action needs encoding, the Sieve implementation MUST do
> so.

This is not even close to sufficient. The interaction with existing
encoded words also has to be considered.

> The _how_ is up to the implementation and can range from re-encoding
> only the affected (encoded-)words using a minimal charset (for a
> certain definition of that) to brutally encoding the whole result in
> =?utf-8?b?...?= chunks unconditionally.

A cure that is worse than the disease given the state of many clients today.

> One could add a :preferred_charsets option that takes a stringlist as
> parameter, but I think that's hacky. One could specify a preferred
> algorithm that SHOULD be followed along the lines of

> 1. Only touch encoded-words that are affected.
> 2. If the affected portions of the result are US-ASCII, remove the
> encoding, else
> 3. If the affected portions of the result can be represented in one of
> the charsets already used in encoded-words in the original form of the
> header, encode using that charset, else
> 4. If they can be represented in iso-8859-1 or the server's locale
> charset or any site-defined sorted list of charsets, use the best
> (latin-1, locale, first in the list), else
> 5. use utf-8.

Yeah, and given past experience with encoded-word handling, how many
implementations do you think are going to get this right?

> but I don't see the need to require a particular behavior when encoding.

I'm afraid I do.

					Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3SIDni2020481 for <[e-mail]>; Mon, 28 Apr 2003 11:13:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3SIDnRj020480 for ietf-mta-filters-bks; Mon, 28 Apr 2003 11:13:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3SIDli2020475 for <[e-mail]>; Mon, 28 Apr 2003 11:13:48 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.0.3 (pD9E11D60.dip.t-dialin.net [217.225.29.96]) by max.kde.org (Postfix) with ESMTP id 800AEAFC6A for <[e-mail]>; Mon, 28 Apr 2003 20:13:47 +0200 (CEST)
From: Marc Mutz <[e-mail]>
Organization: "Old Europe" - and proud
To: [e-mail]
Subject: Re: Three new drafts and a question
Date: Mon, 28 Apr 2003 20:02:24 +0200
User-Agent: KMail/1.5.9
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_GzWr+qbD4GTuKu5"; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[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>

--Boundary-02=_GzWr+qbD4GTuKu5
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Sunday 27 April 2003 19:17, [e-mail] wrote:
<snip>
> I think replaceheader is too complex.

But it's needed in the real world. Adding/removing the [mailing list]=20
tag to/from the subject line and fixing mangled/mangling reply-to=20
headers is popular among people who need to handle large (or large=20
amounts of) mailing list traffic.

> Think for a bit about the right
> way to handle modifications to encoded words. It gets very very nasty
> in a great big hurry.  For example, suppose I have an encoded-word in
> iso-8859-1 and I use replaceheader to change an a with an accent
> grave to an a with an ogonek. What does the result look like? Are
> adjacent encoded-words affected? Should they be?

The base Sieve spec deals with recognizing encoded-words and IMO all=20
that this extension needs to say is that if the result of the=20
replaceheader action needs encoding, the Sieve implementation MUST do=20
so.

The _how_ is up to the implementation and can range from re-encoding=20
only the affected (encoded-)words using a minimal charset (for a=20
certain definition of that) to brutally encoding the whole result in=20
=3D?utf-8?b?...?=3D chunks unconditionally.

One could add a :preferred_charsets option that takes a stringlist as=20
parameter, but I think that's hacky. One could specify a preferred=20
algorithm that SHOULD be followed along the lines of

1. Only touch encoded-words that are affected.
2. If the affected portions of the result are US-ASCII, remove the=20
encoding, else
3. If the affected portions of the result can be represented in one of=20
the charsets already used in encoded-words in the original form of the=20
header, encode using that charset, else
4. If they can be represented in iso-8859-1 or the server's locale=20
charset or any site-defined sorted list of charsets, use the best=20
(latin-1, locale, first in the list), else
5. use utf-8.

but I don't see the need to require a particular behavior when encoding.

Marc

=2D-=20
Silent leges inter arma      -- Cicero

--Boundary-02=_GzWr+qbD4GTuKu5
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD4DBQA+rWzF3oWD+L2/6DgRAqrOAJivT3f0j3OqH+oVsIWAP028eI7zAJ9Jth5x
V1M8MkMcAfQy0XlyJFRXXw==
=91cR
-----END PGP SIGNATURE-----

--Boundary-02=_GzWr+qbD4GTuKu5--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3SHmpt2018032 for <[e-mail]>; Mon, 28 Apr 2003 10:48:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3SHmok7018031 for ietf-mta-filters-bks; Mon, 28 Apr 2003 10:48:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3SHmnt2018018 for <[e-mail]>; Mon, 28 Apr 2003 10:48:49 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3SHmWFe014200 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 28 Apr 2003 10:48:33 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3SHmUqu014931; Mon, 28 Apr 2003 10:48:32 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 459D2179BB; Mon, 28 Apr 2003 10:48:08 -0700 (PDT)
Date: Mon, 28 Apr 2003 10:48:06 -0700
From: Jutta Degener <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Subject: Re: Three new drafts and a question
Message-ID: <[e-mail]>
References: <[e-mail]> <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3SHmUqu014931
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 Sat, Apr 26, 2003 at 11:54:44PM +0200, Kjetil Torgrim Homme wrote:
> [Ned Freed]:
> >   [Jutta Degener]:
> >   > [editheader]
> 
> interesting, the draft says "replaceheader".  "editheader" is a better
> name, especially if :newname goes away.

The extension is "editheader",  comprising the three commands
"addheader", "deleteheader", and "replaceheader".

>   addheader "Comment" ["1", "2"];

Sorry, but I'd rather stick to simple name/value pairs.

> this might be an issue for the variables draft, it could say that the
> search must be short-circuited (given, but perhaps not strongly enough
> worded in existing documents), and the search done in first to last
> order.  would that be appropriate?

I'd rather leave it undefined, so that people have more freedom
in how to implement their search.  If a script writer needs a
specific order, they can always force it by separating the statements.

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3RKYYt2011445 for <[e-mail]>; Sun, 27 Apr 2003 13:34:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3RKYYhL011444 for ietf-mta-filters-bks; Sun, 27 Apr 2003 13:34:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3RKYWt2011439 for <[e-mail]>; Sun, 27 Apr 2003 13:34:32 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 27 Apr 2003 13:34:31 -0700 (PDT)
Date: Sun, 27 Apr 2003 13:33:49 -0700 (PDT)
From: [e-mail]
Subject: Re: variables: greedy or non-greedy matching
In-reply-to: "Your message dated Thu, 24 Apr 2003 10:35:57 -0700" <[e-mail]>
To: Jutta Degener <[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]> <[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>

> On Thu, Apr 24, 2003 at 07:14:43AM -0700, [e-mail] wrote:
> > Um, no. For the very small subset of users sophisticated enough to
> > write this sort of code themselves, I believe their expectation will
> > be set by past experience with other matching systems, and these
> > systems tend to default to greedy matching.

> I think even in that sophisticated subset, most people just live
> their pattern-matching lives without really thinking about the
> difference.

> But admittedly, my own expectations are muddy, and, worse,
> seem to change with the lexical structure of the pattern.
> Speaking naively -- I know that this isn't how things work
> or should work --

> * If the end of my pattern is part of a grammatical whole, I want
>   the wildcard to  be greedy; certainly, I, too, would expect
>   "f*o" to fully match "foo", not to stop after the first "o".

> * But if the end of my pattern is a delimiter, I tend to implicitly
>   expect the expression be defined as something that doesn't
>   contain that delimiter, as in the example Kjetil quoted where few
>   people would expect the * before a closing > in an e-mail address
>   to itself contain another >.

> I think what this all says is that what felt to me like a problem
> with greed is really a problem with globbing and insufficient
> expressiveness of * (regexps have problems, too, once you get
> to comments and quoting, but one has to work a little harder to
> make things fail.)

> So let's stay greedy; thanks for setting me straight!

No problem ;-) And let's also remember that a necessary corollary here
is that the regexp we end up choosing needs to support both greedy and
non-greedy matching.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3RHa2t2004189 for <[e-mail]>; Sun, 27 Apr 2003 10:36:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3RHa2Yu004188 for ietf-mta-filters-bks; Sun, 27 Apr 2003 10:36:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3RHZxt2004182 for <[e-mail]>; Sun, 27 Apr 2003 10:36:00 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 27 Apr 2003 10:35:58 -0700 (PDT)
Date: Sun, 27 Apr 2003 10:17:49 -0700 (PDT)
From: [e-mail]
Subject: Re: Three new drafts and a question
In-reply-to: "Your message dated Sat, 26 Apr 2003 23:54:44 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[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]> <[e-mail]> <[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>

> [Ned Freed]:
> >
> >   [Jutta Degener]:
> >   > [editheader]

> interesting, the draft says "replaceheader".  "editheader" is a better
> name, especially if :newname goes away.

> >   > [Ned Freed]:
> >   > >     I prefer the approach of having a single argument,
> >   > >     which can either be a string specifying a single field or a list
> >   > >     specifying multiple fields.
> >   >
> >   > Hm, you mean a real ["foo", "bar"] list, or a chunk of text
> >   > that becomes the header?
> >
> >   I mean ["Comment: 1", "Comment: 2"].

> I don't follow.  could you write an example?

addheader ["Comment: 1", "Comment: 2"];

> list of header names makes sense with deleteheader, but for addheader
> I think it makes more sense to only support a list of values.

>   addheader "Comment" ["1", "2"];

Ick. This merely adds complexity without actually adding the issue:

addheader ["Comment: 1", "Content-description: 2"];

> you could do a list of header names with replaceheader as well, but
> the counting is a bit tricky, and I think it's complex enough already.
> you can always do N separate replaceheader instead.

I think replaceheader is too complex. Think for a bit about the right way to
handle modifications to encoded words. It gets very very nasty in a great big
hurry.  For example, suppose I have an encoded-word in iso-8859-1 and I use
replaceheader to change an a with an accent grave to an a with an ogonek.
What does the result look like? Are adjacent encoded-words affected? Should
they be?

> >   Good point. Even if we retain replaceheader I'd argue that
> >   :newname should go. You can always get the effect by deleting and
> >   adding.

> if there is only one header, yes.

>    if header "Message-ID" :matches "<*@*>" {
>        deleteheader "Message-ID";
>        addheader "Old-Message-ID" "<${1}@${2}>";
>        addheader "Message-ID" "<my.${1}.${2}@example.com>";
>    }

> if there is more than one instance of a header, you can't get at one
> of them in particular.  the content in ${N} could be from the first or
> last or a random one.

This argues for adding index capabilites to header, which is something we
need independently of this facility.

> this might be an issue for the variables draft, it could say that the
> search must be short-circuited (given, but perhaps not strongly enough
> worded in existing documents), and the search done in first to last
> order.  would that be appropriate?

I have no problem with nailing down first to last scanning order for multiple
versions of the same field. But keep in mind that this doesn't solve the entire
problem: You can potentially have three iterates in a header operation: A list
of field names, a list of field values, and more then one instance of a given
field. I suspect different implementations organize their iterates differently
(I iterate on field, field instance and finally field value myself). I don't
think we want to mandate a particular way of ordering  the iterates.

Of course you can work around the iteration order by using simpler tests,
whereas you can't work around the problem of multiple fields other than
by specifying the short-circuit behavior to some extent.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3QLskt2025133 for <[e-mail]>; Sat, 26 Apr 2003 14:54:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3QLsk50025132 for ietf-mta-filters-bks; Sat, 26 Apr 2003 14:54:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3QLsht2025127 for <[e-mail]>; Sat, 26 Apr 2003 14:54:44 -0700 (PDT) (envelope-from [e-mail])
Received: from ellifu.ifi.uio.no ([129.240.65.211]) by pat.uio.no with esmtp (Exim 2.12 #7) id 199Xd7-0005pr-00 for [e-mail]; Sat, 26 Apr 2003 23:54:45 +0200
Received: (from kjetilho@localhost) by ellifu.ifi.uio.no ; Sat, 26 Apr 2003 23:54:44 +0200 (MEST)
To: [e-mail]
Subject: Re: Three new drafts and a question
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 26 Apr 2003 23:54:44 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 52
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>

[Ned Freed]:
>
>   [Jutta Degener]:
>   > [editheader]

interesting, the draft says "replaceheader".  "editheader" is a better
name, especially if :newname goes away.

>   > [Ned Freed]:
>   > >     I prefer the approach of having a single argument,
>   > >     which can either be a string specifying a single field or a list
>   > >     specifying multiple fields.
>   >
>   > Hm, you mean a real ["foo", "bar"] list, or a chunk of text
>   > that becomes the header?
>   
>   I mean ["Comment: 1", "Comment: 2"].

I don't follow.  could you write an example?

list of header names makes sense with deleteheader, but for addheader
I think it makes more sense to only support a list of values.

  addheader "Comment" ["1", "2"];

you could do a list of header names with replaceheader as well, but
the counting is a bit tricky, and I think it's complex enough already.
you can always do N separate replaceheader instead.

>   Good point. Even if we retain replaceheader I'd argue that
>   :newname should go. You can always get the effect by deleting and
>   adding.

if there is only one header, yes.

   if header "Message-ID" :matches "<*@*>" {
       deleteheader "Message-ID";
       addheader "Old-Message-ID" "<${1}@${2}>";
       addheader "Message-ID" "<my.${1}.${2}@example.com>";
   }

if there is more than one instance of a header, you can't get at one
of them in particular.  the content in ${N} could be from the first or
last or a random one.

this might be an issue for the variables draft, it could say that the
search must be short-circuited (given, but perhaps not strongly enough
worded in existing documents), and the search done in first to last
order.  would that be appropriate?

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PMu8t2031039 for <[e-mail]>; Fri, 25 Apr 2003 15:56:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PMu8Ja031038 for ietf-mta-filters-bks; Fri, 25 Apr 2003 15:56:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PMu7t2031026 for <[e-mail]>; Fri, 25 Apr 2003 15:56:07 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3PMu4Fe013945 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Fri, 25 Apr 2003 15:56:04 -0700 (PDT)
Received: from jutta.sendmail.com (newshell.Sendmail.COM [209.246.26.43]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3PMu4qu014524 for <[e-mail]>; Fri, 25 Apr 2003 15:56:04 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 312F3179B3; Fri, 25 Apr 2003 15:55:52 -0700 (PDT)
Date: Fri, 25 Apr 2003 15:55:52 -0700
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: Soure routes vs. "address" (was: Re: request for clarification)
Message-ID: <[e-mail]>
References: <1051305197.1153.36.camel@lever> <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3PMu4qu014524
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 Fri, Apr 25, 2003 at 03:03:36PM -0700, Philip Guenther explains:
> 
> The "@foo.com,@bar.com:" part is a source route.  The Sieve rfc is just
> saying that tests must act as if the address didn't include the source
> route when determining whether they match.

Hm!  Now that you mention it, the fact that RFC 3028 says that about
_envelope_ addresses only and not about _all_ e-mail addresses (that is,
also the ones used with "address") seems like an omission to me.

The text about the "address" test excludes comments and groups from the
comparison, but doesn't mention source routes:

#  The address primitive never acts on the phrase part of an email
#  address, nor on comments within that address.  It also never acts on
#  group names, although it does act on the addresses within the group
#  construct.

Source routes are part of the RFC 2822 "obs-angle-addr" nonterminal,
and RFC 2822 asks that they be ignored:

#  When interpreting addresses, the route portion SHOULD be ignored.

Is there any reason not to always throw out the source route?

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PM50t2028913 for <[e-mail]>; Fri, 25 Apr 2003 15:05:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PM50tC028912 for ietf-mta-filters-bks; Fri, 25 Apr 2003 15:05:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PM50t2028904 for <[e-mail]>; Fri, 25 Apr 2003 15:05:00 -0700 (PDT) (envelope-from [e-mail])
Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3PM4fFd009475; Fri, 25 Apr 2003 15:04:41 -0700 (PDT)
Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3PM6Me04858; Fri, 25 Apr 2003 15:06:22 -0700 (PDT)
Message-Id: <[e-mail]>
To: Keith Grennan <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: request for clarification "MUST drop source routes" 
In-reply-to: <1051305197.1153.36.camel@lever> 
References: <1051305197.1153.36.camel@lever> 
Date: Fri, 25 Apr 2003 15:03:36 -0700
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>

Keith Grennan <[e-mail]> writes:
>I was wondering if someone could expand on the following:
>
>All tests against envelopes MUST drop source routes.
>
>What is a "source route" in this context and how does one drop it?

These are described in rfc2821.  An example would be:
	<@foo.com,@bar.com:[e-mail]>

The "@foo.com,@bar.com:" part is a source route.  The Sieve rfc is just
saying that tests must act as if the address didn't include the source
route when determining whether they match.  So, if the above address
occured in the envelope 'to', then the test

	envelope :all :contains "to" "foo.com"

must fail, while the test

	envelope :all :is "[e-mail]"

must succeed.


Philip Guenther
[e-mail]


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PLDNt2027062 for <[e-mail]>; Fri, 25 Apr 2003 14:13:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PLDN7p027060 for ietf-mta-filters-bks; Fri, 25 Apr 2003 14:13:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.ActiveState.com (gw.activestate.com [209.17.183.249]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PLDLt2027052 for <[e-mail]>; Fri, 25 Apr 2003 14:13:21 -0700 (PDT) (envelope-from [e-mail])
Received: from smtp3.ActiveState.com (smtp3.ActiveState.com [192.168.3.19]) by smtp1.ActiveState.com (8.12.9/8.12.9) with ESMTP id h3PLDIHt023852 for <[e-mail]>; Fri, 25 Apr 2003 14:13:18 -0700
Received: from lever.ActiveState.com (lever.ActiveState.com [192.168.3.216]) by smtp3.ActiveState.com (8.12.9/8.12.9) with ESMTP id h3PLDIXj012982 for <[e-mail]>; Fri, 25 Apr 2003 14:13:18 -0700
Subject: request for clarification "MUST drop source routes"
From: Keith Grennan <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Organization: 
Message-Id: <1051305197.1153.36.camel@lever>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 25 Apr 2003 14:13:17 -0700
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>

Hi,

I was wondering if someone could expand on the following:

All tests against envelopes MUST drop source routes.

What is a "source route" in this context and how does one drop it?

Thanks,
Keith



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3P4Twt2044614 for <[e-mail]>; Thu, 24 Apr 2003 21:29:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3P4TwrV044613 for ietf-mta-filters-bks; Thu, 24 Apr 2003 21:29:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3P4Tst2044608 for <[e-mail]>; Thu, 24 Apr 2003 21:29:57 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 24 Apr 2003 21:29:47 -0700 (PDT)
Date: Thu, 24 Apr 2003 21:20:54 -0700 (PDT)
From: [e-mail]
Subject: Re: Three new drafts and a question
In-reply-to: "Your message dated Thu, 24 Apr 2003 19:19:31 -0700" <[e-mail]>
To: Jutta Degener <[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]> <[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>

> On Thu, Apr 24, 2003 at 11:08:49AM -0700, [e-mail] wrote:
> [editheader]
> >     I prefer the approach of having a single argument,
> >     which can either be a string specifying a single field or a list
> >     specifying multiple fields.

> Hm, you mean a real ["foo", "bar"] list, or a chunk of text
> that becomes the header?


I mean ["Comment: 1", "Comment: 2"].

> If you're using ["foo", "bar"], you'll quickly run into the
> lack of list operations and -variables.

I don't think so. But we can handle that fairly easily by saying empty
strings add nothing.

> If you're using a big chunk of text, I think it will still have
> to be parsed into names and values and checked or, more likely,
> reformatted.  I don't like doing that, not so much for efficiency
> reasons but because it pretends to the script writer that they're
> touching the true outgoing header when I really can't let them
> do that.

I agree. I don't think the chunk of text approach is appropriate.

> Do you have a usage scenario where a single string vs. multiple
> makes a big difference?

Not really. It just looks better to have all of the fields added in a
single operation.

> > (2) I sure wish we'd allowed signed integers as numbers in the base sieve
> >     specification. If we had them available we could use negative indices
> >     to represent offsets from the last occurence of a given field.

> Yeah, that would be nice, but I couldn't get it to work either.

OK. Just wanted to check and see if there was something I was missing.

> > (3) I see considerable value in addheader and deleteheader. Replaceheader,
> >     however, goes a bit too far for my tastes. Do we really need this? Is
> >     it worth the complexity?

> The "replaceheader" command started out as a "tagheader" command
> that just gave its user a choice of adding a prefix or a suffix.

> The original audience for this was users with message stores that
> don't support direct fileinto.  They can tag their messages by adding
> or changing the Subject: line, and then filter based on the Subject
> line in their browsers.

> Then people wanted an "untagheader" command, and didn't generally
> respond well to the complexity of picking a header vs. the simplicity
> of what I let them do it once they had it, so "replaceheader"
> replaced the "tag" and "untag" versions and got a little more solid.

> We can argue whether :newname has any business being there, though.

Good point. Even if we retain replaceheader I'd argue that :newname should
go. You can always get the effect by deleting and adding.

There's also the question of the interaction of a replaceheader
aimed at the third instance of one field being renamed to a field that
already exists.

> > > <http://www.ietf.org/internet-drafts/draft-degener-sieve-multiscript-00.txt>
> > >
> > > 	Sequential execution of (unrelated) sieve scripts by the
> > > 	environment.  A meta-feature -- it doesn't define new sieve
> > > 	language elements -- that's interesting in particular in
> > > 	contrast to Cyrus's "include" draft.
> >
> > Hmm. The approach taken here is very similar but not quite identical to the
> > approach I've used to combine multiple scripts. We agree in that any script
> > that ends in an implicit keep in effect cedes control to the next script
> > in the sequence, and that the explicit actions reject, fileinto, and
> > redirect that cancel implicit keep prevent subsequent scripts from running.
> >
> > The place where we differ is in the handling of explicit keep. The draft calls
> > for subsequent scripts to be called. I don't do that; in my implementation an
> > explicit keep prevents subsequent scripts from acting.

> Interesting.  I've had some push-back about that, too, where colleagues
> felt (and probably still feel) uncomfortable that the system would react
> to an explicit command with this big-brotheresque "well, you're saying you
> want to keep the message, but what you _really_ may want is to give it the
> default trailing script treatment".

> > I don't think this is something I can change at this point either. One of the
> > things that's often done is to have some kind of filtering in a system-level
> > sieve script. That script may elect to discard a message. I wanted the ability
> > for users to override such system-level decisions by issuing an explicit
> > "keep" in their scripts. This trick got documented and is now in use.

> We'd just have used "fileinto "INBOX"" for that, but okay.  And of
> course you might not have "fileinto".

Good point. Since I implement it I tend to forget it is optional...

> > There's also one semantics issue I see here: RFC 3028 says that fileinto
> > "INBOX" and "keep" are equivalent in an IMAP environment. This specification
> > tweaks that equivalence somewhat.

> Yeah, I know...

> I guess the alternative here is to make explicit keep and implicit
> keep once again behave differently.  That's ugly, but it does seem
> to be closer to expectations.

> Did you ever run into a situation where that gave you trouble --
> where you wished you could have an explicit implicit keep?

I don't believe I ever have. But it is hard to predict what is going to
happen once variables are available. I suspect they are going to
change usage patterns fairly substantially, and it is hard to know which
of these little quirks of the language are going to prove problematic.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3P2Jjt2039970 for <[e-mail]>; Thu, 24 Apr 2003 19:19:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3P2JjcN039969 for ietf-mta-filters-bks; Thu, 24 Apr 2003 19:19:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3P2Jet2039951 for <[e-mail]>; Thu, 24 Apr 2003 19:19:44 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3P2JfFe024411 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Thu, 24 Apr 2003 19:19:42 -0700 (PDT)
Received: from jutta.sendmail.com (newshell.Sendmail.COM [209.246.26.43]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3P2Jfqu027840 for <[e-mail]>; Thu, 24 Apr 2003 19:19:41 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 26CD2179B3; Thu, 24 Apr 2003 19:19:31 -0700 (PDT)
Date: Thu, 24 Apr 2003 19:19:31 -0700
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: Re: Three new drafts and a question
Message-ID: <[e-mail]>
References: <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3P2Jfqu027840
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 Thu, Apr 24, 2003 at 11:08:49AM -0700, [e-mail] wrote:
[editheader]
>     I prefer the approach of having a single argument,
>     which can either be a string specifying a single field or a list
>     specifying multiple fields.

Hm, you mean a real ["foo", "bar"] list, or a chunk of text
that becomes the header?

If you're using ["foo", "bar"], you'll quickly run into the
lack of list operations and -variables.

If you're using a big chunk of text, I think it will still have
to be parsed into names and values and checked or, more likely,
reformatted.  I don't like doing that, not so much for efficiency
reasons but because it pretends to the script writer that they're
touching the true outgoing header when I really can't let them
do that.

Do you have a usage scenario where a single string vs. multiple
makes a big difference?

> (2) I sure wish we'd allowed signed integers as numbers in the base sieve
>     specification. If we had them available we could use negative indices
>     to represent offsets from the last occurence of a given field.

Yeah, that would be nice, but I couldn't get it to work either.

> (3) I see considerable value in addheader and deleteheader. Replaceheader,
>     however, goes a bit too far for my tastes. Do we really need this? Is
>     it worth the complexity?

The "replaceheader" command started out as a "tagheader" command
that just gave its user a choice of adding a prefix or a suffix.

The original audience for this was users with message stores that
don't support direct fileinto.  They can tag their messages by adding
or changing the Subject: line, and then filter based on the Subject
line in their browsers.

Then people wanted an "untagheader" command, and didn't generally
respond well to the complexity of picking a header vs. the simplicity
of what I let them do it once they had it, so "replaceheader"
replaced the "tag" and "untag" versions and got a little more solid.

We can argue whether :newname has any business being there, though.

> > <http://www.ietf.org/internet-drafts/draft-degener-sieve-multiscript-00.txt>
> > 	
> > 	Sequential execution of (unrelated) sieve scripts by the
> > 	environment.  A meta-feature -- it doesn't define new sieve
> > 	language elements -- that's interesting in particular in
> > 	contrast to Cyrus's "include" draft.
> 
> Hmm. The approach taken here is very similar but not quite identical to the
> approach I've used to combine multiple scripts. We agree in that any script
> that ends in an implicit keep in effect cedes control to the next script
> in the sequence, and that the explicit actions reject, fileinto, and
> redirect that cancel implicit keep prevent subsequent scripts from running.
> 
> The place where we differ is in the handling of explicit keep. The draft calls
> for subsequent scripts to be called. I don't do that; in my implementation an
> explicit keep prevents subsequent scripts from acting.

Interesting.  I've had some push-back about that, too, where colleagues
felt (and probably still feel) uncomfortable that the system would react
to an explicit command with this big-brotheresque "well, you're saying you
want to keep the message, but what you _really_ may want is to give it the
default trailing script treatment".

> I don't think this is something I can change at this point either. One of the
> things that's often done is to have some kind of filtering in a system-level
> sieve script. That script may elect to discard a message. I wanted the ability
> for users to override such system-level decisions by issuing an explicit
> "keep" in their scripts. This trick got documented and is now in use.

We'd just have used "fileinto "INBOX"" for that, but okay.  And of
course you might not have "fileinto".

> There's also one semantics issue I see here: RFC 3028 says that fileinto
> "INBOX" and "keep" are equivalent in an IMAP environment. This specification
> tweaks that equivalence somewhat.

Yeah, I know...

I guess the alternative here is to make explicit keep and implicit
keep once again behave differently.  That's ugly, but it does seem
to be closer to expectations.

Did you ever run into a situation where that gave you trouble --
where you wished you could have an explicit implicit keep?

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ON8rt2032559 for <[e-mail]>; Thu, 24 Apr 2003 16:08:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3ON8qGj032558 for ietf-mta-filters-bks; Thu, 24 Apr 2003 16:08:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ON8pt2032553 for <[e-mail]>; Thu, 24 Apr 2003 16:08:51 -0700 (PDT) (envelope-from [e-mail])
Received: from ellifu.ifi.uio.no ([129.240.65.211]) by pat.uio.no with esmtp (Exim 2.12 #7) id 198ppk-0004Hc-00 for [e-mail]; Fri, 25 Apr 2003 01:08:52 +0200
Received: (from kjetilho@localhost) by ellifu.ifi.uio.no ; Fri, 25 Apr 2003 01:08:52 +0200 (MEST)
To: [e-mail]
Subject: Re: Three new drafts and a question
References: <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 25 Apr 2003 01:08:52 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 103
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>

[Jutta Degener]:
>
>   I sent out three new sieve drafts last week that may be of interest:
>   
>    <http://www.ietf.org/internet-drafts/draft-degener-sieve-copy-00.txt>
>     	
>   	fileinto :copy, redirect :copy -- keyword parameter that
>   	prevents cancelling the implicit "keep".

great idea!  a small typo, quotes are missing around ":copy" in

   Syntax:
        "fileinto" [:copy] <folder: string>
        "redirect" [:copy] <folder: string>

>    <http://www.ietf.org/internet-drafts/draft-degener-sieve-editheader-00.txt>
>     	Deleting, adding, and changing message header fields.


| 5. Action replaceheader
|    [...]
|    The field-name is mandatory and always matched as a
|    case-insensitive us-ascii string.

I take it you mean an exact match (:is) ?  the following shouldn't
work:

   replaceheader "Original-*" :newname "${1}"

but it would be interesting, eh?  actually, :matches could be the
mandatory match type for the field-name, I don't think it influences
the rest.  if you do

   replaceheader "Original-*" :newname "${1}" :matches "*foo" :newvalue "${1}"

this will _not_ work, since the value match will run after the field
name match, and thus destroy the contents of the back references.

btw, it is interesting that this extension requires variable
references in strings to be resolved inside the action itself.  it
makes me wonder if I should add a "Note to implementers" in the
variables draft about this.

| 7. Security Considerations
|    [...]
|    A sieve filter that removes headers may unwisely destroy
|    evidence about the path a header has taken.

perhaps tampering with "Received" should be explicitly forbidden.
(even with that restriction, the above warning must be kept.)

>    <http://www.ietf.org/internet-drafts/draft-degener-sieve-multiscript-00.txt>
>     	
>   	Sequential execution of (unrelated) sieve scripts by the
>   	environment.  A meta-feature -- it doesn't define new sieve
>   	language elements -- that's interesting in particular in
>   	contrast to Cyrus's "include" draft.

yes, I think they both are useful.  this is for site configuration,
"include" is for user convenience.

| 4. Locality of script actions
|    [...]
|    For sieve engines that implement the "variables" extension,
|    variable state is not carried over between scripts.

I think this is the right choice, since a set of scripts using
"include" should be considered _one_ script and variable state thus
carry over in that single script.  this also fits in with:

|    The "stop;" command ends the execution of its single
|    containing script, not of scripts in general.

so the "return" in Cyrus's draft is still useful.

I agree that a capability string is unnecessary.

>   There may or may not be another one for fileinto in the wings.
>   It's about Kjetil's open issue 0.3 b):
>   
>   Some implementations of "fileinto" create IMAP folders on the
>   fly if they don't exist; others don't.  (They redirect to
>   the inbox instead.)  Sieve doesn't proscribe either way.
>   
>   My own implementation used to only reuse existing folders; but now
>   that we're thinking about creating them on demand in conjunction
>   with the "variables" extension, I'm getting requests for a way for
>   a user to express their intention; something like
>   
>   	fileinto :create 	"If it doesn't exist, create it"
>   or
>   	fileinto :exists	"If it doesn't exist, redirect to INBOX."
>   
>   or something in that area.

it is unfortunate that behaviour is undefined.  both behaviours are
useful, so I think both should be in the draft.  well, the draft could
instead mandate fileinto to file into INBOX if the folder doesn't
exist and ":create" isn't specified.  this can also serve as a hint to
new implementers of Sieve.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OMxZt2032285 for <[e-mail]>; Thu, 24 Apr 2003 15:59:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OMxZwW032284 for ietf-mta-filters-bks; Thu, 24 Apr 2003 15:59:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OMxXt2032279 for <[e-mail]>; Thu, 24 Apr 2003 15:59:34 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 24 Apr 2003 15:59:32 -0700 (PDT)
Date: Thu, 24 Apr 2003 11:08:49 -0700 (PDT)
From: [e-mail]
Subject: Re: Three new drafts and a question
In-reply-to: "Your message dated Wed, 23 Apr 2003 13:14:05 -0700" <[e-mail]>
To: Jutta Degener <[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]>
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 sent out three new sieve drafts last week that may be of interest:

>  <http://www.ietf.org/internet-drafts/draft-degener-sieve-copy-00.txt>
  	
> 	fileinto :copy, redirect :copy -- keyword parameter that
> 	prevents cancelling the implicit "keep".

This isn't a problem I've seen myself, but it seems like a reasonable
thing to have and the implementation burden should be low.

>  <http://www.ietf.org/internet-drafts/draft-degener-sieve-editheader-00.txt>

>   	Deleting, adding, and changing message header fields.

I see several issues here:

(1) The use of separate field-name/field-value arguments to specify a header
    field matches up nicely with the header test. But it effectively precludes
    specification of more than one header in a single addheader or
    deleteheader command. I prefer the approach of having a single argument,
    which can either be a string specifying a single field or a list
    specifying multiple fields.

(2) I sure wish we'd allowed signed integers as numbers in the base sieve
    specification. If we had them available we could use negative indices
    to represent offsets from the last occurence of a given field. This in
    turn would make it possible to specify ranges of fields in deleteheader
    fairly easily. I wish I had an alternative to suggest here that would
    give us this functionality, but I don't.

(3) I see considerable value in addheader and deleteheader. Replaceheader,
    however, goes a bit too far for my tastes. Do we really need this? Is
    it worth the complexity?

>  <http://www.ietf.org/internet-drafts/draft-degener-sieve-multiscript-00.txt>
  	
> 	Sequential execution of (unrelated) sieve scripts by the
> 	environment.  A meta-feature -- it doesn't define new sieve
> 	language elements -- that's interesting in particular in
> 	contrast to Cyrus's "include" draft.

Hmm. The approach taken here is very similar but not quite identical to the
approach I've used to combine multiple scripts. We agree in that any script
that ends in an implicit keep in effect cedes control to the next script in the
sequence, and that the explicit actions reject, fileinto, and redirect that
cancel implicit keep prevent subsequent scripts from running.

The place where we differ is in the handling of explicit keep. The draft calls
for subsequent scripts to be called. I don't do that; in my implementation an
explicit keep prevents subsequent scripts from acting.

I don't think this is something I can change at this point either. One of the
things that's often done is to have some kind of filtering in a system-level
sieve script. That script may elect to discard a message. I wanted the ability
for users to override such system-level decisions by issuing an explicit "keep"
in their scripts. This trick got documented and is now in use.

I suppose I could always implement an option to control how explicit keeps
affect the operation of multiple scripts.

There's also one semantics issue I see here: RFC 3028 says that fileinto
"INBOX" and "keep" are equivalent in an IMAP environment. This specification
tweaks that equivalence somewhat.

> There may or may not be another one for fileinto in the wings.
> It's about Kjetil's open issue 0.3 b):

> Some implementations of "fileinto" create IMAP folders on the
> fly if they don't exist; others don't.  (They redirect to
> the inbox instead.)  Sieve doesn't proscribe either way.

> My own implementation used to only reuse existing folders; but now
> that we're thinking about creating them on demand in conjunction
> with the "variables" extension, I'm getting requests for a way
> for a user to express their intention; something like

> 	fileinto :create 	"If it doesn't exist, create it"
> or
> 	fileinto :exists	"If it doesn't exist, redirect to INBOX."

> or something in that area.

> Is anyone hearing similar requests from their users?
> Have you thought about the issue and come to conclusions for
> your own releases?

We opted for the other course: We create new folders on demand. Thus far I
don't believe we've gotten requests for "only file to folders that already
exist", but of course that could change once variables support is available.

I have no problem with implementing such an extension in any case.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OHa7t2018597 for <[e-mail]>; Thu, 24 Apr 2003 10:36:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OHa7Ew018596 for ietf-mta-filters-bks; Thu, 24 Apr 2003 10:36:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OHa5t2018591 for <[e-mail]>; Thu, 24 Apr 2003 10:36:06 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3OHa5Fe006082 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Thu, 24 Apr 2003 10:36:05 -0700 (PDT)
Received: from jutta.sendmail.com (newshell.Sendmail.COM [209.246.26.43]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3OHa2qu026458 for <[e-mail]>; Thu, 24 Apr 2003 10:36:03 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 5C351179B3; Thu, 24 Apr 2003 10:35:57 -0700 (PDT)
Date: Thu, 24 Apr 2003 10:35:57 -0700
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: Re: variables: greedy or non-greedy matching
Message-ID: <[e-mail]>
References: <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3OHa2qu026458
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 Thu, Apr 24, 2003 at 07:14:43AM -0700, [e-mail] wrote:
> Um, no. For the very small subset of users sophisticated enough to
> write this sort of code themselves, I believe their expectation will
> be set by past experience with other matching systems, and these
> systems tend to default to greedy matching.

I think even in that sophisticated subset, most people just live
their pattern-matching lives without really thinking about the
difference.

But admittedly, my own expectations are muddy, and, worse,
seem to change with the lexical structure of the pattern. 
Speaking naively -- I know that this isn't how things work
or should work --

* If the end of my pattern is part of a grammatical whole, I want
  the wildcard to  be greedy; certainly, I, too, would expect
  "f*o" to fully match "foo", not to stop after the first "o".

* But if the end of my pattern is a delimiter, I tend to implicitly
  expect the expression be defined as something that doesn't
  contain that delimiter, as in the example Kjetil quoted where few
  people would expect the * before a closing > in an e-mail address
  to itself contain another >.

I think what this all says is that what felt to me like a problem
with greed is really a problem with globbing and insufficient
expressiveness of * (regexps have problems, too, once you get
to comments and quoting, but one has to work a little harder to
make things fail.)

So let's stay greedy; thanks for setting me straight! 

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OGdTt2016702 for <[e-mail]>; Thu, 24 Apr 2003 09:39:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OGdT90016701 for ietf-mta-filters-bks; Thu, 24 Apr 2003 09:39:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OGdPt2016692 for <[e-mail]>; Thu, 24 Apr 2003 09:39:28 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 24 Apr 2003 07:16:55 -0700 (PDT)
Date: Thu, 24 Apr 2003 07:14:43 -0700 (PDT)
From: [e-mail]
Subject: Re: variables: greedy or non-greedy matching
In-reply-to: "Your message dated Thu, 24 Apr 2003 14:08:45 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[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]>
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 can not find any precedence for greedy/non-greedy matching in the
> RFC's (I only checked NNTP, I don't know where else to look).  it
> seems to me that previously, we have only been interested in
> TRUE/FALSE, _how_ the match was performed can not be observed.  the
> variables extension introduces ${<n>} which allows us to observe
> matching behaviour, and therefore whether to do greedy/non-greedy
> matching must be part of the variables specification.

> Jutta points out in private e-mail that greedy matching does not
> follow the prinicple of least surprise for ordinary users.  e.g., in

>   string :matches "<[e-mail]>, <[e-mail]>" "<*@foo.com>*"

> most users will probably expect ${1} to contain "alice", not
> "[e-mail]>, <bob".  change it into:

>   string :matches "<[e-mail]>, <[e-mail]>" "*<*@foo.com>*"
>                                                     ^
> and ${2} is now "bob"...  not intuitive, right?

Um, no. For the very small subset of users sophisticated enough to
write this sort of code themselves, I believe their expectation will
be set by past experience with other matching systems, and these
systems tend to default to greedy matching.

> this issue was raised here earlier, and by analogy with regular
> expressions, I claimed the wildcard "*" in :matches should match
> greedily.  this allows an implementation to convert a match string to
> a regular expression very easily, but is potentially confusing for
> users.

> non-greedy matching requires implementers to write their own matching
> code, or to use a regexp library which supports non-greedy matching.

> what do you think?

I prefer greedy matching.

> if we go for non-greedy, Jutta suggested using "**" as a special case
> to get greedy matching.  (actually, I think the rule should be that
> "*" followed by another wildcard is greedy.)  I'm not sure it is worth
> it, after all a site supporting variables will most likely also offer
> regex.

I don't think it is worth it either.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OFQHt2013711 for <[e-mail]>; Thu, 24 Apr 2003 08:26:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OFQHNH013710 for ietf-mta-filters-bks; Thu, 24 Apr 2003 08:26:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OFQEt2013698 for <[e-mail]>; Thu, 24 Apr 2003 08:26:15 -0700 (PDT) (envelope-from [e-mail])
Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3OFPwdg015384; Thu, 24 Apr 2003 11:25:58 -0400
Date: Thu, 24 Apr 2003 11:25:58 -0400 (EDT)
From: Rob Siemborski <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Re: Three new drafts and a question
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
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>

On Thu, 24 Apr 2003 [e-mail] wrote:

> Do we need a way to set the implicit keep flag? I can't think why right
> now; it just looks not symmetric that it can be reset or left alone, but
> not set.

Personally, I'd feel a little wierd about an "implicit" flag being
settable.

-Rob

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEolt2008416 for <[e-mail]>; Thu, 24 Apr 2003 07:50:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OEol2X008415 for ietf-mta-filters-bks; Thu, 24 Apr 2003 07:50:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEojt2008386 for <[e-mail]>; Thu, 24 Apr 2003 07:50:46 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout2.freenet.de with asmtp (Exim 4.15) id 198i3Z-0000U0-3K for [e-mail]; Thu, 24 Apr 2003 16:50:37 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with smtp (Exim 4.14 #2) id 198i3Y-0008Ob-TJ for [e-mail]; Thu, 24 Apr 2003 16:50:36 +0200
Received: (qmail 31198 invoked by uid 100); 24 Apr 2003 14:50:31 -0000
Date: 24 Apr 2003 14:50:31 -0000
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: Three new drafts and a question
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>

> >  <http://www.ietf.org/internet-drafts/draft-degener-sieve-copy-00.txt>
> >
> > fileinto :copy, redirect :copy -- keyword parameter that
> > prevents cancelling the implicit "keep".

That is certainly useful.

The Exim filter uses "seen" and "unseen" deliveries.  If any seen
deliveries take place, there is no implicit keep.  Each delivery of a
message has a default of being seen or unseen, that can be changed using
an option.  "seen" is like "discard", "unseen" is like ":copy".

I would prefer if the draft expressed more clearly that "keep" is not
symmetric to "discard", because keep stores the message, whereas discard
just clears the implicit keep.  In fact, RFC 3028 could be more clear
on that issue.  It gives a better motivation why ":copy" is needed, though.

Do we need a way to set the implicit keep flag? I can't think why right
now; it just looks not symmetric that it can be reset or left alone, but
not set.

Michael


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEANt2006034 for <[e-mail]>; Thu, 24 Apr 2003 07:10:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OEAM8S006033 for ietf-mta-filters-bks; Thu, 24 Apr 2003 07:10:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEALt2006028 for <[e-mail]>; Thu, 24 Apr 2003 07:10:22 -0700 (PDT) (envelope-from [e-mail])
Received: from SCOTTY (unverified [129.215.188.222]) by starship.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.3.3) with ESMTP id <[e-mail]>; Thu, 24 Apr 2003 15:09:26 +0100
Message-ID: <016f01c30a6b$1d0b63d0$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Jutta Degener" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Three new drafts and a question
Date: Thu, 24 Apr 2003 15:09:26 +0100
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>

> I sent out three new sieve drafts last week that may be of interest:

As if this list wasn't busy enough at the moment ;o)

>  <http://www.ietf.org/internet-drafts/draft-degener-sieve-copy-00.txt>
>
> fileinto :copy, redirect :copy -- keyword parameter that
> prevents cancelling the implicit "keep".

Spelling mistake in first line of this paragraph... should read "possible"

   It is possibly to generate sieve code that perfectly
    <snip>

Yeah I like this idea.  I found the whole interaction between implicit keep
and discard really difficult to get my head round.  this extension sounds
like it will help.

>
<http://www.ietf.org/internet-drafts/draft-degener-sieve-editheader-00.txt>
>
>   Deleting, adding, and changing message header fields.

Heh, was thinking of authoring one of these soon.  Thanks for beating me to
it.  I haven't been able to digest it in detail yet but it looks ok to me on
a first pass :o)

>
<http://www.ietf.org/internet-drafts/draft-degener-sieve-multiscript-00.txt>
>
> Sequential execution of (unrelated) sieve scripts by the
> environment.  A meta-feature -- it doesn't define new sieve
> language elements -- that's interesting in particular in
> contrast to Cyrus's "include" draft.

When you are doing server/domain level filtering, you might want to allow a
server script to file into a specific user folder.  So you could have a user
folder called "Bulk" or "Spam" or something, and the server level script
could have ask to file a message into that users "Bulk" folder (rather than
just delete it).

In MailSite we have server and domain level scripts, and there seemed to be
a few possible interpretations of the "fileinto" command.  Either it could:

a) "fileinto" a folder on the local file system
b) file into a folder of the target user (at server/domain level there may
be many recipients in the envelope at this stage)
c) file into a folder of the server/domain postmaster.

Sadly we chose a), which I thought was going to be the most useful, but now
we have a need to do b) as well.  So we were wondering if fileinto should
have some kind of arg to say:

    fileinto :filesystem "DirectoryName";

To file into the "DirectoryName" folder on the file system of the MTA, or

    fileinto "Spam";

To fileinto the Spam folder of the recipient (if local) or

    fileinto :user "Postmaster" "Spam";

To file into the Spam folder of the Postmaster mailbox.

I know most of this is probably a spearate extension, but the draft as it
stands implies that it's only Keep and implicit Keep actions in previous
scripts that can allow subsequent scripts to be executed, and I'm not sure
that's true.

I think fileinto(s) in a previous script should "change the location" of
where implicit keep would post the message.  Explicit Keep could probably
change the filed location to Inbox (or add Inbox if there were multiple
fileintos in a previous script).  Another fileinto would change the filed
location (or add the new folder if there were multiple fileintos in a
previous script).

I think we need to think through all this pretty carefully, but it'll be
worth it...

Cheers,

Nigel



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OC8nt2098122 for <[e-mail]>; Thu, 24 Apr 2003 05:08:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OC8n8c098121 for ietf-mta-filters-bks; Thu, 24 Apr 2003 05:08:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OC8lt2098115 for <[e-mail]>; Thu, 24 Apr 2003 05:08:47 -0700 (PDT) (envelope-from [e-mail])
Received: from ellifu.ifi.uio.no ([129.240.65.211]) by pat.uio.no with esmtp (Exim 2.12 #7) id 198fWw-0001xo-00 for [e-mail]; Thu, 24 Apr 2003 14:08:46 +0200
Received: (from kjetilho@localhost) by ellifu.ifi.uio.no ; Thu, 24 Apr 2003 14:08:46 +0200 (MEST)
To: [e-mail]
Subject: variables: greedy or non-greedy matching
From: Kjetil Torgrim Homme <[e-mail]>
Date: 24 Apr 2003 14:08:45 +0200
Message-ID: <[e-mail]>
Lines: 39
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>

I can not find any precedence for greedy/non-greedy matching in the
RFC's (I only checked NNTP, I don't know where else to look).  it
seems to me that previously, we have only been interested in
TRUE/FALSE, _how_ the match was performed can not be observed.  the
variables extension introduces ${<n>} which allows us to observe
matching behaviour, and therefore whether to do greedy/non-greedy
matching must be part of the variables specification.

Jutta points out in private e-mail that greedy matching does not
follow the prinicple of least surprise for ordinary users.  e.g., in

  string :matches "<[e-mail]>, <[e-mail]>" "<*@foo.com>*"

most users will probably expect ${1} to contain "alice", not
"[e-mail]>, <bob".  change it into:

  string :matches "<[e-mail]>, <[e-mail]>" "*<*@foo.com>*"
                                                    ^
and ${2} is now "bob"...  not intuitive, right?

this issue was raised here earlier, and by analogy with regular
expressions, I claimed the wildcard "*" in :matches should match
greedily.  this allows an implementation to convert a match string to
a regular expression very easily, but is potentially confusing for
users.

non-greedy matching requires implementers to write their own matching
code, or to use a regexp library which supports non-greedy matching.

what do you think?


if we go for non-greedy, Jutta suggested using "**" as a special case
to get greedy matching.  (actually, I think the rule should be that
"*" followed by another wildcard is greedy.)  I'm not sure it is worth
it, after all a site supporting variables will most likely also offer
regex.
-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NKECt2037758 for <[e-mail]>; Wed, 23 Apr 2003 13:14:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NKECX4037757 for ietf-mta-filters-bks; Wed, 23 Apr 2003 13:14:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NKEBt2037743 for <[e-mail]>; Wed, 23 Apr 2003 13:14:11 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3NKE7Fe012246 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Wed, 23 Apr 2003 13:14:08 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3NKE7qu001532 for <[e-mail]>; Wed, 23 Apr 2003 13:14:07 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 7D646179B3; Wed, 23 Apr 2003 13:14:05 -0700 (PDT)
Date: Wed, 23 Apr 2003 13:14:05 -0700
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: Three new drafts and a question
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3NKE7qu001532
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 sent out three new sieve drafts last week that may be of interest:

 <http://www.ietf.org/internet-drafts/draft-degener-sieve-copy-00.txt>
  	
	fileinto :copy, redirect :copy -- keyword parameter that
	prevents cancelling the implicit "keep".

 <http://www.ietf.org/internet-drafts/draft-degener-sieve-editheader-00.txt>

  	Deleting, adding, and changing message header fields.

 <http://www.ietf.org/internet-drafts/draft-degener-sieve-multiscript-00.txt>
  	
	Sequential execution of (unrelated) sieve scripts by the
	environment.  A meta-feature -- it doesn't define new sieve
	language elements -- that's interesting in particular in
	contrast to Cyrus's "include" draft.

There may or may not be another one for fileinto in the wings.
It's about Kjetil's open issue 0.3 b):

Some implementations of "fileinto" create IMAP folders on the
fly if they don't exist; others don't.  (They redirect to
the inbox instead.)  Sieve doesn't proscribe either way.

My own implementation used to only reuse existing folders; but now
that we're thinking about creating them on demand in conjunction
with the "variables" extension, I'm getting requests for a way
for a user to express their intention; something like 

	fileinto :create 	"If it doesn't exist, create it"
or
	fileinto :exists	"If it doesn't exist, redirect to INBOX."

or something in that area.

Is anyone hearing similar requests from their users?
Have you thought about the issue and come to conclusions for
your own releases?

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3M5NAt2073291 for <[e-mail]>; Mon, 21 Apr 2003 22:23:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3M5NAIX073289 for ietf-mta-filters-bks; Mon, 21 Apr 2003 22:23:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3M5N5t2073284 for <[e-mail]>; Mon, 21 Apr 2003 22:23:09 -0700 (PDT) (envelope-from [e-mail])
Received: from messagingdirect.com (1Cust66.tnt3.edmonton.ab.da.uu.net [64.10.184.66]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3M5MxV18408; Mon, 21 Apr 2003 23:23:04 -0600
Message-ID: <[e-mail]>
Date: Mon, 21 Apr 2003 22:44:21 -0600
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: Jutta Degener <[e-mail]>
CC: [e-mail]
Subject: Imapflags and variables (was Re: List variables in Sieve)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

[I've modified the subject once again to reflect our current discussion].

Jutta Degener wrote:

> On Sat, Apr 19, 2003 at 04:54:09AM -0700, [e-mail] wrote:
> > > After I rewrote my example in "imapflags" I've realised how ugly this will
> > > look, because
> > > 1). The script author has to remember all flags that were set on the
> > > message and specify them all.
>
> Hm!  I thought of that as an advantage, not a downside.

See below.

> > > 2). setflags has to be replaced with multiple "set"s as we have to clear
> > > all flags.
>
> Similarly, I don't think that it's so bad that we get a list
> of what flags are available that way.
>
> Maybe we have very different applications in mind.  To me, the range
> of flags is severely limited by the ability of clients to display
> them and use them in the interface, and by the ability of users to
> remember and use them.
>
> Can you describe a typical application of your multitude of flags?

I am think from the point of view of a user writing scripts by hand, not scripts
generated by UI.
Also, I am thinking more in IMAP terms, i.e. each script is a list of blocks like
this:

if <condition> add/remove <flag>;

I don't want an end user to require to remember at each point in the script which
flags are to be set on the message.
IMHO, this reduces script complexity and, as a result, user errors.

> > > So, I am thinking now about using a single string parameter (instead of a
> > > string list) that contains space delimited flags. Adding flags (old
> > > "addflags") to the list would be simpler, e.g.
> >
> > > set "flags" "${flags} \\Seen"
> >
> > I was wondering if we'd eventually get to this. I'm not delighted by it, but
> > I think it probably is the best solution to the problem.
>
> I'd like to get a better understanding of the problem first.
>
> This is introducing a second list type with roughly the same function
> as the existing one, making sieve in the long term more expensive to

> implement and harder to understand; because now, every time you specify
> a list, you'll have to ask yourself whether it was type A or type B.

I don't think I share your concern. If you are afraid that this will open gates to
multiple Sieve extensions that misuse strings,
Sieve mailing list exists not to let such extensions be standardized.

All functionality required is already available in the base Sieve document or the
variable draft. So, my proposal doesn't make it harder to implement.

Besides, if you want to be explicit, you can still use "${flag1} ${flag2}
${flag3}" construct instead of specifying a single variable.
So, UI-generated scripts are still possible with my proposal.

And yes, I grew up as a Pascal programmer as well and I miss set types and set
related operations ;-).

> > > "removeflags" would be trickier to implement, but "string" test with
> > > :matches can be used to test if a flag was set, e.g.
> >
> > > if string :matches "${flags}" "*\\Draft*" {
> > >     set "flags" "${1}${2}"
> > > }
>
> The mistake in this expression -- it'll match \Draft as well
> as \DraftBeer

Good catch.

> -- will be made many times over, and mostly without
> harm, in scripts all over the world.

Hopefully, if a correct example is shown in the document, everybody will just
cut&paste it.

> It can be fixed by using trailing
> white space in both the matches and the flags string, but I don't
> think most authors will remember to do that.

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

Work Phone: [phone]
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LEj5t2048811 for <[e-mail]>; Mon, 21 Apr 2003 07:45:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LEj5QX048810 for ietf-mta-filters-bks; Mon, 21 Apr 2003 07:45:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LEj0t2048802 for <[e-mail]>; Mon, 21 Apr 2003 07:45:04 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3LEixFe026460 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Mon, 21 Apr 2003 07:45:00 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3LEivqu017641 for <[e-mail]>; Mon, 21 Apr 2003 07:44:59 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id DD32D179B3; Mon, 21 Apr 2003 07:44:12 -0700 (PDT)
Date: Mon, 21 Apr 2003 07:44:12 -0700
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft (draft-homme-sieve-variables-00.txt))
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3LEivqu017641
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 Sat, Apr 19, 2003 at 04:54:09AM -0700, [e-mail] wrote:
> > After I rewrote my example in "imapflags" I've realised how ugly this will
> > look, because
> > 1). The script author has to remember all flags that were set on the
> > message and specify them all.

Hm!  I thought of that as an advantage, not a downside.

> > 2). setflags has to be replaced with multiple "set"s as we have to clear
> > all flags.

Similarly, I don't think that it's so bad that we get a list
of what flags are available that way.

Maybe we have very different applications in mind.  To me, the range
of flags is severely limited by the ability of clients to display
them and use them in the interface, and by the ability of users to
remember and use them.

Can you describe a typical application of your multitude of flags?

> > So, I am thinking now about using a single string parameter (instead of a
> > string list) that contains space delimited flags. Adding flags (old
> > "addflags") to the list would be simpler, e.g.
> 
> > set "flags" "${flags} \\Seen"
> 
> I was wondering if we'd eventually get to this. I'm not delighted by it, but
> I think it probably is the best solution to the problem.

I'd like to get a better understanding of the problem first.

This is introducing a second list type with roughly the same function
as the existing one, making sieve in the long term more expensive to
implement and harder to understand; because now, every time you specify
a list, you'll have to ask yourself whether it was type A or type B.

> > "removeflags" would be trickier to implement, but "string" test with
> > :matches can be used to test if a flag was set, e.g.
> 
> > if string :matches "${flags}" "*\\Draft*" {
> >     set "flags" "${1}${2}"
> > }

The mistake in this expression -- it'll match \Draft as well
as \DraftBeer -- will be made many times over, and mostly without
harm, in scripts all over the world.  It can be fixed by using trailing
white space in both the matches and the flags string, but I don't
think most authors will remember to do that.

> Very cute. How to folks who precompile all this stuff feel about allowing
> this sort of variable pattern?

Well, you can't (precompile all this stuff), so what's the use.

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K2lMt2029288 for <[e-mail]>; Sat, 19 Apr 2003 19:47:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K2lM2m029287 for ietf-mta-filters-bks; Sat, 19 Apr 2003 19:47:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K2lIt2029282 for <[e-mail]>; Sat, 19 Apr 2003 19:47:19 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 19 Apr 2003 19:47:15 -0700 (PDT)
Date: Sat, 19 Apr 2003 19:45:31 -0700 (PDT)
From: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
In-reply-to: "Your message dated Sat, 19 Apr 2003 22:35:32 +0200" <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Kjetil Torgrim Homme <[e-mail]>, [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]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> Kjetil Torgrim Homme <[e-mail]> writes:

> >>   >>    For an example of a less general than expected test,
> >>   >>    consider looking for Subject: containing "MAKE MONEY FAST"
> >>   >>    to filter spam into a separate folder, and an incoming
> >>   >>    message having a Subject: of "=?CP-1252?q?MAKE_MONEY_FAST?=.
> >>   >
> >>   > I believe that message should be filtered just fine.
> >>
> >>   How?  Compare the following from RFC 3028 [2.7.2].  Assuming the
> >>   implementation does not support CP-1252, I don't see how "MAKE
> >>   MONEY FAST" and "=?CP-1252?q?MAKE_MONEY_FAST?=" would match.
> >
> > oh, I assumed that an implementation would decode quoted-printable and
> > base64, but mark the string as "unknown charset".  that seems to "do
> > what I want" more often.

> That approach would only work, for this example, if the unknown
> charset was ASCII compatible.  Of course, non-ASCII charset doesn't
> occur in practice, but I was talking about the case where the sender
> acts malicously to cause certain behaviour the user didn't think of.
> If picking a non-ASCII charset makes the client behave badly, the
> attacker will do so.

iso-2022-* charsets commonly occur in practice, and are not ASCII compatible
in this sense.

> But I agree that your draft isn't the place for these generic Sieve
> security considerations.

Exactly.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K1Pet2027296 for <[e-mail]>; Sat, 19 Apr 2003 18:25:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K1PeFd027295 for ietf-mta-filters-bks; Sat, 19 Apr 2003 18:25:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K1Pct2027287 for <[e-mail]>; Sat, 19 Apr 2003 18:25:38 -0700 (PDT) (envelope-from [e-mail])
Received: from mons.uio.no ([129.240.130.14]) by pat.uio.no with esmtp (Exim 2.12 #7) id 1973aN-0000sX-00 for [e-mail]; Sun, 20 Apr 2003 03:25:39 +0200
Received: from ellifu.ifi.uio.no ([129.240.65.211]) by mons.uio.no with esmtp (Exim 2.12 #7) id 1973Zt-0002mE-00 for [e-mail]; Sun, 20 Apr 2003 03:25:09 +0200
Received: (from kjetilho@localhost) by ellifu.ifi.uio.no ; Sun, 20 Apr 2003 03:25:02 +0200 (MEST)
To: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 20 Apr 2003 03:25:02 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 32
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>

[Ned Freed]:
>
>   > all right, the original idea for adding SETDATE was to use it with
>   > FILEINTO so that you could make archives "dynamically".  also, Sieve
>   > is typically used by the delivery agent.  the case where a Sieve
>   > client uses IMAP or similar to access the message store after delivery
>   > has taken place, is an edge case.  furthermore, the spec says
>   
>   In this case using the Date: field would be an exceedingly bad
>   idea. You don't want to let people add stuff to old archives
>   simply by setting the Date: field to a value in the past.

absolutely, using Date is worse than useless.  I've seen quite a few
mail archives which do that on the web, though...

>   IMO the ideal value to use here is "date of insertion into the
>   archive". The current date is a reasonable thing to use for
>   that. The Date: field is not.

I (as a user) think the ideal value is "date of original delivery".
unfortunately, there is currently no standard way of obtaining that
value, you'll have to dig around in Received and apply some sanity
checking.

>   I think it should refer to the time the filtering action was
>   taken, regardless of whether that was in the context of delivery
>   or later filtering.

noted.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JKZjt2021434 for <[e-mail]>; Sat, 19 Apr 2003 13:35:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JKZjgc021433 for ietf-mta-filters-bks; Sat, 19 Apr 2003 13:35:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JKZht2021428 for <[e-mail]>; Sat, 19 Apr 2003 13:35:44 -0700 (PDT) (envelope-from [e-mail])
Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3JKZWXK006180 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 19 Apr 2003 22:35:33 +0200
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
X-Payment: hashcash 1.2 0:030419:[e-mail]:7ac3972348b3efab
X-Hashcash: 0:030419:[e-mail]:7ac3972348b3efab
X-Payment: hashcash 1.2 0:030419:[e-mail]:1969512eec59d23d
X-Hashcash: 0:030419:[e-mail]:1969512eec59d23d
From: Simon Josefsson <[e-mail]>
Date: Sat, 19 Apr 2003 22:35:32 +0200
In-Reply-To: <[e-mail]> (Kjetil Torgrim Homme's message of "19 Apr 2003 15:40:04 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Face:  )=Tu!-Q9f9BQASOHl~_&4r0`,OQD2*=;cm+4]m[twz:8t5yt@xQW+:T$K%AdKq)`"g;C%>s /8w~Upcau`W2wh$=#"g7]"[2c;1Z/S:B49XEy$-YlaAGc'ZM&U*el'yQAD"c):Lc:fUD-S=\!EV;n@ 1Jff}
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>

Kjetil Torgrim Homme <[e-mail]> writes:

>>   >>    For an example of a less general than expected test,
>>   >>    consider looking for Subject: containing "MAKE MONEY FAST"
>>   >>    to filter spam into a separate folder, and an incoming
>>   >>    message having a Subject: of "=?CP-1252?q?MAKE_MONEY_FAST?=.
>>   >
>>   > I believe that message should be filtered just fine.
>>   
>>   How?  Compare the following from RFC 3028 [2.7.2].  Assuming the
>>   implementation does not support CP-1252, I don't see how "MAKE
>>   MONEY FAST" and "=?CP-1252?q?MAKE_MONEY_FAST?=" would match.
>
> oh, I assumed that an implementation would decode quoted-printable and
> base64, but mark the string as "unknown charset".  that seems to "do
> what I want" more often.

That approach would only work, for this example, if the unknown
charset was ASCII compatible.  Of course, non-ASCII charset doesn't
occur in practice, but I was talking about the case where the sender
acts malicously to cause certain behaviour the user didn't think of.
If picking a non-ASCII charset makes the client behave badly, the
attacker will do so.

But I agree that your draft isn't the place for these generic Sieve
security considerations.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JIgNt2018383 for <[e-mail]>; Sat, 19 Apr 2003 11:42:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JIgNAV018382 for ietf-mta-filters-bks; Sat, 19 Apr 2003 11:42:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JIgJt2018377 for <[e-mail]>; Sat, 19 Apr 2003 11:42:21 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 19 Apr 2003 11:42:17 -0700 (PDT)
Date: Sat, 19 Apr 2003 11:37:20 -0700 (PDT)
From: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
In-reply-to: "Your message dated Sat, 19 Apr 2003 15:29:50 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[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]> <[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>

> >   > oh!  if you run the Sieve script in batch, long after the
> >   > delivery was made, the current date is completely useless.
> >   > SETDATE should be changed to initialise the variables to the
> >   > time of delivery, not current time.
> >
> >   Um, no, it may well be that it is the value in the Date: field
> >   that is completely useless. It is all a question of what you're
> >   trying to achieve. [...]

> all right, the original idea for adding SETDATE was to use it with
> FILEINTO so that you could make archives "dynamically".  also, Sieve
> is typically used by the delivery agent.  the case where a Sieve
> client uses IMAP or similar to access the message store after delivery
> has taken place, is an edge case.  furthermore, the spec says

In this case using the Date: field would be an exceedingly bad idea. You don't
want to let people add stuff to old archives simply by setting the Date: field
to a value in the past.

IMO the ideal value to use here is "date of insertion into the archive". The
current date is a reasonable thing to use for that. The Date: field is not.


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

> so such a client is allowed to use Received headers or whatever it
> likes to find the date the user wants for SETDATE.  still, the intent
> is that it references the time of delivery.  for the typical use, the
> MDA, it doesn't make any difference.  for the standalone MFA (mail
> filtering agent), it does make a difference, and I think we should be
> explicit about what we want the MFA to do.

I think it should refer to the time the filtering action was taken,
regardless of whether that was in the context of delivery or later filtering.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JIaLt2018257 for <[e-mail]>; Sat, 19 Apr 2003 11:36:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JIaKc9018256 for ietf-mta-filters-bks; Sat, 19 Apr 2003 11:36:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JIaGt2018251 for <[e-mail]>; Sat, 19 Apr 2003 11:36:18 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 19 Apr 2003 11:36:12 -0700 (PDT)
Date: Sat, 19 Apr 2003 11:29:05 -0700 (PDT)
From: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
In-reply-to: "Your message dated Sat, 19 Apr 2003 14:30:39 +0200" <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail], [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]> <[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>

> > >    Filters relying on string matches in the raw body of an e-mail
> > >    message may be more general than intended.  Text matches are no
> > >    replacement for a virus or spam filtering system.

> > Of course they aren't. Have we really reached the point where we
> > have to belabor obvious points like this in security considerations sections?

> There are several solutions our there that claim to solve the email
> spam and virus problems with Sieve, encoding common spam and virus
> signatures in Sieve scripts (some are offering online access to
> updated Sieve scripts with new signatures).  People are being told,
> and believe, Sieve is the right tool for this.  Looking only at RFC
> 3028, I can't blame them.  It even contains examples on how to catch
> spam.

Specific examples of how to catch a specific sort of spam message do not
a general filtering system make.

Every month Bruce Schneier has a "doghouse" section in his Cryptogram column
detailing one product or another he considers to be "snake oil security". In
many cases these systems try and gain credibility by claiming that they employ
one security standard or another. Yet we don't try and document this sort of
possible misuse in the security standards we write. Instead we focus on what
the system is good for and what its technical limitations are. We don't try and
deflect marketing pitches. It isn't a game that's appropriate to play in the
"once written never changed" context of an RFC.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JEikt2012078 for <[e-mail]>; Sat, 19 Apr 2003 07:44:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JEikVn012077 for ietf-mta-filters-bks; Sat, 19 Apr 2003 07:44:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JEiet2012071 for <[e-mail]>; Sat, 19 Apr 2003 07:44:40 -0700 (PDT) (envelope-from [e-mail])
Received: from ellifu.ifi.uio.no ([129.240.65.211]) by pat.uio.no with esmtp (Exim 2.12 #7) id 196ta4-0003FR-00; Sat, 19 Apr 2003 16:44:40 +0200
Received: (from kjetilho@localhost) by ellifu.ifi.uio.no ; Sat, 19 Apr 2003 16:44:40 +0200 (MEST)
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: Integer variables
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 19 Apr 2003 16:44:40 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 48
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>

[Alexey Melnikov]:
>
>   Kjetil Torgrim Homme wrote:
>   
>   > the problem is rather that the variable can only be expanded
>   > inside a string, so it would lose its integer property.
>   
>   Which is fine, as long as this is documented.  I believe the
>   current document doesn't specify what types of variables are
>   allowed.  You have to either explicitly allow or prohibit this.

it is explicit already, if you look in the right place:

|   Syntax:   set [MODIFIER] [COMPARATOR] <name: string> <value: string>
                                                          =============

it doesn't say anything about variable references being usable outside
of string interpretation, I guess that could be more explicit, but the
overall Sieve grammar doesn't allow an unadorned variable reference as
a syntactic element.

(if a numeric variable was to be introduced, it seems to me that to
access it, changing the allowed values for QUANTIFIER to include a
variable-ref would be the way to go, i.e. 1${count}, ref. 1M.)

>   > do you have a use for integer variables?
>   
>   You already have the "length" function.

yes, it may be a bit silly.  a determined hacker can use it to convert
numbers in unary to decimal (I've had to do this during crash recovery
in singleuser mode on SunOS ;-), but the lack of a looping construct
will cramp his style.

>   I was thinking something along the lines of comparing
>   lengths/counting headers/scoring.  However this will probably
>   require some actions for simple arithmetic (+/-).

with regex, you can do:

    set "score" "${score}1";  # several times inside if-blocks

    if string :regex "${score}" "1{5,}" {
        # five or more hits ...
    }

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JDe5t2008280 for <[e-mail]>; Sat, 19 Apr 2003 06:40:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JDe5Tk008279 for ietf-mta-filters-bks; Sat, 19 Apr 2003 06:40:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JDe3t2008270 for <[e-mail]>; Sat, 19 Apr 2003 06:40:04 -0700 (PDT) (envelope-from [e-mail])
Received: from ellifu.ifi.uio.no ([129.240.65.211]) by pat.uio.no with esmtp (Exim 2.12 #7) id 196sZY-0006ek-00 for [e-mail]; Sat, 19 Apr 2003 15:40:04 +0200
Received: (from kjetilho@localhost) by ellifu.ifi.uio.no ; Sat, 19 Apr 2003 15:40:04 +0200 (MEST)
To: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 19 Apr 2003 15:40:04 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 31
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>

[Simon Josefsson]:
>
>   IMHO it is useful if all common pitfalls that lead to security
>   problems are discussed.

well, I don't think this is the place for it, it would fit better in a
revision of RFC 3028, or an informational RFC.

>   >>    For an example of a less general than expected test,
>   >>    consider looking for Subject: containing "MAKE MONEY FAST"
>   >>    to filter spam into a separate folder, and an incoming
>   >>    message having a Subject: of "=?CP-1252?q?MAKE_MONEY_FAST?=.
>   >
>   > I believe that message should be filtered just fine.
>   
>   How?  Compare the following from RFC 3028 [2.7.2].  Assuming the
>   implementation does not support CP-1252, I don't see how "MAKE
>   MONEY FAST" and "=?CP-1252?q?MAKE_MONEY_FAST?=" would match.

oh, I assumed that an implementation would decode quoted-printable and
base64, but mark the string as "unknown charset".  that seems to "do
what I want" more often.

>   The IDNA specification says that if IDNs are in IDN-unaware domain
>   name slots, it MUST be encoded as ASCII.  Since the Sieve
>   specification does not discuss IDN, all domain name slots in Sieve
>   scripts are IDN-unaware.

good to know, thanks.
-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JDTpt2007074 for <[e-mail]>; Sat, 19 Apr 2003 06:29:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JDTpLb007073 for ietf-mta-filters-bks; Sat, 19 Apr 2003 06:29:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JDTot2007068 for <[e-mail]>; Sat, 19 Apr 2003 06:29:50 -0700 (PDT) (envelope-from [e-mail])
Received: from ellifu.ifi.uio.no ([129.240.65.211]) by pat.uio.no with esmtp (Exim 2.12 #7) id 196sPe-00069a-00 for [e-mail]; Sat, 19 Apr 2003 15:29:50 +0200
Received: (from kjetilho@localhost) by ellifu.ifi.uio.no ; Sat, 19 Apr 2003 15:29:50 +0200 (MEST)
To: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 19 Apr 2003 15:29:50 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 35
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>

[Ned Freed]:
>
>   I really don't want to try and force this into the setdate
>   framework.  I'll see what I can do to write up the approach I have
>   in mind for this.

thanks.

>   > oh!  if you run the Sieve script in batch, long after the
>   > delivery was made, the current date is completely useless.
>   > SETDATE should be changed to initialise the variables to the
>   > time of delivery, not current time.
>   
>   Um, no, it may well be that it is the value in the Date: field
>   that is completely useless. It is all a question of what you're
>   trying to achieve. [...]

all right, the original idea for adding SETDATE was to use it with
FILEINTO so that you could make archives "dynamically".  also, Sieve
is typically used by the delivery agent.  the case where a Sieve
client uses IMAP or similar to access the message store after delivery
has taken place, is an edge case.  furthermore, the spec says

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

so such a client is allowed to use Received headers or whatever it
likes to find the date the user wants for SETDATE.  still, the intent
is that it references the time of delivery.  for the typical use, the
MDA, it doesn't make any difference.  for the standalone MFA (mail
filtering agent), it does make a difference, and I think we should be
explicit about what we want the MFA to do.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JCUit2004809 for <[e-mail]>; Sat, 19 Apr 2003 05:30:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JCUiZM004808 for ietf-mta-filters-bks; Sat, 19 Apr 2003 05:30:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JCUgt2004803 for <[e-mail]>; Sat, 19 Apr 2003 05:30:43 -0700 (PDT) (envelope-from [e-mail])
Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3JCUdXK032101 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 19 Apr 2003 14:30:40 +0200
To: [e-mail]
Cc: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
X-Payment: hashcash 1.2 0:030419:[e-mail]:a17cfc7f6f692ff4
X-Hashcash: 0:030419:[e-mail]:a17cfc7f6f692ff4
X-Payment: hashcash 1.2 0:030419:[e-mail]:960293418a157cf3
X-Hashcash: 0:030419:[e-mail]:960293418a157cf3
From: Simon Josefsson <[e-mail]>
Date: Sat, 19 Apr 2003 14:30:39 +0200
In-Reply-To: <[e-mail]> (ned freed's message of "Sat, 19 Apr 2003 04:29:53 -0700 (PDT)")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux)
References: <[e-mail]> <[e-mail]>
X-Face:  %bo>yc#X1.-jVa-<s"DQ^4?^PZAo;0a4~Kve&eC`.SGU_L!+28$Zb:is+#k/e?B1tjq7q0I nEu[-9[ohz4/Pc!?ivpiGu<BihTP5heHY).&A[se*\wf_!_#UkEo
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>

[e-mail] writes:

> A date test is also useful, but it is no replacement for the ability
> to test the current date.

Agreed, I want both.

> Additionally, if you are testing date information in the message header,
> while it may be useful to test the Date: field, there are actually quite
> a few other header fields that can contain date information that is even
> more useful to test.

Agreed, I want it the command to take a string that may be a variable,
so you can extract it from, e.g., Received headers.

>>    Filters relying on string matches in the raw body of an e-mail
>>    message may be more general than intended.  Text matches are no
>>    replacement for a virus or spam filtering system.
>
> Of course they aren't. Have we really reached the point where we 
> have to belabor obvious points like this in security considerations sections?

There are several solutions our there that claim to solve the email
spam and virus problems with Sieve, encoding common spam and virus
signatures in Sieve scripts (some are offering online access to
updated Sieve scripts with new signatures).  People are being told,
and believe, Sieve is the right tool for this.  Looking only at RFC
3028, I can't blame them.  It even contains examples on how to catch
spam.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JBuot2004153 for <[e-mail]>; Sat, 19 Apr 2003 04:56:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JBuoO9004152 for ietf-mta-filters-bks; Sat, 19 Apr 2003 04:56:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JBumt2004147 for <[e-mail]>; Sat, 19 Apr 2003 04:56:49 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 19 Apr 2003 04:56:40 -0700 (PDT)
Date: Sat, 19 Apr 2003 04:54:09 -0700 (PDT)
From: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft (draft-homme-sieve-variables-00.txt))
In-reply-to: "Your message dated Sat, 19 Apr 2003 01:21:53 -0600" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Jutta Degener <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=koi8-r
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> Alexey Melnikov wrote:

> > Jutta Degener wrote:
> >
> > > On Sun, Apr 13, 2003 at 05:53:40PM +0200, Kjetil Torgrim Homme wrote:
> > > > [Alexey Melnikov]:
> > > > >
> > > > >   In order to move imapflags extension forward I need support for
> > > > >   set/list variables.
> > >
> > > I think we might be able to do without this.  What if you allow
> > > (and ignore) empty strings in a [...] list?
> > >
> > > That way, you could set
> > >
> > >         set "aflag" "aflag"
> > >
> > >         ["${aflag}", "${bflag}", "${cflag}"]
> > >
> > > and have that come out as
> > >
> > >         ["aflag" "" ""]
> > >
> > > if bflag and cflag are unset.
> > >
> > > There are still things that you can do with a list algebra
> > > that you can't do with this approach -- infinitely many
> > > flags based on the header and body contents of a message --
> > > but I don't think we want to do those things badly enough
> > > to warrant adding three new commands and a variable data type.
> >
> > Surely three new actions shouldn't scare you :-).
> > But I understand the complexity of multiple data types.
> >
> > Ok, I can live with this.
> > It seems the only thing required to be said is that empty strings are
> > ignored in a list that specifies flags to be set.
> > I should also mention that each list member defines a separate flag and
> > spaces in flag names are not allowed (due to IMAP restriction).

> After I rewrote my example in "imapflags" I've realised how ugly this will
> look, because
> 1). The script author has to remember all flags that were set on the
> message and specify them all.
> 2). setflags has to be replaced with multiple "set"s as we have to clear
> all flags.

> So, I am thinking now about using a single string parameter (instead of a
> string list) that contains space delimited flags. Adding flags (old
> "addflags") to the list would be simpler, e.g.

> set "flags" "${flags} \\Seen"

I was wondering if we'd eventually get to this. I'm not delighted by it, but
I think it probably is the best solution to the problem.

> "removeflags" would be trickier to implement, but "string" test with
> :matches can be used to test if a flag was set, e.g.

> if string :matches "${flags}" "*\\Draft*" {
>     set "flags" "${1}${2}"
> }

Very cute. How to folks who precompile all this stuff feel about allowing
this sort of variable pattern?

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JBrEt2004123 for <[e-mail]>; Sat, 19 Apr 2003 04:53:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JBrEXf004122 for ietf-mta-filters-bks; Sat, 19 Apr 2003 04:53:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JBrBt2004117 for <[e-mail]>; Sat, 19 Apr 2003 04:53:12 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 19 Apr 2003 04:53:04 -0700 (PDT)
Date: Sat, 19 Apr 2003 04:44:04 -0700 (PDT)
From: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
In-reply-to: "Your message dated Fri, 18 Apr 2003 16:11:28 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[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>

> [Simon Josefsson]:
> >
> >   * The setdate command is useful, but wouldn't it be even more useful
> >     if there was a command that extracts comparable time/date
> >     variables from Date: headers?  To handled obs-zone's timezones.
> >     E.g., consider if I want to sort messages sent (Date:) between
> >     01 am and 04 am (in the senders timezone) into a folder
> >     INBOX.rants.

Cute. I hadn't thought of using this to get a likely time zone for the
originator.

> like
>   SETDATE :header "Date";
> vs. just
>   SETDATE;
> to access the current time.

> Ned, you had some ideas for more date related tests, what do you
> think?

I really don't want to try and force this into the setdate framework.
I'll see what I can do to write up the approach I have in mind for this.

> it seems to me that the only interesting data to be found in Date: is
> the local time and time zone of the sender (I feel SETDATE should
> normalise the timezone to offset format if it recognises it).  the
> date itself should be no more than a few minutes earlier than current
> time.  if it isn't, there is a misconfiguration or an outage going on.

> oh!  if you run the Sieve script in batch, long after the delivery was
> made, the current date is completely useless.  SETDATE should be
> changed to initialise the variables to the time of delivery, not
> current time.

Um, no, it may well be that it is the value in the Date: field that is
completely useless. It is all a question of what you're trying to achieve. If I
want a likely time zone for the originator I use Date:. If I want to guess at
when the message was actually sent use the oldest Received: field. If I want a
good estimate of when the message reached me use the newest Received: field.
(Actually, it may be necessary to  skip down a few to get the real scoop. This
is one of the reasons why this sort of test tends to be a bit context
sensitive.) If I want to know if the message has expired according to the
originator use one of the various expired fields. And if I want to alter
processing based on my current situation, use the current date.

There's a reason why there isn't a single grand unified time stamp on all
messages, and why we eventually want the ability to perform flexible
tests in this area.

> >   * I feel variable variable names (e.g., ${foo-${bar}-baz}) would be
> >     useful, but I can't come up with a good example why it is really
> >     required so I'm just mentioning it if someone else can come up
> >     with a illustrative example.

> it could be used as a poor man's associative arrays.  there'd be no
> function to list all keys in the "array", though.  if we do this, we
> need a way of escaping the dollar character other than the ${dollar}
> hack.  I don't think it is worth it.  if we want to support
> associative arrays, let's do it explicitly.

I completely agree.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JBhct2004008 for <[e-mail]>; Sat, 19 Apr 2003 04:43:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JBhcAO004007 for ietf-mta-filters-bks; Sat, 19 Apr 2003 04:43:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JBhZt2004002 for <[e-mail]>; Sat, 19 Apr 2003 04:43:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 19 Apr 2003 04:43:28 -0700 (PDT)
Date: Sat, 19 Apr 2003 04:29:53 -0700 (PDT)
From: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
In-reply-to: "Your message dated Fri, 18 Apr 2003 15:16:50 +0200" <[e-mail]>
To: Simon Josefsson <[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]>
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 setdate command is useful, but wouldn't it be even more useful
>   if there was a command that extracts comparable time/date variables
>   from Date: headers?  To handled obs-zone's timezones.  E.g.,
>   consider if I want to sort messages sent (Date:) between 01 am and
>   04 am (in the senders timezone) into a folder INBOX.rants.

A date test is also useful, but it is no replacement for the ability
to test the current date. Like it or not, the current date is a value
that may be reflected nowhere in the message, and may be the information
you want to use to decide on an action (e.g., I'm in a meeting and unable
to answer right away).

Additionally, if you are testing date information in the message header,
while it may be useful to test the Date: field, there are actually quite
a few other header fields that can contain date information that is even
more useful to test. For example, tests on Received: fields can be
very useful in determining if a message made it to a given point by 
a given time. Tests on the various expiry fields are another example.
All tests on the Date: field tell you is the time the originator's UA or
the originator's submission elected to attach to the message.

The problem with these sorts of tests is that they tend to be somewhat more
dependent on context  than we'd like (e.g., can you trust Received: fields or
not) and they introduce a substantial amount of additional complexity. For
exmaple, you really need a way to select a specific occurrance of a field  to
make Received: field tests worthwhile. As such, I beleve they should be cast 
as a separate operation and extension, not something we try and attach to
this draft.

>   This would also make it easier for script writers to do more robust
>   time-based filtering based on Date:, since the server could also
>   contain functions for handling non-conforming but easily guessable
>   times, if they want to support that.

Agreed. But this is not the place for it IMO. I'm trying to find the time
to write up a separate date test that accomplishes this.

>   Looking only at the posts to this list shows people are still using
>   obs-zone, and if people on this list uses such MUAs, chances are
>   rather high that many people in the real world also does.

Sure, this is an issue that has to be accomodated in such tests.

> * A security consideration is that people should be aware that RFC
>   2047 encoded-word, IDNA etc potentially encode information that the
>   script wants to trigger on.  This should have been in RFC 3028, but
>   as variables makes it even more likely that people will try to use
>   sieve scripts to filter for virus etc it might be useful to mention
>   it.  Compare the sieve-body draft:

And the converse is also true: I may want to test for a specific sort of
encoded word (e.g., anyone sending a message to me with a subject in the gb2312
charset is probably sending spam) and that canont be done reliably at present.

>    Filters relying on string matches in the raw body of an e-mail
>    message may be more general than intended.  Text matches are no
>    replacement for a virus or spam filtering system.

Of course they aren't. Have we really reached the point where we 
have to belabor obvious points like this in security considerations sections?

> * The examples in Section 3.1 and 4.1.1 should be terminated with
>   semi-colons to be complete Sieve commands.

> * I feel variable variable names (e.g., ${foo-${bar}-baz}) would be
>   useful, but I can't come up with a good example why it is really
>   required so I'm just mentioning it if someone else can come up with
>   a illustrative example.

They may be useful but they add substantial complexity to some implementations.
Absent a very compelling use case I don't think this is something we want
to support.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JAnxt2095189 for <[e-mail]>; Sat, 19 Apr 2003 03:49:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3JAnxvq095188 for ietf-mta-filters-bks; Sat, 19 Apr 2003 03:49:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3JAnvt2095170 for <[e-mail]>; Sat, 19 Apr 2003 03:49:58 -0700 (PDT) (envelope-from [e-mail])
Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3JAnqXK030759 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 19 Apr 2003 12:49:52 +0200
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
X-Payment: hashcash 1.2 0:030419:[e-mail]:91f5ecaf1b37edcf
X-Hashcash: 0:030419:[e-mail]:91f5ecaf1b37edcf
X-Payment: hashcash 1.2 0:030419:[e-mail]:a230f2450cf41260
X-Hashcash: 0:030419:[e-mail]:a230f2450cf41260
From: Simon Josefsson <[e-mail]>
Date: Sat, 19 Apr 2003 12:49:52 +0200
In-Reply-To: <[e-mail]> (Kjetil Torgrim Homme's message of "19 Apr 2003 04:14:00 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Kjetil Torgrim Homme <[e-mail]> writes:

> [Simon Josefsson]:
>>
>>   Kjetil Torgrim Homme <[e-mail]> writes:
>>   
>>   > the date itself should be no more than a few minutes earlier
>>   > than current time.  if it isn't, there is a misconfiguration or
>>   > an outage going on.
>>   
>>   The time in Date: are in general not the same as delivery time.
>>   Differences of several hours and days are typical.
>
> you should get a better email provider :-)
>
> huge mailing lists may introduce a delay of half an hour.  several
> hours is simply not an acceptable delay, and certainly not if it is
> typical.

Moderated lists are common, and if the moderator is out of town for a
week, the Date: will be a week late.

Offline clients are also common, and the typically put the current
time of hitting the "Send" button as the Date: value (as suggested by
RFC 2822).

>>   What is the difference between delivery time and current time?
>>   
>>   Consider the batch example again, what would SETDATE be
>>   initialized to in this case?  The delivery time is in general not
>>   available from a RFC 2822 message, so the implementation would
>>   probably simply pick current time.
>
> the latest Received header is a good bet.

Ah.  I think that should be mentioned, as one possible way to infer
the delivery time.

> all right, I'm not a native speaker, but how about
>
>    Sieve filtering should not be relied on as a security measure
>    against hostile e-mail messages.  Sieve is designed to do simple,
>    mostly static tests, and is not suitable for use as a spam or virus
>    checker, where the perpetrator has a motivation to vary the format
>    of the email in order to avoid filtering rules.

Very nice!

>>       For an example of a more general than expected test, consider
>>       looking for "xn--foo-bar" within a To: addr-spec in order to
>>       filter message addressed to a specific internationalized
>>       domain names into a separate folder, and an incoming message
>>       having an addr-spec of someone@(xn--foo-bar)example.org.
>
> if you use :address for matching, this won't be a problem.  if you use
> :header, there are more likely modes of failure.  e.g.,
>
>    if :header :matches [ "To", "Cc" ] "root@*.example.com"
>
> and a message with "To: [e-mail], [e-mail]"
>
> although this may be a common pitfall, I'm not sure warnings to "use
> the appropriate test" fits in here.

IMHO it is useful if all common pitfalls that lead to security
problems are discussed.

>>       For an example of a less general than expected test, consider
>>       looking for Subject: containing "MAKE MONEY FAST" to filter
>>       spam into a separate folder, and an incoming message having a
>>       Subject: of "=?CP-1252?q?MAKE_MONEY_FAST?=.
>
> I believe that message should be filtered just fine.

How?  Compare the following from RFC 3028.  Assuming the
implementation does not support CP-1252, I don't see how "MAKE MONEY
FAST" and "=?CP-1252?q?MAKE_MONEY_FAST?=" would match.  (The
assumption isn't a restriction, there will always be MUAs that
supports more charsets, or are less robust in their QP decoding, than
servers.)  Consider EBCDIC for a case where decoding the QP and only
using the ASCII characters would fail too.

,----
| 2.7.2.   Comparisons Across Character Sets
| 
|    All Sieve scripts are represented in UTF-8, but messages may involve
|    a number of character sets.  In order for comparisons to work across
|    character sets, implementations SHOULD implement the following
|    behavior:
| 
|       Implementations decode header charsets to UTF-8.  Two strings are
|       considered equal if their UTF-8 representations are identical.
|       Implementations should decode charsets represented in the forms
|       specified by [MIME] for both message headers and bodies.
|       Implementations must be capable of decoding US-ASCII, ISO-8859-1,
|       the ASCII subset of ISO-8859-* character sets, and UTF-8.
| 
|    If implementations fail to support the above behavior, they MUST
|    conform to the following:
| 
|       No two strings can be considered equal if one contains octets
|       greater than 127.
`----

>>   That reminds me, Sieve should support internationalized domain
>>   names by decoding them when they occur at the appropriate places
>>   (dot-atom's inside domain inside addr-spec, for instance).
>
> I think that is implied, really.  it does pose a problem for clients,
> they can't know whether the server supports it or not, so they need to
> duplicate their tests.  hmm, perhaps we do need an extension for it.

The IDNA specification says that if IDNs are in IDN-unaware domain
name slots, it MUST be encoded as ASCII.  Since the Sieve
specification does not discuss IDN, all domain name slots in Sieve
scripts are IDN-unaware.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J8A3t2082729 for <[e-mail]>; Sat, 19 Apr 2003 01:10:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3J8A3Gu082727 for ietf-mta-filters-bks; Sat, 19 Apr 2003 01:10:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J8A2t2082718 for <[e-mail]>; Sat, 19 Apr 2003 01:10:02 -0700 (PDT) (envelope-from [e-mail])
Received: from messagingdirect.com (1Cust251.tnt3.edmonton.ab.da.uu.net [64.10.184.251]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3J8DIV24729; Sat, 19 Apr 2003 02:13:19 -0600
Message-ID: <[e-mail]>
Date: Sat, 19 Apr 2003 01:26:56 -0600
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: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: Integer variables
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>

Kjetil Torgrim Homme wrote:

> >   Am I allowed to do the following using "variables" extension:
> >
> >   set "NumVar" 100M;
>
> no.
>
> >   If the answer is yes, two more questions:
> >   1). How do we expand integer variables inside strings?
> >   2). Can a variable get a string value after it was assigned an integer
> >   value?
>
> the problem is rather that the variable can only be expanded inside a
> string, so it would lose its integer property.

Which is fine, as long as this is documented.
I believe the current document doesn't specify what types of variables are
allowed.
You have to either explicitly allow or prohibit this.

> do you have a use for integer variables?

You already have the "length" function. I was thinking something along the
lines of comparing lengths/counting headers/scoring.
However this will probably require some actions for simple arithmetic (+/-).

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

Work Phone: [phone]
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J89qt2082676 for <[e-mail]>; Sat, 19 Apr 2003 01:09:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3J89quq082675 for ietf-mta-filters-bks; Sat, 19 Apr 2003 01:09:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J89lt2082641 for <[e-mail]>; Sat, 19 Apr 2003 01:09:51 -0700 (PDT) (envelope-from [e-mail])
Received: from messagingdirect.com (1Cust251.tnt3.edmonton.ab.da.uu.net [64.10.184.251]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3J8CoV24722; Sat, 19 Apr 2003 02:12:50 -0600
Message-ID: <[e-mail]>
Date: Sat, 19 Apr 2003 01:21:53 -0600
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: Jutta Degener <[e-mail]>, [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft   (draft-homme-sieve-variables-00.txt))
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Alexey Melnikov wrote:

> Jutta Degener wrote:
>
> > On Sun, Apr 13, 2003 at 05:53:40PM +0200, Kjetil Torgrim Homme wrote:
> > > [Alexey Melnikov]:
> > > >
> > > >   In order to move imapflags extension forward I need support for
> > > >   set/list variables.
> >
> > I think we might be able to do without this.  What if you allow
> > (and ignore) empty strings in a [...] list?
> >
> > That way, you could set
> >
> >         set "aflag" "aflag"
> >
> >         ["${aflag}", "${bflag}", "${cflag}"]
> >
> > and have that come out as
> >
> >         ["aflag" "" ""]
> >
> > if bflag and cflag are unset.
> >
> > There are still things that you can do with a list algebra
> > that you can't do with this approach -- infinitely many
> > flags based on the header and body contents of a message --
> > but I don't think we want to do those things badly enough
> > to warrant adding three new commands and a variable data type.
>
> Surely three new actions shouldn't scare you :-).
> But I understand the complexity of multiple data types.
>
> Ok, I can live with this.
> It seems the only thing required to be said is that empty strings are
> ignored in a list that specifies flags to be set.
> I should also mention that each list member defines a separate flag and
> spaces in flag names are not allowed (due to IMAP restriction).

After I rewrote my example in "imapflags" I've realised how ugly this will
look, because
1). The script author has to remember all flags that were set on the
message and specify them all.
2). setflags has to be replaced with multiple "set"s as we have to clear
all flags.

So, I am thinking now about using a single string parameter (instead of a
string list) that contains space delimited flags. Adding flags (old
"addflags") to the list would be simpler, e.g.

set "flags" "${flags} \\Seen"

"removeflags" would be trickier to implement, but "string" test with
:matches can be used to test if a flag was set, e.g.

if string :matches "${flags}" "*\\Draft*" {
    set "flags" "${1}${2}"
}

Multiple spaces between flags must be treated as one.

Comments?

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

Work Phone: [phone]
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J3w4t2052399 for <[e-mail]>; Fri, 18 Apr 2003 20:58:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3J3w4f2052398 for ietf-mta-filters-bks; Fri, 18 Apr 2003 20:58:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J3w0t2052393 for <[e-mail]>; Fri, 18 Apr 2003 20:58:04 -0700 (PDT) (envelope-from [e-mail])
Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3J3vsFd014413; Fri, 18 Apr 2003 20:57:54 -0700 (PDT)
Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3J3xYe01436; Fri, 18 Apr 2003 20:59:34 -0700 (PDT)
Message-Id: <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: Comments on draft-homme-sieve-variables-01.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Fri, 18 Apr 2003 20:57:58 -0700
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>

Kjetil Torgrim Homme <[e-mail]> writes:
>[Simon Josefsson]:
>>
>>   Kjetil Torgrim Homme <[e-mail]> writes:
>>   
>>   > the date itself should be no more than a few minutes earlier
>>   > than current time.  if it isn't, there is a misconfiguration or
>>   > an outage going on.
>>   
>>   The time in Date: are in general not the same as delivery time.
>>   Differences of several hours and days are typical.
>
>you should get a better email provider :-)

Not at all.  His provider has no control over the Date: header field as,
for the vast majority of messages, that header field was added by either
the sender's MUA or the MSA.  Desktop machines are often unsynchronized
and may have never been given the correct date, much less time.


Philip Guenther
<[e-mail]>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J2E1t2046275 for <[e-mail]>; Fri, 18 Apr 2003 19:14:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3J2E1sA046274 for ietf-mta-filters-bks; Fri, 18 Apr 2003 19:14:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J2Dxt2046269 for <[e-mail]>; Fri, 18 Apr 2003 19:14:00 -0700 (PDT) (envelope-from [e-mail])
Received: from sjau.ifi.uio.no ([129.240.65.207]) by pat.uio.no with esmtp (Exim 2.12 #7) id 196hrd-0004TW-00 for [e-mail]; Sat, 19 Apr 2003 04:14:01 +0200
Received: (from kjetilho@localhost) by sjau.ifi.uio.no ; Sat, 19 Apr 2003 04:14:01 +0200 (MEST)
To: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 19 Apr 2003 04:14:00 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 91
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>

[Simon Josefsson]:
>
>   Kjetil Torgrim Homme <[e-mail]> writes:
>   
>   > the date itself should be no more than a few minutes earlier
>   > than current time.  if it isn't, there is a misconfiguration or
>   > an outage going on.
>   
>   The time in Date: are in general not the same as delivery time.
>   Differences of several hours and days are typical.

you should get a better email provider :-)

huge mailing lists may introduce a delay of half an hour.  several
hours is simply not an acceptable delay, and certainly not if it is
typical.

>   > oh!  if you run the Sieve script in batch, long after the
>   > delivery was made, the current date is completely useless.
>   > SETDATE should be changed to initialise the variables to the
>   > time of delivery, not current time.
>   
>   What is the difference between delivery time and current time?
>   
>   Consider the batch example again, what would SETDATE be
>   initialized to in this case?  The delivery time is in general not
>   available from a RFC 2822 message, so the implementation would
>   probably simply pick current time.

the latest Received header is a good bet.  the final local delivery
may be held up, but should be very uncommon.  in the current mail
system of my University this can happen since the spool disk (my home
directory) is accessed through NFS.  these days, delivery to local
storage is becoming the typical mode of operation.

>   > I'd appreciate it if you could formulate a paragraph for me :-)
>   
>   Someone who knows english might be able to make the following
>   legible:
>   
>       Carelessly constructed tests may be both more general than
>       intended and also less general than intended.  This is a
>       generic problem with Sieve, but may become more important when
>       filtering decisions are made based on variables initialized
>       from data in message.  The moral of the story is that Sieve
>       tests are not a replacement for intelligent spam and virus
>       detection mechanisms, rather a solution that is intended to
>       work most of the time that can be circumvented by adaptive
>       senders.

all right, I'm not a native speaker, but how about

   Sieve filtering should not be relied on as a security measure
   against hostile e-mail messages.  Sieve is designed to do simple,
   mostly static tests, and is not suitable for use as a spam or virus
   checker, where the perpetrator has a motivation to vary the format
   of the email in order to avoid filtering rules.

>       For an example of a more general than expected test, consider
>       looking for "xn--foo-bar" within a To: addr-spec in order to
>       filter message addressed to a specific internationalized
>       domain names into a separate folder, and an incoming message
>       having an addr-spec of someone@(xn--foo-bar)example.org.

if you use :address for matching, this won't be a problem.  if you use
:header, there are more likely modes of failure.  e.g.,

   if :header :matches [ "To", "Cc" ] "root@*.example.com"

and a message with "To: [e-mail], [e-mail]"

although this may be a common pitfall, I'm not sure warnings to "use
the appropriate test" fits in here.

>       For an example of a less general than expected test, consider
>       looking for Subject: containing "MAKE MONEY FAST" to filter
>       spam into a separate folder, and an incoming message having a
>       Subject: of "=?CP-1252?q?MAKE_MONEY_FAST?=.

I believe that message should be filtered just fine.

>   That reminds me, Sieve should support internationalized domain
>   names by decoding them when they occur at the appropriate places
>   (dot-atom's inside domain inside addr-spec, for instance).

I think that is implied, really.  it does pose a problem for clients,
they can't know whether the server supports it or not, so they need to
duplicate their tests.  hmm, perhaps we do need an extension for it.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IGvnt2030337 for <[e-mail]>; Fri, 18 Apr 2003 09:57:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IGvnlZ030336 for ietf-mta-filters-bks; Fri, 18 Apr 2003 09:57:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IGvkt2030320 for <[e-mail]>; Fri, 18 Apr 2003 09:57:47 -0700 (PDT) (envelope-from [e-mail])
Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3IGvdXK017276 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 18 Apr 2003 18:57:40 +0200
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
X-Payment: hashcash 1.2 0:030418:[e-mail]:7a5f91d625e1a32a
X-Hashcash: 0:030418:[e-mail]:7a5f91d625e1a32a
X-Payment: hashcash 1.2 0:030418:[e-mail]:2877877a48c45b47
X-Hashcash: 0:030418:[e-mail]:2877877a48c45b47
From: Simon Josefsson <[e-mail]>
Date: Fri, 18 Apr 2003 18:57:39 +0200
In-Reply-To: <[e-mail]> (Kjetil Torgrim Homme's message of "18 Apr 2003 16:11:28 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux)
References: <[e-mail]> <[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>

Kjetil Torgrim Homme <[e-mail]> writes:

> [Simon Josefsson]:
>>
>>   * The setdate command is useful, but wouldn't it be even more useful
>>     if there was a command that extracts comparable time/date
>>     variables from Date: headers?  To handled obs-zone's timezones.
>>     E.g., consider if I want to sort messages sent (Date:) between
>>     01 am and 04 am (in the senders timezone) into a folder
>>     INBOX.rants.
>
> like
>   SETDATE :header "Date";

Yes.  The string must be allowed to be a variable too, so you can
extract times from Received:, etc.

> it seems to me that the only interesting data to be found in Date: is
> the local time and time zone of the sender (I feel SETDATE should
> normalise the timezone to offset format if it recognises it).  the
> date itself should be no more than a few minutes earlier than current
> time.  if it isn't, there is a misconfiguration or an outage going on.

The time in Date: are in general not the same as delivery time.
Differences of several hours and days are typical.

> oh!  if you run the Sieve script in batch, long after the delivery was
> made, the current date is completely useless.  SETDATE should be
> changed to initialise the variables to the time of delivery, not
> current time.

What is the difference between delivery time and current time?

Consider the batch example again, what would SETDATE be initialized to
in this case?  The delivery time is in general not available from a
RFC 2822 message, so the implementation would probably simply pick
current time.  A delivery agent invoked by the MTA would also pick
current time for this, since current time is delivery time in a
delivery agent.  I'm probably just dense, but I don't see a
practically useful distinction between delivery and current time.

>>   * A security consideration is that people should be aware that RFC
>>     2047 encoded-word, IDNA etc potentially encode information that the
>>     script wants to trigger on.  This should have been in RFC 3028, but
>>     as variables makes it even more likely that people will try to use
>>     sieve scripts to filter for virus etc it might be useful to mention
>>     it.  Compare the sieve-body draft:
>>   
>>      Filters relying on string matches in the raw body of an e-mail
>>      message may be more general than intended.  Text matches are no
>>      replacement for a virus or spam filtering system.
>
> I'd appreciate it if you could formulate a paragraph for me :-)

Someone who knows english might be able to make the following legible:

    Carelessly constructed tests may be both more general than
    intended and also less general than intended.  This is a generic
    problem with Sieve, but may become more important when filtering
    decisions are made based on variables initialized from data in
    message.  The moral of the story is that Sieve tests are not a
    replacement for intelligent spam and virus detection mechanisms,
    rather a solution that is intended to work most of the time that
    can be circumvented by adaptive senders.

    For an example of a more general than expected test, consider
    looking for "xn--foo-bar" within a To: addr-spec in order to
    filter message addressed to a specific internationalized domain
    names into a separate folder, and an incoming message having an
    addr-spec of someone@(xn--foo-bar)example.org.  For an example of
    a less general than expected test, consider looking for Subject:
    containing "MAKE MONEY FAST" to filter spam into a separate
    folder, and an incoming message having a Subject: of
    "=?CP-1252?q?MAKE_MONEY_FAST?=.

That reminds me, Sieve should support internationalized domain names
by decoding them when they occur at the appropriate places (dot-atom's
inside domain inside addr-spec, for instance).



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IGkrt2029283 for <[e-mail]>; Fri, 18 Apr 2003 09:46:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IGkrk4029282 for ietf-mta-filters-bks; Fri, 18 Apr 2003 09:46:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IGkqt2029277 for <[e-mail]>; Fri, 18 Apr 2003 09:46:52 -0700 (PDT) (envelope-from [e-mail])
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA13195; Fri, 18 Apr 2003 12:42:10 -0400 (EDT)
Date: Fri, 18 Apr 2003 12:45:40 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Mailing list last call for draft-daboo-sieve-spamtest-03.txt
Message-ID: <2147483647.1050669940@[63.163.82.24]>
In-Reply-To: <[e-mail]> <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/3.1.0b1 (Mac OS X)
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 Ned,

--On Friday, April 11, 2003 8:12 AM -0700 [e-mail] wrote:

| (1) The document lacks the required IPR boilerplate. The IESG has recently
|     started pushing back on this.
|
| (2) The change history section needs to be marked "to be removed prior
|     to publication as an RFC".
|
| (3) The abstract should refer to the "sieve mail filtering language"
| rather     than just "sieve", in order to better put the document in
| context.
|
| (4) The conventions section should be moved so it appears after the
|     introduction and overview.
|
| (5) The abstract should not be numbered.

OK, all the above changes have been made in my working copy.

--On Friday, April 11, 2003 6:22 PM -0700 [e-mail] wrote:

|
|> I do have a few of draft nits that need to be addressed with a revised
|> version:
|
|> ...
|
| Just noticed another problem with the draft as it stands. It contains an
| example:
|
|         if spamtest :value "ge" :comparator "i;ascii-numeric" "3"
|         {
|             fileinto "INBOX.spam-trap";
|         }
|         elsif spamtest :is "NIL"
|         {
|             fileinto "INBOX.unclassified";
|         }
|
| This turns out not to work. The problem is that the "i;ascii-numeric"
| comparator is defined to rank all strings that don't begin with a digit
| after any string that does. So if the spamtest value is NIL the first
| if succeeds and the second one is never reached.
|
| This is easily corrected by reversing the clauses, of course. The fact
| that NILL will rank higher probably should be noted somewhere as well.

Examples have been fixed. I added a note to the General Considerations 
section that describes this issue with the numeric comparator and explains 
how to handle it. The fixed examples also have notes that point out the new 
ordering of the tests, referring back to the General Considerations section.


-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IEEPt2024774 for <[e-mail]>; Fri, 18 Apr 2003 07:14:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IEEPCY024773 for ietf-mta-filters-bks; Fri, 18 Apr 2003 07:14:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IEENt2024766 for <[e-mail]>; Fri, 18 Apr 2003 07:14:23 -0700 (PDT) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [9.2.112.58]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h3IEEJQ100398 for <[e-mail]>; Fri, 18 Apr 2003 10:14:19 -0400
Received: from ballybran (ballybran.watson.ibm.com [9.2.42.31]) by sp1n294en1.watson.ibm.com (8.11.7/8.11.4) with SMTP id h3IEEJA27622 for <[e-mail]>; Fri, 18 Apr 2003 10:14:19 -0400
Message-ID: <004201c305b4$cd263030$[e-mail]>
From: "Wolfgang Segmuller" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]><005601c304e2$e26844b0$[e-mail]><[e-mail]><009201c3052a$ca73d520$[e-mail]> <[e-mail]>
Subject: Re: new version of the variables draft
Date: Fri, 18 Apr 2003 10:14:18 -0400
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>

From: "Kjetil Torgrim Homme" <[e-mail]>
>
> thanks.  how about:
>
> |  The default comparator is "i;ascii-casemap"
> +  The comparator only affects the result when certain modifiers are
> +  used.
>

This is good.

>
> >   I think that all elements of a syntax should be described where
> >   the element was introduced.  I was looking for section 4.1.2
> >   comparators, and didn't find it.
>
> well, the draft assumes familiarity with the base Sieve RFC.  I could
> stick in a "see [SIEVE] for more details on comparators", but it ought
> to be implied.  actually, even the default comparator could have been
> left out since it is specified in RFC 3028, but I thought I'd just
> make it clear since the text in the RFC is so centred on matching.
>

I wasn't refering to what comparators are in general.  I was refering to
what comparators do in this action.  The only place comparators were
mentioned was buried in the modifiers section of the action.  The addition
you proposed certainly covers my concerns.

Thanks,
Wolfgang



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IEBUt2024707 for <[e-mail]>; Fri, 18 Apr 2003 07:11:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IEBUwe024706 for ietf-mta-filters-bks; Fri, 18 Apr 2003 07:11:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IEBSt2024700 for <[e-mail]>; Fri, 18 Apr 2003 07:11:29 -0700 (PDT) (envelope-from [e-mail])
Received: from sjau.ifi.uio.no ([129.240.65.207]) by pat.uio.no with esmtp (Exim 2.12 #7) id 196WaO-0001d6-00 for [e-mail]; Fri, 18 Apr 2003 16:11:28 +0200
Received: (from kjetilho@localhost) by sjau.ifi.uio.no ; Fri, 18 Apr 2003 16:11:28 +0200 (MEST)
To: [e-mail]
Subject: Re: Comments on draft-homme-sieve-variables-01.txt
References: <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 18 Apr 2003 16:11:28 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 60
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>

[Simon Josefsson]:
>
>   * The setdate command is useful, but wouldn't it be even more useful
>     if there was a command that extracts comparable time/date
>     variables from Date: headers?  To handled obs-zone's timezones.
>     E.g., consider if I want to sort messages sent (Date:) between
>     01 am and 04 am (in the senders timezone) into a folder
>     INBOX.rants.

like
  SETDATE :header "Date";
vs. just
  SETDATE;
to access the current time.

Ned, you had some ideas for more date related tests, what do you
think?

it seems to me that the only interesting data to be found in Date: is
the local time and time zone of the sender (I feel SETDATE should
normalise the timezone to offset format if it recognises it).  the
date itself should be no more than a few minutes earlier than current
time.  if it isn't, there is a misconfiguration or an outage going on.

oh!  if you run the Sieve script in batch, long after the delivery was
made, the current date is completely useless.  SETDATE should be
changed to initialise the variables to the time of delivery, not
current time.

>   * A security consideration is that people should be aware that RFC
>     2047 encoded-word, IDNA etc potentially encode information that the
>     script wants to trigger on.  This should have been in RFC 3028, but
>     as variables makes it even more likely that people will try to use
>     sieve scripts to filter for virus etc it might be useful to mention
>     it.  Compare the sieve-body draft:
>   
>      Filters relying on string matches in the raw body of an e-mail
>      message may be more general than intended.  Text matches are no
>      replacement for a virus or spam filtering system.

I'd appreciate it if you could formulate a paragraph for me :-)

>   * The examples in Section 3.1 and 4.1.1 should be terminated with
>     semi-colons to be complete Sieve commands.

thanks.

>   * I feel variable variable names (e.g., ${foo-${bar}-baz}) would be
>     useful, but I can't come up with a good example why it is really
>     required so I'm just mentioning it if someone else can come up
>     with a illustrative example.

it could be used as a poor man's associative arrays.  there'd be no
function to list all keys in the "array", though.  if we do this, we
need a way of escaping the dollar character other than the ${dollar}
hack.  I don't think it is worth it.  if we want to support
associative arrays, let's do it explicitly.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IDGtt2019577 for <[e-mail]>; Fri, 18 Apr 2003 06:16:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IDGtTx019576 for ietf-mta-filters-bks; Fri, 18 Apr 2003 06:16:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IDGqt2019569 for <[e-mail]>; Fri, 18 Apr 2003 06:16:54 -0700 (PDT) (envelope-from [e-mail])
Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3IDGoXK013891 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Fri, 18 Apr 2003 15:16:50 +0200
To: [e-mail]
Subject: Comments on draft-homme-sieve-variables-01.txt
X-Payment: hashcash 1.2 0:030418:[e-mail]:cea7d45e126698ef
X-Hashcash: 0:030418:[e-mail]:cea7d45e126698ef
From: Simon Josefsson <[e-mail]>
Date: Fri, 18 Apr 2003 15:16:50 +0200
Message-ID: <[e-mail]>
User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, hits=-6.3 required=5.0 tests=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>

* The setdate command is useful, but wouldn't it be even more useful
  if there was a command that extracts comparable time/date variables
  from Date: headers?  To handled obs-zone's timezones.  E.g.,
  consider if I want to sort messages sent (Date:) between 01 am and
  04 am (in the senders timezone) into a folder INBOX.rants.

  This would also make it easier for script writers to do more robust
  time-based filtering based on Date:, since the server could also
  contain functions for handling non-conforming but easily guessable
  times, if they want to support that.

  Looking only at the posts to this list shows people are still using
  obs-zone, and if people on this list uses such MUAs, chances are
  rather high that many people in the real world also does.

* A security consideration is that people should be aware that RFC
  2047 encoded-word, IDNA etc potentially encode information that the
  script wants to trigger on.  This should have been in RFC 3028, but
  as variables makes it even more likely that people will try to use
  sieve scripts to filter for virus etc it might be useful to mention
  it.  Compare the sieve-body draft:

   Filters relying on string matches in the raw body of an e-mail
   message may be more general than intended.  Text matches are no
   replacement for a virus or spam filtering system.

* The examples in Section 3.1 and 4.1.1 should be terminated with
  semi-colons to be complete Sieve commands.

* I feel variable variable names (e.g., ${foo-${bar}-baz}) would be
  useful, but I can't come up with a good example why it is really
  required so I'm just mentioning it if someone else can come up with
  a illustrative example.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HMxQt2065751 for <[e-mail]>; Thu, 17 Apr 2003 15:59:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HMxQGd065749 for ietf-mta-filters-bks; Thu, 17 Apr 2003 15:59:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HMxOt2065743 for <[e-mail]>; Thu, 17 Apr 2003 15:59:25 -0700 (PDT) (envelope-from [e-mail])
Received: from atta.ifi.uio.no ([129.240.65.208]) by pat.uio.no with esmtp (Exim 2.12 #7) id 196ILl-0000j6-00 for [e-mail]; Fri, 18 Apr 2003 00:59:25 +0200
Received: (from kjetilho@localhost) by atta.ifi.uio.no ; Fri, 18 Apr 2003 00:59:25 +0200 (MEST)
To: <[e-mail]>
Subject: Re: new version of the variables draft
References: <[e-mail]> <005601c304e2$e26844b0$[e-mail]> <[e-mail]> <009201c3052a$ca73d520$[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 18 Apr 2003 00:59:25 +0200
In-Reply-To: <009201c3052a$ca73d520$[e-mail]>
Message-ID: <[e-mail]>
Lines: 39
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>

[Wolfgang Segmuller]:
>
>   I think changing the paragraph that identifies the default comparator to:
>   
>       Comparators are used by the some modifiers to identify the
>       locale for case mapping.  See section "4.1.1.2. Case
>       modifiers" for how the comparator is used.  The default
>       comparator is "i;ascii-casemap".
>   
>   will make it clear what comparators are used for, instead of
>   having it buried in the modifiers section.  If you don't like the
>   forward reference, you can always move some of the discussion in
>   4.1.1.2 to this paragraph.

thanks.  how about:

|  The default comparator is "i;ascii-casemap"
+  The comparator only affects the result when certain modifiers are
+  used.

future extension might add new modifiers which aren't case modifiers.
for instance if a list variable type is introduced, a useful modifier
will be ":sort".

I think it is good to make clear that a SET without any modifiers can
ignore the comparator, anyway.

>   I think that all elements of a syntax should be described where
>   the element was introduced.  I was looking for section 4.1.2
>   comparators, and didn't find it.

well, the draft assumes familiarity with the base Sieve RFC.  I could
stick in a "see [SIEVE] for more details on comparators", but it ought
to be implied.  actually, even the default comparator could have been
left out since it is specified in RFC 3028, but I thought I'd just
make it clear since the text in the RFC is so centred on matching.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLkTt2063683 for <[e-mail]>; Thu, 17 Apr 2003 14:46:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HLkTc8063682 for ietf-mta-filters-bks; Thu, 17 Apr 2003 14:46:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLkRt2063677 for <[e-mail]>; Thu, 17 Apr 2003 14:46:27 -0700 (PDT) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h3HLkOQ44048 for <[e-mail]>; Thu, 17 Apr 2003 17:46:24 -0400
Received: from ballybran (ballybran.watson.ibm.com [9.2.42.31]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.4) with SMTP id h3HLkN837190 for <[e-mail]>; Thu, 17 Apr 2003 17:46:23 -0400
Message-ID: <009201c3052a$ca73d520$[e-mail]>
From: "Wolfgang Segmuller" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]><005601c304e2$e26844b0$[e-mail]> <[e-mail]>
Subject: Re: new version of the variables draft
Date: Thu, 17 Apr 2003 17:46:23 -0400
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>

----- Original Message -----
From: "Kjetil Torgrim Homme" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, April 17, 2003 1:34 PM
Subject: Re: new version of the variables draft


>
> [Wolfgang Segmuller]:
> >
> >   Did I miss something, in the Set action there is a comparator in
> >   the syntax, and a mention of a default value for it.  What do you
> >   need a comparator for in the Set action?
>
> | 4.1.1.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.  The comparator specified SHOULD be consulted to
> |    establish which locale to use.
>
> this isn't very useful until someone registers new comparators (which
> must be REQUIREd in the script before use), but it leaves the door
> open.
>
> (wording changes to make things more clear are always welcome.)
>

Thanks, I missed that in the text.

I think changing the paragraph that identifies the default comparator to:

    Comparators are used by the some modifiers to identify the locale for
    case mapping.  See section "4.1.1.2. Case modifiers" for how the
    comparator is used.  The default comparator is "i;ascii-casemap".

will make it clear what comparators are used for, instead of having it
buried in the modifiers section.  If you don't like the forward reference,
you can always move some of the discussion in 4.1.1.2 to this paragraph.

I think that all elements of a syntax should be described where the element
was introduced.  I was looking for section 4.1.2 comparators, and didn't
find it.

Wolfgang



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLH6t2062468 for <[e-mail]>; Thu, 17 Apr 2003 14:17:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HLH6D5062467 for ietf-mta-filters-bks; Thu, 17 Apr 2003 14:17:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLH4t2062462 for <[e-mail]>; Thu, 17 Apr 2003 14:17:05 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 17 Apr 2003 14:17:02 -0700 (PDT)
Date: Thu, 17 Apr 2003 14:16:39 -0700 (PDT)
From: [e-mail]
Subject: Re: new version of the variables draft
In-reply-to: "Your message dated Thu, 17 Apr 2003 09:11:40 -0400" <005601c304e2$e26844b0$[e-mail]>
To: Wolfgang Segmuller <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <005601c304e2$e26844b0$[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>

> Did I miss something, in the Set action there is a comparator in the syntax,
> and a mention of a default value for it.  What do you need a comparator for
> in the Set action?

It specifies how :upper, :lower and so on work.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HKcct2060422 for <[e-mail]>; Thu, 17 Apr 2003 13:38:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HKcbR7060421 for ietf-mta-filters-bks; Thu, 17 Apr 2003 13:38:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HKcXt2060413 for <[e-mail]>; Thu, 17 Apr 2003 13:38:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 16 Apr 2003 16:36:25 -0700 (PDT)
Date: Wed, 16 Apr 2003 16:36:03 -0700 (PDT)
From: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft (draft-homme-sieve-variables-00.txt))
In-reply-to: "Your message dated Thu, 17 Apr 2003 00:44:57 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[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]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> [Ned Freed]:
> >
> >   Folks, I think we have reached a point where a revised I-D for the
> >   variables document is in order. I'm starting to lose track of
> >   where we are on some of these changes...

> I fully agree, but I'd like some feedback on a very important issue
> first, the syntax vs. semantics issue.

> semantics seems the easier bolt-on, but syntax is the smoothest change
> IMO.  in particular, the backslash handling feels more natural.
> consider "\${foo}".  if we change syntax, the backslash will quote the
> dollar so that it isn't a variable reference.  if we change semantics
> of strings, the backslash has no effect.

I'm personally in the semantics camp. Smooth changes are good.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHZCt2054382 for <[e-mail]>; Thu, 17 Apr 2003 10:35:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HHZCtV054381 for ietf-mta-filters-bks; Thu, 17 Apr 2003 10:35:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHZ8t2054374 for <[e-mail]>; Thu, 17 Apr 2003 10:35:11 -0700 (PDT) (envelope-from [e-mail])
Received: from atta.ifi.uio.no ([129.240.65.208]) by pat.uio.no with esmtp (Exim 2.12 #7) id 196DHx-0003FC-00 for [e-mail]; Thu, 17 Apr 2003 19:35:09 +0200
Received: (from kjetilho@localhost) by atta.ifi.uio.no ; Thu, 17 Apr 2003 19:34:59 +0200 (MEST)
To: <[e-mail]>
Subject: Re: new version of the variables draft
References: <[e-mail]> <005601c304e2$e26844b0$[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 17 Apr 2003 19:34:59 +0200
In-Reply-To: <005601c304e2$e26844b0$[e-mail]>
Message-ID: <[e-mail]>
Lines: 22
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>

[Wolfgang Segmuller]:
>
>   Did I miss something, in the Set action there is a comparator in
>   the syntax, and a mention of a default value for it.  What do you
>   need a comparator for in the Set action?

| 4.1.1.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.  The comparator specified SHOULD be consulted to
|    establish which locale to use.

this isn't very useful until someone registers new comparators (which
must be REQUIREd in the script before use), but it leaves the door
open.

(wording changes to make things more clear are always welcome.)

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HFsEt2050337 for <[e-mail]>; Thu, 17 Apr 2003 08:54:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HFsEeu050336 for ietf-mta-filters-bks; Thu, 17 Apr 2003 08:54:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HFs8t2050312 for <[e-mail]>; Thu, 17 Apr 2003 08:54:13 -0700 (PDT) (envelope-from [e-mail])
Received: from messagingdirect.com (dhcp198-169.esys.ca [198.161.92.169]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3HFvcV12942; Thu, 17 Apr 2003 09:57:38 -0600
Message-ID: <[e-mail]>
Date: Thu, 17 Apr 2003 09:57:34 -0600
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: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft  (draft-homme-sieve-variables-00.txt))
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Jutta Degener wrote:

> On Thu, Apr 17, 2003 at 12:44:57AM +0200, Kjetil Torgrim Homme wrote:
> > [Ned Freed]:
> > >
> > >   Folks, I think we have reached a point where a revised I-D for the
> > >   variables document is in order. I'm starting to lose track of
> > >   where we are on some of these changes...
> >
> > I fully agree, but I'd like some feedback on a very important issue
> > first, the syntax vs. semantics issue.
> >
> > semantics seems the easier bolt-on, but syntax is the smoothest change
> > IMO.  in particular, the backslash handling feels more natural.
> > consider "\${foo}".  if we change syntax, the backslash will quote the
> > dollar so that it isn't a variable reference.  if we change semantics
> > of strings, the backslash has no effect.
>
> The gut reaction of a shell programmer will probably differ,
> but I'd rather not change the syntax.  To me, string scanning
> and variable extension are different stages and must not
> affect each other.

I fully agree with this.

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

Work Phone: [phone]
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HDBmt2043653 for <[e-mail]>; Thu, 17 Apr 2003 06:11:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HDBlJc043652 for ietf-mta-filters-bks; Thu, 17 Apr 2003 06:11:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HDBjt2043647 for <[e-mail]>; Thu, 17 Apr 2003 06:11:45 -0700 (PDT) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h3HDBeQ11502 for <[e-mail]>; Thu, 17 Apr 2003 09:11:40 -0400
Received: from ballybran (ballybran.watson.ibm.com [9.2.42.31]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.4) with SMTP id h3HDBe827096 for <[e-mail]>; Thu, 17 Apr 2003 09:11:40 -0400
Message-ID: <005601c304e2$e26844b0$[e-mail]>
From: "Wolfgang Segmuller" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: new version of the variables draft
Date: Thu, 17 Apr 2003 09:11:40 -0400
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>

Did I miss something, in the Set action there is a comparator in the syntax,
and a mention of a default value for it.  What do you need a comparator for
in the Set action?

Wolfgang



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H5QIt2091777 for <[e-mail]>; Wed, 16 Apr 2003 22:26:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H5QI7Y091776 for ietf-mta-filters-bks; Wed, 16 Apr 2003 22:26:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H5QFt2091771 for <[e-mail]>; Wed, 16 Apr 2003 22:26:16 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 1961uc-0005OP-00 for [e-mail]; Thu, 17 Apr 2003 07:26:18 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Thu, 17 Apr 2003 07:26:18 +0200
To: [e-mail]
Subject: new version of the variables draft
From: Kjetil Torgrim Homme <[e-mail]>
Date: 17 Apr 2003 07:26:18 +0200
Message-ID: <[e-mail]>
Lines: 8
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>

--=-=-=

I just submitted a new version of the draft to IETF.  I include it
here for convenience.


--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment;
  filename=draft-homme-sieve-variables-01.txt
Content-Transfer-Encoding: quoted-printable
Content-Description: variables-01







Network Working Group                                        K. T. Homme
Document: draft-homme-sieve-variables-01.txt          University of Oslo
Expires October 17, 2003                                     17 Apr 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 mate=AD
   rial 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 con=AD
   figuration details across rules.  This extension adds an action to
   store data in variables, an action to retrieve the current time,
   changes the interpolation of 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           17 Apr 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 informa=AD
   tion 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

0.2.1.  Changes since -00

a)   allow generic time zone names, without requiring implementations to
     support it.  added a "${timezone}" variable so that the user can
     check if the implementation does support the time zone name he
     wants.  the default time zone was changed to localtime again.

b)   allow back references from :matches as well as :regex.

c)   added a section on implementation limits.

d)   clarified global scope so that it spans include.

e)   clarified that this draft only affects scripts which require "vari=AD
     ables".

f)   changed modifiers into being tagged arguments for SET, added prece=AD
     dence table.

g)   added optional COMPARATOR to SET to solve the internationalisation
     problem with :lower etc.

h)   the name of the variable being SET is passed in a string to conform
     with overall Sieve grammar.  this string is explicitly disallowed
     from containing variable references.


0.3.  Open Issues

a)   should we include more predefined variables to access the time?
     (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 creates new
     folders on demand.  [SIEVE] doesn't prohibit this, and currently
     some implementations will create new folders automatically, others
     won't.

c)   the NOTIFY draft has variables, too.  it would be nice if the syn=AD
     tax for the two extensions agreed.  a changed NOTIFY can be used on
     its own without the variables extension, the user simply won't be



Homme                                                           [Page 2]





Internet Draft        Sieve -- Variables Extension           17 Apr 2003


     able to configure the notification message to include different
     snippets from the message.


1.  Introduction

   This is an extension to the Sieve language defined by [SIEVE].  It
   adds support for storing and referencing data in string variables.
   The mechanisms detailed in this document will only apply to Sieve
   scripts which include a require clause for the "variables" extension.
   The require clauses themselves are not affected by this extension.

   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 inclu=AD
   sion of the value of variables.  The syntax follows [ABNF].

      variable-ref        =3D  "${" variable-name "}"
      variable-name       =3D  num-variable / identifier
      num-variable        =3D  1*DIGIT

   When the string is evaluated, substrings matching variable-ref shall
   be replaced by the value of variable-name.  Only one pass through the
   string shall be done.  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:
      "&%${}!"     =3D> unchanged, as the empty string is an illegal
                      identifier
      "${doh!}"    =3D> unchanged, as "!" is illegal in identifiers

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

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

   The expanded string MUST use the variable values which are current
   when control reaches the statement the string is part of.



Homme                                                           [Page 3]





Internet Draft        Sieve -- Variables Extension           17 Apr 2003


3.1.  Quoting

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

   Examples:
      "${fo\o}"  =3D> ${foo}  =3D> the expansion of variable foo.
      "${fo\\o}" =3D> ${fo\o} =3D> illegal identifier =3D> left verbatim.
      "\${foo}"  =3D> ${foo}  =3D> the expansion of variable foo.
      "\\${foo}" =3D> \${foo} =3D> 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 circum=AD
   vent expansion to the empty string.

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


3.2.  Numeric variables

   The decimal value of the numeric variable name will index the list of
   matching strings from the most recently evaluated match of type
   ":matches" or ":regex".  The list is empty if the match was unsuc=AD
   cessful.

   For ":matches", the list will contain one string for each wildcard in
   the match pattern.  Each string holds what the corresponding wildcard
   expands to, possibly the empty string.  The wildcards expand greed=AD
   ily.

   For ":regex", the list will contain the strings corresponding to the
   group operators.  The groups are ordered by the position of the open=AD
   ing parenthesis, from left to right.

   The first string in the list has index 1.  If the index is out of
   range, the empty string will be substituted.  Index 0 returns the
   number of strings in the list.

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

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

      # this is equivalent to the above:
      if header :matches "List-ID" "<*@" {
          fileinto "lists.${1}"; stop;
      }

      if header :matches [ "To", "Cc" ] "coyote@**.com" {



Homme                                                           [Page 4]





Internet Draft        Sieve -- Variables Extension           17 Apr 2003


          # ${0} is always "2", and ${2} is always the empty string.
          fileinto "business.${1}"; stop;
      } else {
          # ${0} is always "0"
          stop;
      }


4.  Action Commands

   This extension defines two actions, "set" and "setdate", both of
   which MUST be supported by an implementation of this extension.


4.1.  Action set

   Syntax:   set [MODIFIER] [COMPARATOR] <name: string> <value: string>

   The "set" action stores the specified value in the variable called
   name.  name MUST be a constant string without variable references.
   The contents of name MUST conform to the syntax of identifier.  An
   illegal name MUST cause a syntax error.

   The default comparator is "i;ascii-casemap".

   All variables have global scope: they are visible until processing
   stops.  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 meep.
      .
      ;

   "set" does not affect the implicit keep.


4.1.1.  Modifiers

   Modifiers are applied on value before it is stored in the variable.
   Modifier names are case insensitive.  Unknown modifiers MUST yield a
   syntax error.  More than one modifier can be specified, in which case
   they are applied according to this precedence list, highest value
   first:









Homme                                                           [Page 5]





Internet Draft        Sieve -- Variables Extension           17 Apr 2003


                        Precedence     Modifier
                       -----------------------------
                            1          :length
                       -----------------------------
                            2          :lowerfirst
                                       :upperfirst
                       -----------------------------
                            3          :lower
                                       :upper


   If two or more modifiers of the same precedence are used, they can be
   applied in any order.

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


4.1.1.1.  Modifier ":length"

   The value is the decimal number of letters in the expansion, con=AD
   verted to a string.


4.1.1.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.  The comparator
   specified SHOULD be consulted to establish which locale to use.


4.1.1.2.1.  Modifier ":upper"

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


4.1.1.2.2.  Modifier ":lower"

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


4.1.1.2.3.  Modifier ":upperfirst"

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






Homme                                                           [Page 6]





Internet Draft        Sieve -- Variables Extension           17 Apr 2003


4.1.1.2.4.  Modifier ":lowerfirst"

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


4.2.  Action setdate

   Syntax: setdate [ <time-zone: string> ]

   The value of time-zone SHOULD be a well-known name, or an offset rel=AD
   ative to UTC.  All implementations MUST support the time-offset syn=AD
   tax

           time-offset  =3D  ( "+" / "-" ) 4DIGIT

   time-offset should be interpreted the same way as "zone" in [IMAIL].


     Note: There is currently no registry for time zones.  If IETF
     establishes one, its names SHOULD be used.  In the absence of
     such a registry, [TZ] is the most widespread collection of
     time zone definitions and its use as a reference is RECOM=AD
     MENDED.

   If the time-zone is left out or not recognised, the local time zone
   SHOULD be used.

   The action setdate initialises a few variables:

      ${year}     =3D> the current year, "0000" .. "9999"
      ${month}    =3D> the current month, "01" .. "12"
      ${day}      =3D> the current day, "01" .. "31"
      ${hour}     =3D> the current hour, "00" .. "23"
      ${minute}   =3D> the current hour, "00" .. "59"
      ${second}   =3D> the current second, "00" .. "59"
      ${timezone} =3D> the time zone in use.  If the user specified a
                     time zone which was recognised, ${timezone} will
                     contain the name given.  Otherwise, the value
                     MUST be the server's default time zone in offset
                     format.

   These variables SHOULD reference the time when execution of the Sieve
   script reaches the statement.  All calls to setdate MUST refer to the
   same point in time.

   "setdate" does not affect the implicit keep.


5.  Test string

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



Homme                                                           [Page 7]





Internet Draft        Sieve -- Variables Extension           17 Apr 2003


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


6.  Implementation Limits

   An implementation of this draft MUST support at least 128 distinct
   variables.  The supported length of variable names MUST be at least
   32 characters.  Each variable MUST be able to hold at least 4000
   characters.  Attempts to set the variable to a value larger than what
   the implementation supports MUST be treated as an error.

   Numeric variables ${1} through ${9} MUST be supported.  Referencing
   higher indices than is supported is a syntax error which MUST be dis=AD
   covered at compile-time.  If the string matching a wildcard or a
   regex group operator exceeds the maximum variable size, the implemen=AD
   tation SHOULD truncate it and MUST NOT treat it as an error.


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, Ned Freed, Lawrence Greenfield, Peder Stray
   and Nigel Swinson for valuable feedback.


9.  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 Specifica=AD
                tions: ABNF", Internet Mail Consortium, RFC 2234, Novem=AD
                ber 1997





Homme                                                           [Page 8]





Internet Draft        Sieve -- Variables Extension           17 Apr 2003


     [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", Mira=AD
                point, RFC 3028, January 2001.

     [TZ]       Olson, A.D., et al, Time zone code and data,
                ftp://elsie.nci.nih.gov/pub/, updated periodically.



Appendix B.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   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 doc=AD
   ument 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=AD
   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 MER=AD
   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
















Homme                                                           [Page 9]



--=-=-=


-- 
Kjetil T.

--=-=-=--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GNkft2081623 for <[e-mail]>; Wed, 16 Apr 2003 16:46:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GNkfcv081622 for ietf-mta-filters-bks; Wed, 16 Apr 2003 16:46:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GNkdt2081614 for <[e-mail]>; Wed, 16 Apr 2003 16:46:40 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 195wbx-0003is-00 for [e-mail]; Thu, 17 Apr 2003 01:46:41 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Thu, 17 Apr 2003 01:46:41 +0200
To: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft (draft-homme-sieve-variables-00.txt))
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 17 Apr 2003 01:46:40 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 25
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>

[Jutta Degener]:
>
>   On Thu, Apr 17, 2003 at 12:44:57AM +0200, Kjetil Torgrim Homme wrote:
>   > semantics seems the easier bolt-on, but syntax is the smoothest
>   > change IMO.  in particular, the backslash handling feels more
>   > natural.  consider "\${foo}".  if we change syntax, the
>   > backslash will quote the dollar so that it isn't a variable
>   > reference.  if we change semantics of strings, the backslash has
>   > no effect.
>   
>   The gut reaction of a shell programmer will probably differ, but
>   I'd rather not change the syntax.  To me, string scanning and
>   variable extension are different stages and must not affect each
>   other.

duly noted.

>   If you do change the syntax, where do you stop?  Why should \ be
>   special for variable syntax, but not for :regex and :matches
>   pattern syntax?  I don't want to have to answer that.

interesting point!  I'm not sure I want to explain that, either :-)

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GNQat2080957 for <[e-mail]>; Wed, 16 Apr 2003 16:26:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GNQa5v080956 for ietf-mta-filters-bks; Wed, 16 Apr 2003 16:26:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GNQVt2080951 for <[e-mail]>; Wed, 16 Apr 2003 16:26:35 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3GNQTFe025225 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 16 Apr 2003 16:26:29 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3GNQSqu012812; Wed, 16 Apr 2003 16:26:29 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 1051417999; Wed, 16 Apr 2003 16:25:55 -0700 (PDT)
Date: Wed, 16 Apr 2003 16:25:55 -0700
From: Jutta Degener <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft (draft-homme-sieve-variables-00.txt))
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3GNQSqu012812
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 Thu, Apr 17, 2003 at 12:44:57AM +0200, Kjetil Torgrim Homme wrote:
> [Ned Freed]:
> >
> >   Folks, I think we have reached a point where a revised I-D for the
> >   variables document is in order. I'm starting to lose track of
> >   where we are on some of these changes...
> 
> I fully agree, but I'd like some feedback on a very important issue
> first, the syntax vs. semantics issue.
> 
> semantics seems the easier bolt-on, but syntax is the smoothest change
> IMO.  in particular, the backslash handling feels more natural.
> consider "\${foo}".  if we change syntax, the backslash will quote the
> dollar so that it isn't a variable reference.  if we change semantics
> of strings, the backslash has no effect.

The gut reaction of a shell programmer will probably differ,
but I'd rather not change the syntax.  To me, string scanning
and variable extension are different stages and must not
affect each other.

If you do change the syntax, where do you stop?  Why should
\ be special for variable syntax, but not for :regex and
:matches pattern syntax?  I don't want to have to answer that.

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GMiwt2079720 for <[e-mail]>; Wed, 16 Apr 2003 15:44:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GMiwjl079719 for ietf-mta-filters-bks; Wed, 16 Apr 2003 15:44:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GMiut2079713 for <[e-mail]>; Wed, 16 Apr 2003 15:44:56 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 195veD-0005H2-00 for [e-mail]; Thu, 17 Apr 2003 00:44:57 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Thu, 17 Apr 2003 00:44:57 +0200
To: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft (draft-homme-sieve-variables-00.txt))
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 17 Apr 2003 00:44:57 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 17
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>

[Ned Freed]:
>
>   Folks, I think we have reached a point where a revised I-D for the
>   variables document is in order. I'm starting to lose track of
>   where we are on some of these changes...

I fully agree, but I'd like some feedback on a very important issue
first, the syntax vs. semantics issue.

semantics seems the easier bolt-on, but syntax is the smoothest change
IMO.  in particular, the backslash handling feels more natural.
consider "\${foo}".  if we change syntax, the backslash will quote the
dollar so that it isn't a variable reference.  if we change semantics
of strings, the backslash has no effect.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GKWGt2074948 for <[e-mail]>; Wed, 16 Apr 2003 13:32:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GKWGfn074947 for ietf-mta-filters-bks; Wed, 16 Apr 2003 13:32:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GKW9t2074939 for <[e-mail]>; Wed, 16 Apr 2003 13:32:10 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 16 Apr 2003 13:31:56 -0700 (PDT)
Date: Wed, 16 Apr 2003 13:30:51 -0700 (PDT)
From: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft (draft-homme-sieve-variables-00.txt))
In-reply-to: "Your message dated Mon, 14 Apr 2003 20:38:17 -0600" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Jutta Degener <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=koi8-r
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Folks, I think we have reached a point where a revised I-D for the
variables document is in order. I'm starting to lose track of where
we are on some of these changes...

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FMgrt2097353 for <[e-mail]>; Tue, 15 Apr 2003 15:42:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FMgrGC097352 for ietf-mta-filters-bks; Tue, 15 Apr 2003 15:42:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FMght2097346 for <[e-mail]>; Tue, 15 Apr 2003 15:42:51 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3FMgZFe005764 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 15 Apr 2003 15:42:36 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3FMgYqu010584; Tue, 15 Apr 2003 15:42:35 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 82E4617999; Tue, 15 Apr 2003 15:42:03 -0700 (PDT)
Date: Tue, 15 Apr 2003 15:42:03 -0700
From: Jutta Degener <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Sieve Mailing List <[e-mail]>
Subject: Re: variables: dynamic match patterns
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3FMgYqu010584
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 Mon, Apr 14, 2003 at 10:19:17PM +0200, Kjetil Torgrim Homme wrote:
> 
> [Jutta Degener]:
> >
> >   Hm.  That's a reasonable offer, Kjetil, but I'd rather eat the
> >   complexity as an implementor than to place it on the users and
> >   client writers by making this be an implementation-specific
> >   difference.
> 
> well, that is one side of it.  the other side is that of the server
> administrators.  if you must support multipass searches in body, this
> may be a performance hit for servers.  the administrator has few
> options: pray that people won't use it too often, buy more hardware
> (RAM!), or turn off the body extension altogether.

I strongly feel that performance should be addressed on a global
level, not on the level of individual features.

An ISP might want to restrict, and a vendor of tools might offer
a way to restrict, the amount of time and memory used by a sieve
script's execution (or by an IMAP search, for that matter).
That's a good and safe thing to do.

Disabling individual features is a stopgap measure in the absence
of better tools, but while desperate ISPs will do it, we shouldn't
do it at the specification level.

(Neither should we specify mechanisms that are needlessly wasteful,
but I don't think these are.)

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FHwmt2083767 for <[e-mail]>; Tue, 15 Apr 2003 10:58:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FHwm6D083766 for ietf-mta-filters-bks; Tue, 15 Apr 2003 10:58:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FHwht2083750 for <[e-mail]>; Tue, 15 Apr 2003 10:58:47 -0700 (PDT) (envelope-from [e-mail])
Received: from messagingdirect.com (dhcp198-169.esys.ca [198.161.92.169]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3FI2FV28712; Tue, 15 Apr 2003 12:02:15 -0600
Message-ID: <[e-mail]>
Date: Tue, 15 Apr 2003 12:02:18 -0600
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: Cyrus Daboo <[e-mail]>
CC: Sieve Mailing List <[e-mail]>
Subject: Re: Draft for script 'include' capability
References: <2147483647.1050063758@[10.0.1.6]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <2147483647.1050413811@[63.163.82.24]>
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>

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Monday, April 14, 2003 11:30 PM -0600 Alexey Melnikov
> <[e-mail]> wrote:
>
> |> From my own experience: I came across a C compiler that was treating
> |> missing
> | include files as empty. I was very surprised as a user. So, I am in favor
> | of being explicit and fail interpretation/compilation when a file doesn't
> | exist.
>
> Alternatively, we could allow a ':nofail' parameter to include so that a
> user could explicitly turn on silent failures for missing include files.
> Thus if a user really wanted to do something along the lines of what Rob
> proposed, they could do that, e.g.:
>
> include :nofail "my_optional_vacation_script";

I don't think you should be that flexible. Just pick one way.

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

Work Phone: [phone]
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FHc8t2081637 for <[e-mail]>; Tue, 15 Apr 2003 10:38:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FHc8Vo081636 for ietf-mta-filters-bks; Tue, 15 Apr 2003 10:38:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FHc6t2081615 for <[e-mail]>; Tue, 15 Apr 2003 10:38:07 -0700 (PDT) (envelope-from [e-mail])
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.9/8.12.9) with ESMTP id h3FHbvTN008551; Tue, 15 Apr 2003 13:37:57 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 15 Apr 2003 13:41:03 -0400
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: Alexey Melnikov <[e-mail]>
CC: Kjetil Torgrim Homme <[e-mail]>, Sieve Mailing List <[e-mail]>
Subject: Re: Draft for script 'include' capability
References: <2147483647.1050063758@[10.0.1.6]> <[e-mail]> <[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>

Alexey Melnikov wrote:
> 
> > >   > |     3   How should non-exist include scripts be handled?
> > >   >
> > >   > error at compile-time or run-time depending on the implementation.
> > >
> > >   I'd argue that these should be interpreted to be empty scripts,
> > >   since I suspect runtime errors could be more confusing to the end
> > >   user.  (Since generally users don't see explicit error notices
> > >   from sieve runs).
> > >
> > >   The advantage of interpreting it as an empty script is you can
> > >   have your main script include stuff like "my-vacation-script"
> > >   which then can just be deleted when you come back, as opposed to
> > >   having to modify your main script.
> >
> > heh.  I'd prefer to keep my vacation-script around, and just disable
> > it from the main script.  I see your point, though.
> >
> > >   I guess the issue is what does the user expect to happen, and I
> > >   don't really like causing one script to start failing just because
> > >   an included script dissapears.
> >
> > how about typos?  those will be hard to find.
> 
> >From my own experience: I came across a C compiler that was treating missing
> include files as empty. I was very surprised as a user. So, I am in favor of
> being explicit and fail interpretation/compilation when a file doesn't
> exist.

This is my feeling as well.

-- 
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.8p1/8.12.8) with ESMTP id h3FHawt2081467 for <[e-mail]>; Tue, 15 Apr 2003 10:36:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FHawWT081466 for ietf-mta-filters-bks; Tue, 15 Apr 2003 10:36:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FHavt2081461 for <[e-mail]>; Tue, 15 Apr 2003 10:36:57 -0700 (PDT) (envelope-from [e-mail])
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA17509; Tue, 15 Apr 2003 13:33:26 -0400 (EDT)
Date: Tue, 15 Apr 2003 13:36:51 -0400
From: Cyrus Daboo <[e-mail]>
To: Alexey Melnikov <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
cc: Sieve Mailing List <[e-mail]>
Subject: Re: Draft for script 'include' capability
Message-ID: <2147483647.1050413811@[63.163.82.24]>
In-Reply-To: <[e-mail]>
References: <2147483647.1050063758@[10.0.1.6]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.0b1 (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 Alexey,

--On Monday, April 14, 2003 11:30 PM -0600 Alexey Melnikov 
<[e-mail]> wrote:

|> From my own experience: I came across a C compiler that was treating
|> missing
| include files as empty. I was very surprised as a user. So, I am in favor
| of being explicit and fail interpretation/compilation when a file doesn't
| exist.

Alternatively, we could allow a ':nofail' parameter to include so that a 
user could explicitly turn on silent failures for missing include files. 
Thus if a user really wanted to do something along the lines of what Rob 
proposed, they could do that, e.g.:

include :nofail "my_optional_vacation_script";

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FGnRt2075338 for <[e-mail]>; Tue, 15 Apr 2003 09:49:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FGnRBY075336 for ietf-mta-filters-bks; Tue, 15 Apr 2003 09:49:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FGnPt2075324 for <[e-mail]>; Tue, 15 Apr 2003 09:49:26 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 15 Apr 2003 09:49:21 -0700 (PDT)
Date: Tue, 15 Apr 2003 09:49:05 -0700 (PDT)
From: [e-mail]
Subject: Re: variables: scoping
In-reply-to: "Your message dated Tue, 15 Apr 2003 14:22:15 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Sieve Mailing List <[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]> <[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>

> [Ned Freed]:
> >
> >   I strongly object to this proposal. It adds considerable
> >   implementation complexity yet achieves negligable benefits.

> okay.  my proposal demonstrates that the ability can be added later if
> need be, anyway.  (variables must have global scope (across includes)
> now to enable that extension later.)

Good point, and sufficient IMO to table this whole thing for now.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FGPCt2074066 for <[e-mail]>; Tue, 15 Apr 2003 09:25:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FGPCxj074065 for ietf-mta-filters-bks; Tue, 15 Apr 2003 09:25:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FGP6t2074060 for <[e-mail]>; Tue, 15 Apr 2003 09:25:11 -0700 (PDT) (envelope-from [e-mail])
Received: from messagingdirect.com (dhcp198-169.esys.ca [198.161.92.169]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3FGScV28072; Tue, 15 Apr 2003 10:28:38 -0600
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2003 23:30:59 -0600
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: Kjetil Torgrim Homme <[e-mail]>
CC: Sieve Mailing List <[e-mail]>
Subject: Re: Draft for script 'include' capability
References: <2147483647.1050063758@[10.0.1.6]> <[e-mail]> <[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>

> >   > |     3   How should non-exist include scripts be handled?
> >   >
> >   > error at compile-time or run-time depending on the implementation.
> >
> >   I'd argue that these should be interpreted to be empty scripts,
> >   since I suspect runtime errors could be more confusing to the end
> >   user.  (Since generally users don't see explicit error notices
> >   from sieve runs).
> >
> >   The advantage of interpreting it as an empty script is you can
> >   have your main script include stuff like "my-vacation-script"
> >   which then can just be deleted when you come back, as opposed to
> >   having to modify your main script.
>
> heh.  I'd prefer to keep my vacation-script around, and just disable
> it from the main script.  I see your point, though.
>
> >   I guess the issue is what does the user expect to happen, and I
> >   don't really like causing one script to start failing just because
> >   an included script dissapears.
>
> how about typos?  those will be hard to find.

>From my own experience: I came across a C compiler that was treating missing
include files as empty. I was very surprised as a user. So, I am in favor of
being explicit and fail interpretation/compilation when a file doesn't
exist.

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

Work Phone: [phone]
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FCMHt2055434 for <[e-mail]>; Tue, 15 Apr 2003 05:22:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FCMHKk055433 for ietf-mta-filters-bks; Tue, 15 Apr 2003 05:22:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FCMFt2055421 for <[e-mail]>; Tue, 15 Apr 2003 05:22:16 -0700 (PDT) (envelope-from [e-mail])
Received: from yksi.ifi.uio.no ([129.240.65.221]) by pat.uio.no with esmtp (Exim 2.12 #7) id 195PS3-000643-00 for [e-mail]; Tue, 15 Apr 2003 14:22:15 +0200
Received: (from kjetilho@localhost) by yksi.ifi.uio.no ; Tue, 15 Apr 2003 14:22:15 +0200
To: Sieve Mailing List <[e-mail]>
Subject: Re: variables: scoping
References: <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 15 Apr 2003 14:22:15 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 11
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>

[Ned Freed]:
>
>   I strongly object to this proposal. It adds considerable
>   implementation complexity yet achieves negligable benefits.

okay.  my proposal demonstrates that the ability can be added later if
need be, anyway.  (variables must have global scope (across includes)
now to enable that extension later.)

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FBXSt2048173 for <[e-mail]>; Tue, 15 Apr 2003 04:33:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FBXSm6048172 for ietf-mta-filters-bks; Tue, 15 Apr 2003 04:33:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FBXQt2048167 for <[e-mail]>; Tue, 15 Apr 2003 04:33:26 -0700 (PDT) (envelope-from [e-mail])
Received: from yksi.ifi.uio.no ([129.240.65.221]) by pat.uio.no with esmtp (Exim 2.12 #7) id 195Ogn-0000tY-00 for [e-mail]; Tue, 15 Apr 2003 13:33:25 +0200
Received: (from kjetilho@localhost) by yksi.ifi.uio.no ; Tue, 15 Apr 2003 13:33:25 +0200
To: [e-mail]
Subject: Re: Integer variables
References: <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 15 Apr 2003 13:33:25 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 25
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>

[Alexey Melnikov]:
>
>   I don't think this was discussed, excuse me if I've missed the
>   discussion.

it hasn't been discussed.

>   Am I allowed to do the following using "variables" extension:
>   
>   set "NumVar" 100M;

no.

>   If the answer is yes, two more questions:
>   1). How do we expand integer variables inside strings?
>   2). Can a variable get a string value after it was assigned an integer
>   value?

the problem is rather that the variable can only be expanded inside a
string, so it would lose its integer property.

do you have a use for integer variables?

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F59ft2007141 for <[e-mail]>; Mon, 14 Apr 2003 22:09:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3F59f9D007140 for ietf-mta-filters-bks; Mon, 14 Apr 2003 22:09:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F59et2007135 for <[e-mail]>; Mon, 14 Apr 2003 22:09:40 -0700 (PDT) (envelope-from [e-mail])
Received: from messagingdirect.com (1Cust164.tnt3.edmonton.ab.da.uu.net [64.10.184.164]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3F5D9V23981; Mon, 14 Apr 2003 23:13:10 -0600
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2003 23:02:15 -0600
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: [e-mail]
Subject: Integer variables
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>

I don't think this was discussed, excuse me if I've missed the
discussion.
Am I allowed to do the following using "variables" extension:

set "NumVar" 100M;

If the answer is yes, two more questions:
1). How do we expand integer variables inside strings?
2). Can a variable get a string value after it was assigned an integer
value?

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

Work Phone: [phone]
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F58Zt2007126 for <[e-mail]>; Mon, 14 Apr 2003 22:08:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3F58ZLW007125 for ietf-mta-filters-bks; Mon, 14 Apr 2003 22:08:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F58Rt2007115 for <[e-mail]>; Mon, 14 Apr 2003 22:08:34 -0700 (PDT) (envelope-from [e-mail])
Received: from messagingdirect.com (1Cust164.tnt3.edmonton.ab.da.uu.net [64.10.184.164]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3F5B6V23970; Mon, 14 Apr 2003 23:11:14 -0600
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2003 20:38:17 -0600
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: Jutta Degener <[e-mail]>
CC: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft   (draft-homme-sieve-variables-00.txt))
References: <[e-mail]> <[e-mail]> <[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>

Jutta Degener wrote:

> On Sun, Apr 13, 2003 at 05:53:40PM +0200, Kjetil Torgrim Homme wrote:
> > [Alexey Melnikov]:
> > >
> > >   In order to move imapflags extension forward I need support for
> > >   set/list variables.
>
> I think we might be able to do without this.  What if you allow
> (and ignore) empty strings in a [...] list?
>
> That way, you could set
>
>         set "aflag" "aflag"
>
>         ["${aflag}", "${bflag}", "${cflag}"]
>
> and have that come out as
>
>         ["aflag" "" ""]
>
> if bflag and cflag are unset.
>
> There are still things that you can do with a list algebra
> that you can't do with this approach -- infinitely many
> flags based on the header and body contents of a message --
> but I don't think we want to do those things badly enough
> to warrant adding three new commands and a variable data type.

Surely three new actions shouldn't scare you :-).
But I understand the complexity of multiple data types.

Ok, I can live with this.
It seems the only thing required to be said is that empty strings are
ignored in a list that specifies flags to be set.
I should also mention that each list member defines a separate flag and
spaces in flag names are not allowed (due to IMAP restriction).

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

Work Phone: [phone]
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EL3DbP078856 for <[e-mail]>; Mon, 14 Apr 2003 14:03:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EL3DGK078855 for ietf-mta-filters-bks; Mon, 14 Apr 2003 14:03:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EL3CbP078850 for <[e-mail]>; Mon, 14 Apr 2003 14:03:12 -0700 (PDT) (envelope-from [e-mail])
Received: from PLATO.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id QAA10546; Mon, 14 Apr 2003 16:59:38 -0400 (EDT)
Date: Mon, 14 Apr 2003 17:03:52 -0400
From: Cyrus Daboo <[e-mail]>
To: Rob Siemborski <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
cc: Sieve Mailing List <[e-mail]>
Subject: Re: Draft for script 'include' capability
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <2147483647.1050063758@[10.0.1.6]> <[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>

Hi Rob,

--On Monday, April 14, 2003 4:37 PM -0400 Rob Siemborski 
<[e-mail]> wrote:

|> I prefer
|>   include :global "spam-tests";
|> over
|>   include "/global/spam-tests";
|>
|> the default should be to look in the personal folder.
|
| I like this.

Seems OK to me too, and provides a little better extensibility -- see next 
comment.

|> | 4 Open Issues:
|> |
|> |     1   Should we allow URIs to point to scripts to include?
|>
|> the possibility of reliance on external resources should not be
|> offered.
|
| I'm assuming your argument against this is "lack of utility" which I
| suspect I can agree with.

I think we can skip this for now and if it ever becomes necessary we can 
simply define it as a new extension and use the 'include :uri "..."' syntax 
for it.

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EKqubP078588 for <[e-mail]>; Mon, 14 Apr 2003 13:52:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EKquKW078587 for ietf-mta-filters-bks; Mon, 14 Apr 2003 13:52:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EKqtbP078582 for <[e-mail]>; Mon, 14 Apr 2003 13:52:55 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 195Awb-0006Od-00 for [e-mail]; Mon, 14 Apr 2003 22:52:49 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Mon, 14 Apr 2003 22:52:49 +0200
To: Sieve Mailing List <[e-mail]>
Subject: Re: Draft for script 'include' capability
References: <2147483647.1050063758@[10.0.1.6]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 14 Apr 2003 22:52:49 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 47
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>

[Rob Siemborski]:
>
>   On Sun, 14 Apr 2003, Kjetil Torgrim Homme wrote:
>   
>   > |     1   Should we allow URIs to point to scripts to include?
>   >
>   > the possibility of reliance on external resources should not be
>   > offered.
>   
>   I'm assuming your argument against this is "lack of utility"

not really.  if scripts can be fetched by HTTP, you introduce a
reliance on a working name service both locally and at the remote
site.  you also need to punch huge holes in your firewall.
furthermore, the script must be downloaded for each invocation of the
include statement, which puts an additional strain on the server, and
slows down throughput (== more deliveries running simultaneously).

>   which I suspect I can agree with.

well, I don't see the great utility, either :-)

>   > |     3   How should non-exist include scripts be handled?
>   >
>   > error at compile-time or run-time depending on the implementation.
>   
>   I'd argue that these should be interpreted to be empty scripts,
>   since I suspect runtime errors could be more confusing to the end
>   user.  (Since generally users don't see explicit error notices
>   from sieve runs).
>   
>   The advantage of interpreting it as an empty script is you can
>   have your main script include stuff like "my-vacation-script"
>   which then can just be deleted when you come back, as opposed to
>   having to modify your main script.

heh.  I'd prefer to keep my vacation-script around, and just disable
it from the main script.  I see your point, though.

>   I guess the issue is what does the user expect to happen, and I
>   don't really like causing one script to start failing just because
>   an included script dissapears.

how about typos?  those will be hard to find.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EKgtbP078343 for <[e-mail]>; Mon, 14 Apr 2003 13:42:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EKgtle078342 for ietf-mta-filters-bks; Mon, 14 Apr 2003 13:42:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EKgsbP078336 for <[e-mail]>; Mon, 14 Apr 2003 13:42:54 -0700 (PDT) (envelope-from [e-mail])
Received: from PLATO.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id QAA10384; Mon, 14 Apr 2003 16:39:22 -0400 (EDT)
Date: Mon, 14 Apr 2003 16:43:36 -0400
From: Cyrus Daboo <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>, Sieve Mailing List <[e-mail]>
Subject: Re: variables: dynamic match patterns
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[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>

Hi Kjetil,

--On Monday, April 14, 2003 10:19 PM +0200 Kjetil Torgrim Homme 
<[e-mail]> wrote:

|>   Hm.  That's a reasonable offer, Kjetil, but I'd rather eat the
|>   complexity as an implementor than to place it on the users and
|>   client writers by making this be an implementation-specific
|>   difference.
|
| well, that is one side of it.  the other side is that of the server
| administrators.  if you must support multipass searches in body, this
| may be a performance hit for servers.  the administrator has few
| options: pray that people won't use it too often, buy more hardware
| (RAM!), or turn off the body extension altogether.

Sadly we have already seen multiple instances of ISPs disabling the IMAP 
SEARCH command because they feel that is too 'expensive' CPU-wise and 
adversely effects performance. I would guess the same philosophy will be 
applied to body searches in sieve.

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EKbrbP078241 for <[e-mail]>; Mon, 14 Apr 2003 13:37:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EKbrgI078240 for ietf-mta-filters-bks; Mon, 14 Apr 2003 13:37:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EKbpbP078235 for <[e-mail]>; Mon, 14 Apr 2003 13:37:51 -0700 (PDT) (envelope-from [e-mail])
Received: from MAIL4.andrew.cmu.edu (MAIL4.andrew.cmu.edu [128.2.10.134]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3EKbjfg016308; Mon, 14 Apr 2003 16:37:45 -0400
Date: Mon, 14 Apr 2003 16:37:44 -0400 (EDT)
From: Rob Siemborski <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
cc: Sieve Mailing List <[e-mail]>
Subject: Re: Draft for script 'include' capability
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <2147483647.1050063758@[10.0.1.6]> <[e-mail]>
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>

On Sun, 14 Apr 2003, Kjetil Torgrim Homme wrote:

> I prefer
>   include :global "spam-tests";
> over
>   include "/global/spam-tests";
>
> the default should be to look in the personal folder.

I like this.

> | 4 Open Issues:
> |
> |     1   Should we allow URIs to point to scripts to include?
>
> the possibility of reliance on external resources should not be
> offered.

I'm assuming your argument against this is "lack of utility" which I
suspect I can agree with.

> |     2   Should we allow string lists as argument to include?
>
> I don't see the usefulness of it, but I don't care either way.
>
> |     3   How should non-exist include scripts be handled?
>
> error at compile-time or run-time depending on the implementation.

I'd argue that these should be interpreted to be empty scripts, since I
suspect runtime errors could be more confusing to the end user.  (Since
generally users don't see explicit error notices from sieve runs).

The advantage of interpreting it as an empty script is you can have your
main script include stuff like "my-vacation-script" which then can just be
deleted when you come back, as opposed to having to modify your main
script.

I guess the issue is what does the user expect to happen, and I don't
really like causing one script to start failing just because an included
script dissapears.

-Rob

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EKJNbP077880 for <[e-mail]>; Mon, 14 Apr 2003 13:19:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EKJNpS077879 for ietf-mta-filters-bks; Mon, 14 Apr 2003 13:19:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EKJMbP077874 for <[e-mail]>; Mon, 14 Apr 2003 13:19:22 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 195AQA-0002Sw-00 for [e-mail]; Mon, 14 Apr 2003 22:19:18 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Mon, 14 Apr 2003 22:19:17 +0200
To: Sieve Mailing List <[e-mail]>
Subject: Re: variables: dynamic match patterns
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 14 Apr 2003 22:19:17 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 15
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>

[Jutta Degener]:
>
>   Hm.  That's a reasonable offer, Kjetil, but I'd rather eat the
>   complexity as an implementor than to place it on the users and
>   client writers by making this be an implementation-specific
>   difference.

well, that is one side of it.  the other side is that of the server
administrators.  if you must support multipass searches in body, this
may be a performance hit for servers.  the administrator has few
options: pray that people won't use it too often, buy more hardware
(RAM!), or turn off the body extension altogether.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EK5cbP077073 for <[e-mail]>; Mon, 14 Apr 2003 13:05:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EK5cvn077072 for ietf-mta-filters-bks; Mon, 14 Apr 2003 13:05:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EK5bbP077066 for <[e-mail]>; Mon, 14 Apr 2003 13:05:37 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3EK5KFe006503 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 14 Apr 2003 13:05:21 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3EK5Kqu021705; Mon, 14 Apr 2003 13:05:20 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 545F417999; Mon, 14 Apr 2003 13:04:54 -0700 (PDT)
Date: Mon, 14 Apr 2003 13:04:54 -0700
From: Jutta Degener <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Sieve Mailing List <[e-mail]>
Subject: Re: variables: dynamic match patterns
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3EK5Kqu021705
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 Mon, Apr 14, 2003 at 09:42:53PM +0200, Kjetil Torgrim Homme wrote:
> how about:
> 
> (somewhere at the start of the specification:)
>   A constant string is a string or multi-line value without variable
>   references.
> 
> (in a section on interactions with old and new mechanisms?)
>   Implementations MAY require match patterns to be constant strings
>   when used with some test types.  Such implementations MUST reject
>   the activation of scripts with disallowed match patterns.
> 
> is it too strong to require the error to be discovered at upload time?
> I don't feel good about allowing it to happen during run-time, but
> that might be a quality-of-implementation issue.

Hm.  That's a reasonable offer, Kjetil, but I'd rather eat
the complexity as an implementor than to place it on the users
and client writers by making this be an implementation-specific
difference.

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EJh0bP074207 for <[e-mail]>; Mon, 14 Apr 2003 12:43:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EJh06q074206 for ietf-mta-filters-bks; Mon, 14 Apr 2003 12:43:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EJgwbP074196 for <[e-mail]>; Mon, 14 Apr 2003 12:42:58 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 1959qv-0006oQ-00 for [e-mail]; Mon, 14 Apr 2003 21:42:53 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Mon, 14 Apr 2003 21:42:53 +0200
To: Sieve Mailing List <[e-mail]>
Subject: Re: variables: dynamic match patterns
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 14 Apr 2003 21:42:53 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 31
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>

[Ned Freed]:
>
>   Fair enough, but the case that breaks the bank is body. You really
>   really really want to do all your body search operations in a
>   single passs. If you don't you can easily write scripts that have
>   serious performance problems.

agreed.

>   I don't especially care about the case of optimizing the header,
>   address, envelope, and string tests, but body is a serious
>   problem. And it seems fairly awkward to say that the match
>   parameter doesn't get expanded in body but does elsewhere.

how about:

(somewhere at the start of the specification:)
  A constant string is a string or multi-line value without variable
  references.

(in a section on interactions with old and new mechanisms?)
  Implementations MAY require match patterns to be constant strings
  when used with some test types.  Such implementations MUST reject
  the activation of scripts with disallowed match patterns.

is it too strong to require the error to be discovered at upload time?
I don't feel good about allowing it to happen during run-time, but
that might be a quality-of-implementation issue.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EJ7YbP072611 for <[e-mail]>; Mon, 14 Apr 2003 12:07:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EJ7YLf072610 for ietf-mta-filters-bks; Mon, 14 Apr 2003 12:07:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EJ7VbP072604 for <[e-mail]>; Mon, 14 Apr 2003 12:07:32 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 14 Apr 2003 12:07:24 -0700 (PDT)
Date: Mon, 14 Apr 2003 12:04:32 -0700 (PDT)
From: [e-mail]
Subject: Re: variables: interaction with "require"
In-reply-to: "Your message dated Mon, 14 Apr 2003 20:48:34 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Sieve Mailing List <[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]> <[e-mail]> <[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>

> [Ned Freed]:
> >
> >   [Jutta]:
> >   > Now that the door has been opened to "strings that don't have
> >   > variables expanded in them", can we consider using the same kind
> >   > of strings as variable names in "set" commands and as match
> >   > patterns?
> >
> >   I've thought about this and I believe I like it. I assume you're
> >   talking about any match argument anywhere, not just when :matches
> >   or :regex are in use. (The issue with body isn't addressed unless
> >   you do this.)

> REQUIRE is a special case in that it is only allowed as the first
> action in a script.  it therefore makes sense that all REQUIRE are
> processed before any of them take effect.  (this is also a useful rule
> for resolving dependencies among extensions if that should occur in
> the future.)

> the parser/lexer will know which strings contain variable references,
> and can easily set a boolean for "constant/non-constant".  I suggest
> we use terminology like "<argument> must be a constant string without
> variable references".  this makes "${foo}" an error, not a verbatim
> value, in such a context.

Good point.

> >   This needs to apply to the match argument in the string test as
> >   well. It cannot apply to the source argument or the test becomes
> >   worthless.
> >
> >   > (So they can be precompiled and don't change contents
> >   > during program execution.)
> >
> >   Yep. Seems like a good idea to me.

> why can't you optimise it only if the string is static?  I can see
> some utility in being able to match against a previous result.

>   require [ "variables", "fileinto" ];
>   if header [ "List-ID" ] :matches "*<*@*>*" {
>      set "listaddr" "${2}@{3}";
>      set "listname" "${2}";
>      if address :is :all [ "to", "cc" ] "${list}" {
>         fileinto "INBOX.lists.${listname}";
>      } else {
>         fileinto "INBOX.possibly-spam";
>      }
>   }

Fair enough, but the case that breaks the bank is body. You really really
really want to do all your body search operations in a single passs. If you
don't you can easily write scripts that have serious performance problems.

I don't especially care about the case of optimizing the header, address,
envelope, and string tests, but body is a serious problem. And it seems fairly
awkward to say that the match parameter doesn't get expanded in body but
does elsewhere.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EImfbP072214 for <[e-mail]>; Mon, 14 Apr 2003 11:48:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EImfDn072213 for ietf-mta-filters-bks; Mon, 14 Apr 2003 11:48:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EImdbP072208 for <[e-mail]>; Mon, 14 Apr 2003 11:48:40 -0700 (PDT) (envelope-from [e-mail])
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19590M-0000MF-00 for [e-mail]; Mon, 14 Apr 2003 20:48:34 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Mon, 14 Apr 2003 20:48:34 +0200
To: Sieve Mailing List <[e-mail]>
Subject: Re: variables: interaction with "require"
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 14 Apr 2003 20:48:34 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 50
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>

[Ned Freed]:
>
>   [Jutta]:
>   > Now that the door has been opened to "strings that don't have
>   > variables expanded in them", can we consider using the same kind
>   > of strings as variable names in "set" commands and as match
>   > patterns?
>   
>   I've thought about this and I believe I like it. I assume you're
>   talking about any match argument anywhere, not just when :matches
>   or :regex are in use. (The issue with body isn't addressed unless
>   you do this.)

REQUIRE is a special case in that it is only allowed as the first
action in a script.  it therefore makes sense that all REQUIRE are
processed before any of them take effect.  (this is also a useful rule
for resolving dependencies among extensions if that should occur in
the future.)

the parser/lexer will know which strings contain variable references,
and can easily set a boolean for "constant/non-constant".  I suggest
we use terminology like "<argument> must be a constant string without
variable references".  this makes "${foo}" an error, not a verbatim
value, in such a context.

>   This needs to apply to the match argument in the string test as
>   well. It cannot apply to the source argument or the test becomes
>   worthless.
>   
>   > (So they can be precompiled and don't change contents
>   > during program execution.)
>   
>   Yep. Seems like a good idea to me.

why can't you optimise it only if the string is static?  I can see
some utility in being able to match against a previous result.

  require [ "variables", "fileinto" ];
  if header [ "List-ID" ] :matches "*<*@*>*" {
     set "listaddr" "${2}@{3}";
     set "listname" "${2}";
     if address :is :all [ "to", "cc" ] "${list}" {
        fileinto "INBOX.lists.${listname}";
     } else {
        fileinto "INBOX.possibly-spam";
     }
  }

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EHJkbP068449 for <[e-mail]>; Mon, 14 Apr 2003 10:19:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EHJk3J068448 for ietf-mta-filters-bks; Mon, 14 Apr 2003 10:19:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EHJibP068443 for <[e-mail]>; Mon, 14 Apr 2003 10:19:45 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 14 Apr 2003 10:19:32 -0700 (PDT)
Date: Mon, 14 Apr 2003 10:16:07 -0700 (PDT)
From: [e-mail]
Subject: Re: variables: interaction with "require"
In-reply-to: "Your message dated Mon, 14 Apr 2003 09:22:31 -0700" <[e-mail]>
To: Jutta Degener <[e-mail]>
Cc: [e-mail], Kjetil Torgrim Homme <[e-mail]>, Sieve Mailing List <[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]> <[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>

> On Sun, Apr 13, 2003 at 10:20:56PM -0700, [e-mail] wrote:
> > [Kjetil]
> > > + The require clauses themselves are not affected by this extension.
> >
> > I agree with this proposed solution to the problem.

> Now that the door has been opened to "strings that don't
> have variables expanded in them", can we consider using
> the same kind of strings as variable names in "set"
> commands and as match patterns?

I've thought about this and I believe I like it. I assume you're talking
about any match argument anywhere, not just when :matches or :regex
are in use. (The issue with body isn't addressed unless you do this.)

This needs to apply to the match argument in the string test as well. It cannot
apply to the source argument or the test becomes worthless.

> (So they can be precompiled and don't change contents
> during program execution.)

Yep. Seems like a good idea to me.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EHGFbP068377 for <[e-mail]>; Mon, 14 Apr 2003 10:16:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EHGFx6068376 for ietf-mta-filters-bks; Mon, 14 Apr 2003 10:16:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EHGDbP068371 for <[e-mail]>; Mon, 14 Apr 2003 10:16:14 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 14 Apr 2003 10:15:54 -0700 (PDT)
Date: Mon, 14 Apr 2003 10:15:23 -0700 (PDT)
From: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft (draft-homme-sieve-variables-00.txt))
In-reply-to: "Your message dated Mon, 14 Apr 2003 09:18:16 -0700" <[e-mail]>
To: Jutta Degener <[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]> <[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>

> On Sun, Apr 13, 2003 at 05:53:40PM +0200, Kjetil Torgrim Homme wrote:
> > [Alexey Melnikov]:
> > >
> > >   In order to move imapflags extension forward I need support for
> > >   set/list variables.

> I think we might be able to do without this.  What if you allow
> (and ignore) empty strings in a [...] list?

> That way, you could set

> 	set "aflag" "aflag"

> 	["${aflag}", "${bflag}", "${cflag}"]

> and have that come out as

> 	["aflag" "" ""]

> if bflag and cflag are unset.

> There are still things that you can do with a list algebra
> that you can't do with this approach -- infinitely many
> flags based on the header and body contents of a message --
> but I don't think we want to do those things badly enough
> to warrant adding three new commands and a variable data type.

I agree with this assessment. The added complexity isn't worth it.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EGNKbP066729 for <[e-mail]>; Mon, 14 Apr 2003 09:23:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EGNKmN066728 for ietf-mta-filters-bks; Mon, 14 Apr 2003 09:23:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EGNJbP066723 for <[e-mail]>; Mon, 14 Apr 2003 09:23:19 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3EGMvFe013961 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 14 Apr 2003 09:22:57 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3EGMuqu013050; Mon, 14 Apr 2003 09:22:57 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 4BCEB17999; Mon, 14 Apr 2003 09:22:31 -0700 (PDT)
Date: Mon, 14 Apr 2003 09:22:31 -0700
From: Jutta Degener <[e-mail]>
To: [e-mail]
Cc: Kjetil Torgrim Homme <[e-mail]>, Sieve Mailing List <[e-mail]>
Subject: Re: variables: interaction with "require"
Message-ID: <[e-mail]>
References: <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3EGMuqu013050
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 Sun, Apr 13, 2003 at 10:20:56PM -0700, [e-mail] wrote:
> [Kjetil] 
> > + The require clauses themselves are not affected by this extension.
> 
> I agree with this proposed solution to the problem.

Now that the door has been opened to "strings that don't
have variables expanded in them", can we consider using
the same kind of strings as variable names in "set"
commands and as match patterns?

(So they can be precompiled and don't change contents
during program execution.)

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EGJ1bP066636 for <[e-mail]>; Mon, 14 Apr 2003 09:19:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3EGJ1AK066635 for ietf-mta-filters-bks; Mon, 14 Apr 2003 09:19:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3EGIubP066629 for <[e-mail]>; Mon, 14 Apr 2003 09:19:00 -0700 (PDT) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3EGIgFe013472 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Mon, 14 Apr 2003 09:18:42 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3EGIfqu012173 for <[e-mail]>; Mon, 14 Apr 2003 09:18:42 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id D0BE217999; Mon, 14 Apr 2003 09:18:16 -0700 (PDT)
Date: Mon, 14 Apr 2003 09:18:16 -0700
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft  (draft-homme-sieve-variables-00.txt))
Message-ID: <[e-mail]>
References: <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3EGIfqu012173
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 Sun, Apr 13, 2003 at 05:53:40PM +0200, Kjetil Torgrim Homme wrote:
> [Alexey Melnikov]:
> >
> >   In order to move imapflags extension forward I need support for
> >   set/list variables.

I think we might be able to do without this.  What if you allow
(and ignore) empty strings in a [...] list?

That way, you could set

	set "aflag" "aflag"

	["${aflag}", "${bflag}", "${cflag}"]

and have that come out as

	["aflag" "" ""]

if bflag and cflag are unset.

There are still things that you can do with a list algebra
that you can't do with this approach -- infinitely many
flags based on the header and body contents of a message --
but I don't think we want to do those things badly enough
to warrant adding three new commands and a variable data type.

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E5La1r005451 for <[e-mail]>; Sun, 13 Apr 2003 22:21:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3E5La3U005450 for ietf-mta-filters-bks; Sun, 13 Apr 2003 22:21:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E5LX1r005445 for <[e-mail]>; Sun, 13 Apr 2003 22:21:34 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 13 Apr 2003 22:21:24 -0700 (PDT)
Date: Sun, 13 Apr 2003 22:20:56 -0700 (PDT)
From: [e-mail]
Subject: Re: variables: interaction with "require"
In-reply-to: "Your message dated Mon, 14 Apr 2003 04:55:38 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Sieve Mailing List <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[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>

> this can happen:

>   require "variables";
>   require "file${foo}into";

> according to current spec, this should work, since ${foo} expands to
> the empty string.  how about

>   require [ "variables", "file${foo}into" ];

> should it work?  and how about

> == main script ==
>   require [ "include", "variables" ];
>   set "ext" "fileinto";
>   include "/personal/test";

> == /personal/test ==
>   require "variables";
>   require "${ext}";
>   fileinto "INBOX";

> this must not work, since each included script must be parsable on its
> own (according to the current include draft).  but if you change it
> into

> == /personal/test ==
>   require "variables";
>   require "file${ext}into";
>   fileinto "INBOX";

> it will work on its own, but bomb when included from the main script.

> I don't see how variable expansion in the arguments to require can
> ever be useful.  I suggest adding to the introduction:

>   The mechanisms detailed in this document will only apply to Sieve
>   scripts which include a require clause for the "variables" extension.
> + The require clauses themselves are not affected by this extension.

I agree with this proposed solution to the problem.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E3qu1r003957 for <[e-mail]>; Sun, 13 Apr 2003 20:52:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3E3quEm003956 for ietf-mta-filters-bks; Sun, 13 Apr 2003 20:52:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E3qt1r003951 for <[e-mail]>; Sun, 13 Apr 2003 20:52:55 -0700 (PDT) (envelope-from [e-mail])
Received: from yksi.ifi.uio.no ([129.240.65.221]) by pat.uio.no with esmtp (Exim 2.12 #7) id 194v1U-0007YM-00 for [e-mail]; Mon, 14 Apr 2003 05:52:48 +0200
Received: (from kjetilho@localhost) by yksi.ifi.uio.no ; Mon, 14 Apr 2003 05:52:48 +0200
To: [e-mail]
Subject: variables: redefining syntax or semantics?
From: Kjetil Torgrim Homme <[e-mail]>
Date: 14 Apr 2003 05:52:48 +0200
Message-ID: <[e-mail]>
Lines: 20
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>

draft -00 changes the semantics of strings.  this has the advantage
that the original Sieve syntax is left unchanged.

in <[e-mail]> I outlined syntax changes to
accomplish the same.

it seems to me that it is acceptable to change syntax if the new
syntax is more restrictive than the original, that is, the set of
valid scripts in the new syntax is a subset of the valid scripts in
the old syntax.  this is true for the suggested syntax.  (I withdraw
single quoted strings.)

even so, the syntax does change, and thus the parser must change its
behaviour depending on the extensions which are pulled in.  expressing
variable references as syntax may seem esthetically pleasing, but the
implementation might not be.

(I haven't read through the complete list archive yet.)
-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E3KZ1r003131 for <[e-mail]>; Sun, 13 Apr 2003 20:20:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3E3KZ7M003130 for ietf-mta-filters-bks; Sun, 13 Apr 2003 20:20:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E3KY1r003125 for <[e-mail]>; Sun, 13 Apr 2003 20:20:34 -0700 (PDT) (envelope-from [e-mail])
Received: from yksi.ifi.uio.no ([129.240.65.221]) by pat.uio.no with esmtp (Exim 2.12 #7) id 194uWB-0004AA-00 for [e-mail]; Mon, 14 Apr 2003 05:20:27 +0200
Received: (from kjetilho@localhost) by yksi.ifi.uio.no ; Mon, 14 Apr 2003 05:20:27 +0200
To: Sieve Mailing List <[e-mail]>
Subject: Re: Draft for script 'include' capability
References: <2147483647.1050063758@[10.0.1.6]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 14 Apr 2003 05:20:27 +0200
In-Reply-To: <2147483647.1050063758@[10.0.1.6]>
Message-ID: <[e-mail]>
Lines: 61
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>

[Cyrus Daboo]:
>
>   Below are details for a new draft that I just posted that
>   describes a script 'include' capability for including one script
>   inside another. I suspect this will be somewhat
>   controversial. Obviously this has relevance to the current
>   discussion on variables, in particular with regard to scoping. All
>   comments welcome...
>
>   A URL for this Internet-Draft is:
>   <http://www.ietf.org/internet-drafts/draft-daboo-sieve-include-00.txt>

thanks.  I think it looks good.  the only thing I don't like is
encoding private vs. global through the included filename.  (one of
the examples omits the directory prefix, btw.)

I prefer
  include :global "spam-tests";
over
  include "/global/spam-tests";

the default should be to look in the personal folder.

| 4 Open Issues:
|     
|     1   Should we allow URIs to point to scripts to include?

the possibility of reliance on external resources should not be
offered.

|     2   Should we allow string lists as argument to include?

I don't see the usefulness of it, but I don't care either way.

|     3   How should non-exist include scripts be handled?

error at compile-time or run-time depending on the implementation.

|     4   Interaction with variables?

global variables are visible.  numeric variables (match back
references) are kept across the include.  this enables the user to use
them for parameter passing if needed ...

    if string :matches "[e-mail]" "*" {
        include "am_i_rcpt";
    }

----

another issue is case-sensitivity for filenames.  this is glossed over
in fileinto as well, but I think it should be stated explicitly.
something like:

    The filename is case sensitive.  An implementation MAY refuse to
    allow two files whose names only differ in case.

actually, this should go into the Managesieve draft as well.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E34T1r002438 for <[e-mail]>; Sun, 13 Apr 2003 20:04:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3E34TGp002435 for ietf-mta-filters-bks; Sun, 13 Apr 2003 20:04:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E34S1r002430 for <[e-mail]>; Sun, 13 Apr 2003 20:04:28 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 13 Apr 2003 20:04:16 -0700 (PDT)
Date: Sun, 13 Apr 2003 19:54:34 -0700 (PDT)
From: [e-mail]
Subject: Re: variables: scoping
In-reply-to: "Your message dated Mon, 14 Apr 2003 04:31:20 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Sieve Mailing List <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[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 discussion is getting unwieldy, so I'm trying to break it into
> more managable pieces.

> Lawrence Greenfield may be right, keeping all variables in one global
> scope may cause problems later.  but I don't want to make things very
> complicated, either, ie. mandatory declaration of variables before use
> seems unnecessary.

> therefore, I suggest a modifier :local to SET as a middle ground.  it
> will cause the named variable to have block local scope.  if used
> outside any blocks, it will have file local scope.  a SET _without_
> :local will either change the value of an existing variable if there
> is one in scope, or initialise a global variable.

>   require [ "variables", "include" ];
>   set "foo" "anna"; # a global variable
>   set "foo" :local "beatrice"; # this shadows the global variable
>   if ... {
>       set "foo" "charlize";
>       set "foo" :local "deborah"; # shadows the variable with file scope
>       # here, ${foo} is "deborah"
>   }
>   # here, ${foo} is "charlize"
>   include "/personal/spamtests";
>   # inside spamtests, ${foo} is the global variable with value "anna".
>   # spamtests can set new global variables which are visible after
>   # the script returns.

> this does mean that SET may be used to "declare" variables as well as
> "set" their values, but I don't think it is a problem to combine the
> two functions into one action.

I strongly object to this proposal. It adds considerable implementation
complexity yet achieves negligable benefits.

Variables give scripts capabilities they didn't have before and which cannot be
achieved with any existing mechanisms. The same cannot be said for local
variables. I fail to see the capability they provide for real world scripts
that cannot be achieved any other way.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E2tl1r002278 for <[e-mail]>; Sun, 13 Apr 2003 19:55:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3E2tlrX002277 for ietf-mta-filters-bks; Sun, 13 Apr 2003 19:55:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E2tj1r002271 for <[e-mail]>; Sun, 13 Apr 2003 19:55:46 -0700 (PDT) (envelope-from [e-mail])
Received: from yksi.ifi.uio.no ([129.240.65.221]) by pat.uio.no with esmtp (Exim 2.12 #7) id 194u8B-0001YG-00 for [e-mail]; Mon, 14 Apr 2003 04:55:39 +0200
Received: (from kjetilho@localhost) by yksi.ifi.uio.no ; Mon, 14 Apr 2003 04:55:38 +0200
To: Sieve Mailing List <[e-mail]>
Subject: variables: interaction with "require"
From: Kjetil Torgrim Homme <[e-mail]>
Date: 14 Apr 2003 04:55:38 +0200
Message-ID: <[e-mail]>
Lines: 42
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>

this can happen:

  require "variables";
  require "file${foo}into";

according to current spec, this should work, since ${foo} expands to
the empty string.  how about

  require [ "variables", "file${foo}into" ];

should it work?  and how about

== main script ==
  require [ "include", "variables" ];
  set "ext" "fileinto";
  include "/personal/test";

== /personal/test ==
  require "variables";
  require "${ext}";
  fileinto "INBOX";

this must not work, since each included script must be parsable on its
own (according to the current include draft).  but if you change it
into

== /personal/test ==
  require "variables";
  require "file${ext}into";
  fileinto "INBOX";

it will work on its own, but bomb when included from the main script.

I don't see how variable expansion in the arguments to require can
ever be useful.  I suggest adding to the introduction:

  The mechanisms detailed in this document will only apply to Sieve
  scripts which include a require clause for the "variables" extension.
+ The require clauses themselves are not affected by this extension.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E2VT1r001724 for <[e-mail]>; Sun, 13 Apr 2003 19:31:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3E2VTAq001723 for ietf-mta-filters-bks; Sun, 13 Apr 2003 19:31:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E2VR1r001718 for <[e-mail]>; Sun, 13 Apr 2003 19:31:28 -0700 (PDT) (envelope-from [e-mail])
Received: from yksi.ifi.uio.no ([129.240.65.221]) by pat.uio.no with esmtp (Exim 2.12 #7) id 194tke-0007hM-00 for [e-mail]; Mon, 14 Apr 2003 04:31:20 +0200
Received: (from kjetilho@localhost) by yksi.ifi.uio.no ; Mon, 14 Apr 2003 04:31:20 +0200
To: Sieve Mailing List <[e-mail]>
Subject: variables: scoping
From: Kjetil Torgrim Homme <[e-mail]>
Date: 14 Apr 2003 04:31:20 +0200
Message-ID: <[e-mail]>
Lines: 34
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>

the discussion is getting unwieldy, so I'm trying to break it into
more managable pieces.

Lawrence Greenfield may be right, keeping all variables in one global
scope may cause problems later.  but I don't want to make things very
complicated, either, ie. mandatory declaration of variables before use
seems unnecessary.

therefore, I suggest a modifier :local to SET as a middle ground.  it
will cause the named variable to have block local scope.  if used
outside any blocks, it will have file local scope.  a SET _without_
:local will either change the value of an existing variable if there
is one in scope, or initialise a global variable.

  require [ "variables", "include" ];
  set "foo" "anna"; # a global variable
  set "foo" :local "beatrice"; # this shadows the global variable
  if ... {
      set "foo" "charlize";
      set "foo" :local "deborah"; # shadows the variable with file scope
      # here, ${foo} is "deborah"
  }
  # here, ${foo} is "charlize"
  include "/personal/spamtests";
  # inside spamtests, ${foo} is the global variable with value "anna".
  # spamtests can set new global variables which are visible after
  # the script returns.

this does mean that SET may be used to "declare" variables as well as
"set" their values, but I don't think it is a problem to combine the
two functions into one action.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3DFrkJM014165 for <[e-mail]>; Sun, 13 Apr 2003 08:53:46 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3DFrkdX014162 for ietf-mta-filters-bks; Sun, 13 Apr 2003 08:53:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3DFreJM014107 for <[e-mail]>; Sun, 13 Apr 2003 08:53:40 -0700 (PDT)
Received: from yksi.ifi.uio.no ([129.240.65.221]) by pat.uio.no with esmtp (Exim 2.12 #7) id 194jnY-0007VY-00; Sun, 13 Apr 2003 17:53:40 +0200
Received: (from kjetilho@localhost) by yksi.ifi.uio.no ; Sun, 13 Apr 2003 17:53:40 +0200
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: List variables in Sieve (Re: variables draft  (draft-homme-sieve-variables-00.txt))
References: <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 13 Apr 2003 17:53:40 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 64
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>

[Alexey Melnikov]:
>
>   In order to move imapflags extension forward I need support for
>   set/list variables.

I've read your draft, but I don't see why.  I'm currently reading the
complete archive for this list to get a better feel for the philosophy
of Sieve, but it takes some time :-)

>   I haven't thought too much how this is going to be implemented (so
>   don't blame me if I say something stupid ;-)), but here are some
>   preliminary thoughts and questions:
>   
>   1). Special syntax for list variables?
>   2). Can they be expanded inside strings? If yes, what does it mean?
>   3). Need new actions to add/remove values to the list:
>   
>   addhead <listvariable> <value(s)>
>   addtail <listvariable> <value(s)>
>   remove <listvariable> <value(s)>

the first two operate on a list, but remove operates on a set.

it has occured to me that

  SET "foo" ["hi", "there"];

seems a natural thing to write, which perhaps should be supported in
some way.  I'm not sure what it should be used for, though.

if we want to go for generality, it may be a good idea to offer a
associative array/hash/dictionary rather than an indexed list.  after
all, the hash can be used as if it was an indexed list, AWK does this.

  SET "foo" :index "bar" "zot";
  "${foo{bar}}" => "zot"

>   4). Need a way to convert a list variable to a string form
>   (conversion in other direction is easily achievable with existing
>   capabilities: set listvar ["${var1}", "${var2}", ...];)
>   
>   New command:
>    asstring <identifier> <listvariable> <delimeter_str>
>   
>   <delimeter_str> defines the delimiter that would be inserted
>   between values of the listvariable.

if the default delimiter is the empty string, the user can add
whatever delimiter he likes in the list.  in AWK, there is a magic
global variable OFS, output field separator, to control this
behaviour.

in my current draft, a variable can only be expanded inside a string.
clearly, this expansion can not result in a list of strings.  or can
it?

   SET rcpt [ "Alice", "Bob" ];
   "hello ${rcpt}, nice to see you" =>
        [ "hello ", "Alice", "Bob", ", nice to see you" ]

just some quick thoughts.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C1PlJM003363 for <[e-mail]>; Fri, 11 Apr 2003 18:25:47 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3C1PlnB003362 for ietf-mta-filters-bks; Fri, 11 Apr 2003 18:25:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C1PhJM003356 for <[e-mail]>; Fri, 11 Apr 2003 18:25:45 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 11 Apr 2003 18:25:42 -0700 (PDT)
Date: Fri, 11 Apr 2003 18:22:40 -0700 (PDT)
From: [e-mail]
Subject: Re: Mailing list last call for draft-daboo-sieve-spamtest-03.txt
In-reply-to: "Your message dated Fri, 11 Apr 2003 08:12:44 -0700 (PDT)" <[e-mail]>
To: [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]>
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 do have a few of draft nits that need to be addressed with a revised
> version:

> ...

Just noticed another problem with the draft as it stands. It contains an
example:

        if spamtest :value "ge" :comparator "i;ascii-numeric" "3"
        {
            fileinto "INBOX.spam-trap";
        }
        elsif spamtest :is "NIL"
        {
            fileinto "INBOX.unclassified";
        }
    
This turns out not to work. The problem is that the "i;ascii-numeric"
comparator is defined to rank all strings that don't begin with a digit
after any string that does. So if the spamtest value is NIL the first
if succeeds and the second one is never reached.

This is easily corrected by reversing the clauses, of course. The fact that
NILL will rank higher probably should be noted somewhere as well.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLxIJM020619 for <[e-mail]>; Fri, 11 Apr 2003 14:59:18 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLxIGY020618 for ietf-mta-filters-bks; Fri, 11 Apr 2003 14:59:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLxHJM020612 for <[e-mail]>; Fri, 11 Apr 2003 14:59:17 -0700 (PDT)
Received: from messagingdirect.com (dhcp198-169.esys.ca [198.161.92.169]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3BM2kV13308; Fri, 11 Apr 2003 16:02:46 -0600
Message-ID: <[e-mail]>
Date: Fri, 11 Apr 2003 16:02:46 -0600
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: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: List variables in Sieve (Re: variables draft  (draft-homme-sieve-variables-00.txt))
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>

In order to move imapflags extension forward I need support for set/list variables.
I haven't thought too much how this is going to be implemented (so don't blame me if
I say something stupid ;-)), but here are some preliminary thoughts and questions:

1). Special syntax for list variables?
2). Can they be expanded inside strings? If yes, what does it mean?
3). Need new actions to add/remove values to the list:

addhead <listvariable> <value(s)>
addtail <listvariable> <value(s)>
remove <listvariable> <value(s)>

4). Need a way to convert a list variable to a string form (conversion in other
direction is easily achievable with existing capabilities: set listvar ["${var1}",
"${var2}", ...];)

New command:
 asstring <identifier> <listvariable> <delimeter_str>

<delimeter_str> defines the delimiter that would be inserted between values of the
listvariable.

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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BGOkJM004211 for <[e-mail]>; Fri, 11 Apr 2003 09:24:46 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BGOk8b004210 for ietf-mta-filters-bks; Fri, 11 Apr 2003 09:24:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BGOhJM004203 for <[e-mail]>; Fri, 11 Apr 2003 09:24:44 -0700 (PDT)
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA16673 for <[e-mail]>; Fri, 11 Apr 2003 12:19:14 -0400 (EDT)
Date: Fri, 11 Apr 2003 12:22:38 -0400
From: Cyrus Daboo <[e-mail]>
To: Sieve Mailing List <[e-mail]>
Subject: Draft for script 'include' capability
Message-ID: <2147483647.1050063758@[10.0.1.6]>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
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>

Below are details for a new draft that I just posted that describes a 
script 'include' capability for including one script inside another. I 
suspect this will be somewhat controversial. Obviously this has relevance 
to the current discussion on variables, in particular with regard to 
scoping. All comments welcome...

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: SIEVE Include Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-include-00.txt
	Pages		: 8
	Date		: 2003-4-10
	
The SIEVE [SIEVE] 'include' extension permits users to include one
SIEVE script inside another.  This can make managing large scripts
or multiple sets of scripts much easier, as well as supporting
common 'libraries' of scripts.  Users are able to include their own
personal scripts or site-wide scripts provided by the local SIEVE
implementation.

A URL for this Internet-Draft is:
<http://www.ietf.org/internet-drafts/draft-daboo-sieve-include-00.txt>


-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BFIkJM001183 for <[e-mail]>; Fri, 11 Apr 2003 08:18:46 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BFIk7p001182 for ietf-mta-filters-bks; Fri, 11 Apr 2003 08:18:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BFIiJM001178 for <[e-mail]>; Fri, 11 Apr 2003 08:18:45 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 11 Apr 2003 08:18:43 -0700 (PDT)
Date: Fri, 11 Apr 2003 08:12:44 -0700 (PDT)
From: [e-mail]
Subject: Mailing list last call for draft-daboo-sieve-spamtest-03.txt
To: [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>

A revised version of the spamtest document was just published (thanks Cyrus)
and it appears to address the issues raised at the sieve
lunch in SF. Accordingly, I'd like to begin a two week "mailing list last
call" for this document.

I do have a few of draft nits that need to be addressed with a revised
version:

(1) The document lacks the required IPR boilerplate. The IESG has recently
    started pushing back on this.

(2) The change history section needs to be marked "to be removed prior 
    to publication as an RFC".

(3) The abstract should refer to the "sieve mail filtering language" rather
    than just "sieve", in order to better put the document in context.

(4) The conventions section should be moved so it appears after the
    introduction and overview.

(5) The abstract should not be numbered.

That's it for now.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AMocJM014677 for <[e-mail]>; Thu, 10 Apr 2003 15:50:38 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AMocN1014675 for ietf-mta-filters-bks; Thu, 10 Apr 2003 15:50:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AMoaJM014671 for <[e-mail]>; Thu, 10 Apr 2003 15:50:37 -0700 (PDT)
Received: from yksi.ifi.uio.no ([129.240.65.221]) by pat.uio.no with esmtp (Exim 2.12 #7) id 193ksR-0007Od-00 for [e-mail]; Fri, 11 Apr 2003 00:50:39 +0200
Received: (from kjetilho@localhost) by yksi.ifi.uio.no ; Fri, 11 Apr 2003 00:50:38 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 11 Apr 2003 00:50:38 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 19
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>

[Marc Mutz]:
>
>   [Kjetil Torgrim Homme]:
>   >   the slightly nasty consequence of this is that the string
>   >   specifying the variable itself can contain variable
>   >   references.  it is impossible to know at compile time whether
>   >   the resulting variable name is valid.
>   
>   Suppress/disallow variable expansion in the first arg of SET?

suppress makes the parser quite hairy unless we add a single quoted
string or similar.  disallow could work, but we still need to handle
the same syntax errors.  we only remove the ability to do indirect
setting of variables.  this isn't a very useful ability, since there
is no corresponding indirect lookup of variables, but I'm sure it can
be exploited somehow...

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AKaUJM009161 for <[e-mail]>; Thu, 10 Apr 2003 13:36:30 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AKaU9P009160 for ietf-mta-filters-bks; Thu, 10 Apr 2003 13:36:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AKaTJM009156 for <[e-mail]>; Thu, 10 Apr 2003 13:36:29 -0700 (PDT)
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3AKaUal016309 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 10 Apr 2003 13:36:30 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3AKaTqu008972; Thu, 10 Apr 2003 13:36:29 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 4C8B117996; Thu, 10 Apr 2003 13:36:18 -0700 (PDT)
Date: Thu, 10 Apr 2003 13:36:18 -0700
From: Jutta Degener <[e-mail]>
To: Marc Mutz <[e-mail]>
Cc: [e-mail]
Subject: Re: regex <-> variables interaction (was: Re: variables draft (draft-homme-sieve-variables-00.txt))
Message-ID: <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h3AKaTqu008972
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 Thu, Apr 10, 2003 at 09:06:24PM +0200, Marc Mutz wrote:
Content-Description: signed data
> On Tuesday 08 April 2003 19:27, [e-mail] wrote:
> <snip>
> > > header :regex "Foo" "((a|b))*"?
> >
> > That IMO is an issue for the regex draft. As for how it should be
> > handled there,
> <snip>
> 
> On a related note, I think the regex extension should include 
> non-capturing parentheses: "make (?:money|dollars)"

Why not just omit capturing if the corresponding variable isn't used?

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJlrJM007756 for <[e-mail]>; Thu, 10 Apr 2003 12:47:53 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AJlrGG007755 for ietf-mta-filters-bks; Thu, 10 Apr 2003 12:47:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJlpJM007749 for <[e-mail]>; Thu, 10 Apr 2003 12:47:52 -0700 (PDT)
Received: from 192.168.0.3 (p5082B7F9.dip.t-dialin.net [80.130.183.249]) by max.kde.org (Postfix) with ESMTP id B7274C0C59 for <[e-mail]>; Thu, 10 Apr 2003 21:47:53 +0200 (CEST)
From: Marc Mutz <[e-mail]>
Organization: "Old Europe" - and proud
To: [e-mail]
Subject: regex <-> variables interaction (was: Re: variables draft (draft-homme-sieve-variables-00.txt))
Date: Thu, 10 Apr 2003 21:06:24 +0200
User-Agent: KMail/1.5.9
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_7Ccl+OausuJIP12"; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <[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>

--Boundary-02=_7Ccl+OausuJIP12
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Tuesday 08 April 2003 19:27, [e-mail] wrote:
<snip>
> > header :regex "Foo" "((a|b))*"?
>
> That IMO is an issue for the regex draft. As for how it should be
> handled there,
<snip>

On a related note, I think the regex extension should include=20
non-capturing parentheses: "make (?:money|dollars)"

Esp. in the light of the variables extension, which makes formerly=20
non-capturing () capturing now. As everyone here will know, capturing=20
in regexes imposes a non-negligible performance penalty on regex use,=20
which is a critical component even without capturing.

Of course, this may mean that we can't use the posix regex spec as=20
reference anymore. How about the ecmascript one? With libpcre being=20
available under a very liberal license, I don't see a bigger=20
implementation burden than with posix regexes...

Marc

=2D-=20
"You're hackers, aren't you," the barman said, eyeing us. No one said
a thing. The darkness of the Eurotunnel rolled by. Apparently we'd
given ourselves away by talking too enthusiastically about IPv6. He
looked around conspiratorially, lowered his voice. "Can you get me
some credit card numbers?"
      -- James J. King "What's the shortest way to hack a Linux box?"
         Telepolis 2001/08/11 (#9293)

--Boundary-02=_7Ccl+OausuJIP12
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+lcC73oWD+L2/6DgRAnNLAJ9Ab+lQF1L47h/RVWZShSiCPltc/gCeLszH
qyuRWLuUEWAt9EeI/KjVi18=
=h3GG
-----END PGP SIGNATURE-----

--Boundary-02=_7Ccl+OausuJIP12--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJ5xJM002692 for <[e-mail]>; Thu, 10 Apr 2003 12:05:59 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AJ5xDe002691 for ietf-mta-filters-bks; Thu, 10 Apr 2003 12:05:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AJ5vJM002686 for <[e-mail]>; Thu, 10 Apr 2003 12:05:58 -0700 (PDT)
Received: from 192.168.0.3 (pD9E11CB2.dip.t-dialin.net [217.225.28.178]) by max.kde.org (Postfix) with ESMTP id 1218CC2020 for <[e-mail]>; Thu, 10 Apr 2003 21:05:59 +0200 (CEST)
From: Marc Mutz <[e-mail]>
Organization: "Old Europe" - and proud
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
Date: Thu, 10 Apr 2003 20:24:21 +0200
User-Agent: KMail/1.5.9
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_nbbl+YJVI1igHOW"; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[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>

--Boundary-02=_nbbl+YJVI1igHOW
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Tuesday 08 April 2003 21:10, Kjetil Torgrim Homme wrote:
<snip>
>      the slightly nasty consequence of this is that the string
>      specifying the variable itself can contain variable references.
>      it is impossible to know at compile time whether the resulting
>      variable name is valid.
<snip>

Suppress/disallow variable expansion in the first arg of SET?

Marc

=2D-=20
The first casualty of war is the truth.

--Boundary-02=_nbbl+YJVI1igHOW
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+lbbn3oWD+L2/6DgRAgoOAJkBc9mirYonOeTySc58gQ84BK8oVACffu4a
RS/ilTJz47xxnN11AH0Mvbs=
=3Mds
-----END PGP SIGNATURE-----

--Boundary-02=_nbbl+YJVI1igHOW--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39McMJM027274 for <[e-mail]>; Wed, 9 Apr 2003 15:38:22 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39McMr5027273 for ietf-mta-filters-bks; Wed, 9 Apr 2003 15:38:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39McFJM027269 for <[e-mail]>; Wed, 9 Apr 2003 15:38:16 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 193OCv-0000Bt-00 for [e-mail]; Thu, 10 Apr 2003 00:38:17 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Thu, 10 Apr 2003 00:38:17 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 10 Apr 2003 00:38:16 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 106
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>

[Lawrence Greenfield]:
>
>   Formal operational semantics and careful thought on how to make
>   various features orthogonal would go a long way so we don't have
>   every specification referencing every other specification and
>   subtly altering their meanings.

no disagreement in general.  however, variables are usually a
first-class member of a language, so when we add this after the fact,
it is to be expected that most specifications have their functionality
altered (hopefully enhanced).

in my draft, this is done by changing the semantics of the basic type
string.  the alternative seems to be to make variable references a
construct only available when explicitly stated in the grammar for the
action, which in turn requires new actions and tests to be defined
whereever variables might be useful.  I obviously favour the first
approach.  it may be more painful now, but I believe it will pay off
in the long term.

now, how to do it?  in my first attempt at a draft, I changed the
grammar of quoted-string, multi-line-literal and multi-line-dotstuff.
this does seem more invasive, but it may also seem more honest.

basically, it was done like this:

       quoted-string  =  DQUOTE *(CHAR / variable-ref) DQUOTE
        variable-ref  =  "${" variable-name "}"

which is bogus, of course.  doing it right is actually quite hard (at
least for me), I don't see how to support the current syntax in the
draft without a _lot_ of grammar rules.  actually, I don't see how to
do it at all :-)

here's an attempt at a slightly simplified syntax:

  quoted-string = DQUOTE
                  *(qcontent / quoted-pair / variable-ref /
                    verbatim-dollar / "{")
                  *"$"
                  DQUOTE

        qcontent  =  %x01-21 / %x23 / %x25-5b / %x5d-%x7a / %x7c-1fffff
                ; all characters except NUL, double-quote, dollar,
                ; backslash and opening brace
     quoted-pair  =  "\" %x01-1fffff
    variable-ref  =  "${" variable-name "}"
   variable-name  =  num-variable / identifier
    num-variable  =  1*DIGIT
 verbatim-dollar  =  1*"$" (qcontent / quoted-pair / variable-ref)

the verbatim-dollar makes sure that "$${foo}" and "$\"bar" are allowed
and work as expected.  since there has to be a non-dollar character in
the verbatim-dollar expansion, strings ending in one or more dollar
characters are handled by an explicit *"$" just before the closing
quote.

using this syntax, "${!}" gives a parsing error rather than being left
verbatim.  backslash are processed differently than in my draft, a
backslash will now actually escape the variable reference, which I
think is an improvement.  "\${foo}" will parse as a quoted-pair ("\$")
followed by a "{" and "foo}".

the above syntax can be simplified further by requiring all dollars
outside variable references to be escaped using backslash.

  quoted-string = DQUOTE
                  *(qcontent / quoted-pair / variable-ref)
                  DQUOTE
        qcontent  =  %x01-21 / %x23 / %x25-5b / %x5d-1fffff
                ; all characters except NUL, double-quote, dollar and
                ; backslash

other expansions are the same as above.  strings like "$$$" and
"\\.(.*)$" now yield errors.  most users will use Sieve generators
that probably escape every dollar _anyway_ to keep the implementation
simple, so being non-intrusive in general texts doesn't seem
important.  the regexp gotcha may be the worst.


it might be useful to change string as well:

          string  =  quoted-string / squoted-string / multi-line
  squoted-string  =  "'" *(sqcontent / quoted-pair) "'"
       sqcontent  =  %x01-26 / %x28-5b / %x5d-1fffff
                ; all characters except NUL, single quote and backslash

that way the body extension can mandate the use of squoted-string for
specifying the match pattern.  yes, dependencies are tricky here.

...

btw, it seems this needs fixing in a Sieve revision:

   quoted-string  =  DQUOTE *CHAR DQUOTE
            CHAR  =  %x01-7F ; from [ABNF]
similarily:
    CHAR-NOT-DOT  =  (%x01-09 / %x0b-0c / %x0e-2d / %x2f-ff)
           ;; no dots, no CRLFs
and others doesn't include the complete Unicode repertoire.

also, CHAR includes the double quote, so "foo" "bar" could be parsed
as one quoted-string with contents ``foo" "bar''.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39LYkJM023350 for <[e-mail]>; Wed, 9 Apr 2003 14:34:46 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39LYkqa023349 for ietf-mta-filters-bks; Wed, 9 Apr 2003 14:34:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39LYiJM023343 for <[e-mail]>; Wed, 9 Apr 2003 14:34:45 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 09 Apr 2003 14:34:37 -0700 (PDT)
Date: Wed, 09 Apr 2003 14:30:19 -0700 (PDT)
From: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-reply-to: "Your message dated Wed, 09 Apr 2003 14:47:17 -0400" <[e-mail]>
To: Lawrence Greenfield <[e-mail]>
Cc: [e-mail], [e-mail], Kjetil Torgrim Homme <[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]> <[e-mail]> <[e-mail]> <[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>

>    Date: Tue, 08 Apr 2003 10:27:45 -0700 (PDT)
>    From: [e-mail]

>    Agreed, but IMO the benefits far outweigh the disadvantages. Like
>    it or not, there is a large class of operations sieve currently
>    cannot do and which people really really really want to be able to
>    do. I have to tell customers "no, you cannot do that at present
>    with sieve" at least a couple of times every month, and that they
>    have to use procmail or something similar instead.  This really
>    isn't an acceptable state of affairs IMO.

> Whatever the benefits may be, they don't let us adapt a random-ass
> approach to language design.

Nor was I suggesting any such thing be done.

> Formal operational semantics and careful thought on how to make
> various features orthogonal would go a long way so we don't have every
> specification referencing every other specification and subtly
> altering their meanings.

As is always the case in the IETF, willingness to do the work counts for a lot.
I have no problem with someone doing a formal analysis here; in fact I would
welcome it. What I object to is making such analysis a requirement to
proceed.

As for careful thought, well, isn't that why we're discussing the various
details of this extension on the list right now?

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39IlNJM014351 for <[e-mail]>; Wed, 9 Apr 2003 11:47:23 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39IlNqb014350 for ietf-mta-filters-bks; Wed, 9 Apr 2003 11:47:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39IlMJM014346 for <[e-mail]>; Wed, 9 Apr 2003 11:47:22 -0700 (PDT)
Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h39IlHdf030390; Wed, 9 Apr 2003 14:47:17 -0400
Date: Wed, 9 Apr 2003 14:47:17 -0400
Message-Id: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.3
To: [e-mail]
Cc: [e-mail], Kjetil Torgrim Homme <[e-mail]>, [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
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>

   Date: Tue, 08 Apr 2003 10:27:45 -0700 (PDT)
   From: [e-mail]

   Agreed, but IMO the benefits far outweigh the disadvantages. Like
   it or not, there is a large class of operations sieve currently
   cannot do and which people really really really want to be able to
   do. I have to tell customers "no, you cannot do that at present
   with sieve" at least a couple of times every month, and that they
   have to use procmail or something similar instead.  This really
   isn't an acceptable state of affairs IMO.

Whatever the benefits may be, they don't let us adapt a random-ass
approach to language design.

Formal operational semantics and careful thought on how to make
various features orthogonal would go a long way so we don't have every
specification referencing every other specification and subtly
altering their meanings.

Larry



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39HFqJM010124 for <[e-mail]>; Wed, 9 Apr 2003 10:15:52 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39HFqr3010123 for ietf-mta-filters-bks; Wed, 9 Apr 2003 10:15:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39HFoJM010119 for <[e-mail]>; Wed, 9 Apr 2003 10:15:51 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 09 Apr 2003 10:15:49 -0700 (PDT)
Date: Wed, 09 Apr 2003 09:48:49 -0700 (PDT)
From: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-reply-to: "Your message dated Wed, 09 Apr 2003 14:21:58 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[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]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> [Arnt Gulbrandsen]:
> >
> >   Kjetil Torgrim Homme writes:
> >   > [Tim Showalter]:
> >   >>    If I had done minimal-matching right-to-left, would the result
> >   >> have been greedy? (This would resolve my objection.)
> >   >
> >   > yes.
> >
> >   No. Consider the match for a*a in ababa: A minimal match takes aba
> >   no matter whether it's right-to-left or left-to-right, a greedy
> >   one takes ababa.

> doh!  I assumed anchored matching, sorry!

We're discussing sieve here, and sieve uses anchored matches for :matches.
While RFC 3028 doesn't have an explicit statement to the effect that :matches
is anchored, the only discussion of substring matches is specifically in the
context of :contains, and there are a couple of examples of the the form

    if header :matches "subject" "*make*money*fast*" ...

that don't make much sense if :matches is unanchored.

I also note that turning an anchored match into an unanchored match is
easy. (The opposite is not true -- another reason why sieve  matches need to be
anchored.)

We probably want to add an explicit statement when RFC 3028 is revised.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39CM1JM022918 for <[e-mail]>; Wed, 9 Apr 2003 05:22:01 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39CM1LS022917 for ietf-mta-filters-bks; Wed, 9 Apr 2003 05:22:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39CLwJM022908 for <[e-mail]>; Wed, 9 Apr 2003 05:21:59 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 193EaV-000277-00 for [e-mail]; Wed, 9 Apr 2003 14:21:59 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Wed, 9 Apr 2003 14:21:58 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 09 Apr 2003 14:21:58 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 17
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>

[Arnt Gulbrandsen]:
>
>   Kjetil Torgrim Homme writes:
>   > [Tim Showalter]:
>   >>    If I had done minimal-matching right-to-left, would the result
>   >> have been greedy? (This would resolve my objection.)
>   >
>   > yes.
>   
>   No. Consider the match for a*a in ababa: A minimal match takes aba
>   no matter whether it's right-to-left or left-to-right, a greedy
>   one takes ababa.

doh!  I assumed anchored matching, sorry!

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39AXuJM014260 for <[e-mail]>; Wed, 9 Apr 2003 03:33:56 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39AXulj014259 for ietf-mta-filters-bks; Wed, 9 Apr 2003 03:33:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39AXtJM014254 for <[e-mail]>; Wed, 9 Apr 2003 03:33:55 -0700 (PDT)
Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:13744 "ehlo melkebalanse.gulbrandsen.priv.no") by gulbrandsen.priv.no with ESMTP id <S148832AbTDIKdi>; Wed, 9 Apr 2003 12:33:38 +0200
Message-Id: <[e-mail]>
From: Arnt Gulbrandsen <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
Cc: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Date: Wed, 9 Apr 2003 12:34:17 +0200
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>

Kjetil Torgrim Homme writes:
> [Tim Showalter]:
>
>>    I implemented a mostly-linear time glob algorithm by implementing 
>>    minimal matching left-to-right. I am opposed to any semantic that 
>>    would result in pattern matching being fairly expensive 
>>    (specifically, any algorithm that results in * being recursive is 
>>    bad).
>>
>>    If I had done minimal-matching right-to-left, would the result 
>>    have been greedy? (This would resolve my objection.)
>
> yes.

No. Consider the match for a*a in ababa: A minimal match takes aba no 
matter whether it's right-to-left or left-to-right, a greedy one takes 
ababa.

--Arnt


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h390cKJM028737 for <[e-mail]>; Tue, 8 Apr 2003 17:38:21 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h390cKbl028736 for ietf-mta-filters-bks; Tue, 8 Apr 2003 17:38:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h390cIJM028731 for <[e-mail]>; Tue, 8 Apr 2003 17:38:19 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 08 Apr 2003 17:38:18 -0700 (PDT)
Date: Tue, 08 Apr 2003 17:38:05 -0700 (PDT)
From: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-reply-to: "Your message dated Wed, 09 Apr 2003 01:32:06 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[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]> <[e-mail]> <[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>

> [Tim Showalter]:
> >
> >   I implemented a mostly-linear time glob algorithm by implementing
> >   minimal matching left-to-right.  I am opposed to any semantic that
> >   would result in pattern matching being fairly expensive
> >   (specifically, any algorithm that results in * being recursive is
> >   bad).
> >
> >   If I had done minimal-matching right-to-left, would the result
> >   have been greedy?  (This would resolve my objection.)

> yes.  just reverse both strings to see this.  here's an example:

> "ababbab" ~ "*a*b?*" => [ "ab", "b", "a", "b" ]  (greedy)
> "babbaba" ~ "*?b*a*" => [ "b", "a", "b", "ba" ]  (minimal)

> or the other pair:
> "babbaba" ~ "*?b*a*" => [ "babb", "a", "", "" ]  (greedy)
> "ababbab" ~ "*a*b?*" => [ "", "", "a", "bbab" ]  (minimal)

Yep, you're right. My mistake. Sorry.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h390UHJM028609 for <[e-mail]>; Tue, 8 Apr 2003 17:30:17 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h390UHa8028608 for ietf-mta-filters-bks; Tue, 8 Apr 2003 17:30:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h390UEJM028604 for <[e-mail]>; Tue, 8 Apr 2003 17:30:16 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 08 Apr 2003 17:30:07 -0700 (PDT)
Date: Tue, 08 Apr 2003 14:56:17 -0700 (PDT)
From: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-reply-to: "Your message dated Tue, 08 Apr 2003 14:05:56 -0700" <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: [e-mail], Lawrence Greenfield <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[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>

> > Good point, but it is an ambiguity that is easily resolved simply by saying
> > glob patterns have to implement greedy matching when variables are used.

> I implemented a mostly-linear time glob algorithm by implementing
> minimal matching left-to-right.  I am opposed to any semantic that would
> result in pattern matching being fairly expensive (specifically, any
> algorithm that results in * being recursive is bad).

I'm fairly sure that the greediness or non-greediness of the match doesn't
have to affect the efficiency of the operation. I've written both greedy
and non-greedy pattern matchers, and I believe all of them exhibit the
same sort of mostly-linear never-exponential behavior you describe.

(The trick I used in the greedy case, FWIW, is to scan the remainder of the
pattern and back off the initial match so it doesn't cover material needed to
satisfy the rest of the pattern.)

> If I had done minimal-matching right-to-left, would the result have been
> greedy?  (This would resolve my objection.)

I don't think so. I think you have to tweak your approach.

> Let me know if this doesn't make sense; I'm not an expert on this.

The reason I prefer a greedy match is that it seems to be what most people have
come to expect. Capturing globs and regexps tend to be greedy by default.

				Ned



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38NW6JM024401 for <[e-mail]>; Tue, 8 Apr 2003 16:32:06 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38NW6XE024400 for ietf-mta-filters-bks; Tue, 8 Apr 2003 16:32:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38NW4JM024396 for <[e-mail]>; Tue, 8 Apr 2003 16:32:05 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 1932ZT-0002Uy-00 for [e-mail]; Wed, 9 Apr 2003 01:32:07 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Wed, 9 Apr 2003 01:32:07 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 09 Apr 2003 01:32:06 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 23
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>

[Tim Showalter]:
>
>   I implemented a mostly-linear time glob algorithm by implementing
>   minimal matching left-to-right.  I am opposed to any semantic that
>   would result in pattern matching being fairly expensive
>   (specifically, any algorithm that results in * being recursive is
>   bad).
>   
>   If I had done minimal-matching right-to-left, would the result
>   have been greedy?  (This would resolve my objection.)

yes.  just reverse both strings to see this.  here's an example:

"ababbab" ~ "*a*b?*" => [ "ab", "b", "a", "b" ]  (greedy)
"babbaba" ~ "*?b*a*" => [ "b", "a", "b", "ba" ]  (minimal)

or the other pair:
"babbaba" ~ "*?b*a*" => [ "babb", "a", "", "" ]  (greedy)
"ababbab" ~ "*a*b?*" => [ "", "", "a", "bbab" ]  (minimal)

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38N0BJM022700 for <[e-mail]>; Tue, 8 Apr 2003 16:00:11 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38N0B5M022699 for ietf-mta-filters-bks; Tue, 8 Apr 2003 16:00:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38N04JM022688 for <[e-mail]>; Tue, 8 Apr 2003 16:00:05 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19324O-0005Nt-00 for [e-mail]; Wed, 9 Apr 2003 01:00:00 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Wed, 9 Apr 2003 01:00:00 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 09 Apr 2003 01:00:00 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 143
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>

[Ned Freed]:
>
>   Well, it isn't clear to me that we want to encourage storing
>   massive texts in variables. I think the preferred approach is to
>   use variables to store smallish substitutions into larger texts.
>   
>   Philosophy aside, I'm more concerned about limits on the all-digit
>   variables since they come into being automatically than I am on
>   the limits on explicitly specified variables. I could tolerate
>   having a large limit on variables in general as long as a smaller
>   limit could apply to all-digit variables. Although come to think
>   of it, the base specification allows considerable leeway on
>   implementation limits, so I guess I could consider limits on
>   :matches as an implementation limit allowed by the base
>   specification.

I added this section to the draft:

6.  Implementation Limits

An implementation of this draft MUST support at least 128 distinct
variables.  The supported length of variable names MUST be at least 32
characters.  The supported size of a variable's content MUST be at
least 4095 octets.  Attempts to set the variable to a value larger
than the implementation supports MUST be treated as an error.

Numeric variables ${1} through ${9} MUST be supported.  Referencing
higher indices than is supported is a syntax error which MUST be
discovered at compile-time.  If the string matching a wildcard or a
regex group operator exceeds the maximum variable size, the
implementation SHOULD truncate it and MUST NOT treat it as an error.
=== ends ===

I hope this addresses your concerns.

>   > not sure what you want here.  either a clarification in the
>   > introduction like:
>   
>   >    This is an extension to the Sieve language defined by [SIEVE].  It
>   >    adds support for storing and referencing data in string variables.
>   > +  The mechanisms detailed in this document will only apply to Sieve
>   > +  scripts which include a require clause for the "variables"
>   > +  extension.
>   
>   This is what I meant.

added, thanks.

>   > interesting.  do you know where I can get a copy?  I wonder how to
>   > cram this into the modifier syntax, though.  perhaps the current
>   > approach is completely wrong.  rather than stick modifiers inside the
>   > strings, we could make them modify the SET action.  it seems a better
>   > fit to fit other elements of Sieve (both syntax and semantics).
>   
>   A copy was posted to the imapext list on 26-Feb. Hopefully Chris will
>   be able to post an updated version to the I-D directory soon.

thanks, it's at http://article.gmane.org/gmane.ietf.imapext/1436

>   >     SET :upper :comparator "i;ascii-casemap" name "${1}"
>   
>   I like this a lot better than the present modifier syntax.  You do
>   need to specify the combining rules for :upper / :lower /
>   :upperfirst / :lowerfirst.  I think the rule should be that :upper
>   and :lower are incompatible with each and so are :upperfirst and
>   :lowerfirst.  And if :Xfirst is specified along with :Y, :Y is
>   done prior to :Xfirst.

so tags in Sieve MUST be commutative?

>   > what would it take to get it changed?  it seems to me they could
>   > just take (a subset of) the Olson database and decree it as
>   > official.
>   
>   The problem is that the Olson database is constantly being changed
>   and updated, which means any snapshot you take has a good chance
>   of being at odds with reality in fairly short order. (A political
>   rather than technical base tends to do this... I understand that
>   there are 1-2 updates every month or so.) So absent the
>   wherewithall to basically have IANA act as a handler for the Olson
>   effort or something similar, I see serious problems here.

ok.  my current wording:

  Note: There is currently no registry for time zones.  If IETF
  establishes one, its names SHOULD be used.  In the absence of such a
  registry, [TZ] is the most widespread collection of time zone
  definitions and its use as a reference is RECOMMENDED.

(where [TZ] refers to Olson et al. of course)

>   
>   > >       I suggest that the correct approach to take is the one RFC
>   > >       2445 uses. I would also like to allow a time offset as an
>   > >       argument to setdate, but zone support is what's needed.
>   
>   > interesting, thanks for the reference.  do you mean to include the
>   > whole vocabulary to define a time zone?  that seems very complex to
>   > me.
>   
>   You can simply refer to it. No need to repeat it.

oh, I was worried about the implementation :-).  also, now the
responsibility for keeping the time zone definition up-to-date rests
on the Sieve client, not the server.  also, the time zone definition
could be implemented by the client using a bunch of IFs and a couple
of calls on SETDATE...

>   > actually, with ${timezone} available, the fallback can be implemented
>   > by the user.  we simply need to mandate that the time offset syntax is
>   > supported as a valid "time zone".
>   >
>   >     setdate "US-Eastern";
>   >     if not string "${timezone}" "US-Eastern" {
>   >         setdate "-0500";
>   >     }
>   
>   Interesting. I could go with this.

great :-)

>   Then by all means make the zone one that's local to the user
>   rather than to the server. I really don't think having a default
>   of UTC is the right answer here.

I'm with you, and these changes in SETDATE makes it easier to bear.

>   Date would test date values in headers. There are all sorts of
>   those, and there is considerable value in being able to test them.

ah...  yes, this is useful functionality, especially for filtering
email archives.  perhaps we could generalise SETDATE?

   SETDATE :now "+0200";	# old behaviour
   SETDATE :header "Date";
   SETDATE :header "Date" "+0000";

the default time zone for :header should be the one specified in the
header.

(what to do if there is no such header, or it can't be parsed?)
-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38LhNJM018792 for <[e-mail]>; Tue, 8 Apr 2003 14:43:23 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38LhNIK018791 for ietf-mta-filters-bks; Tue, 8 Apr 2003 14:43:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38LhKJM018786 for <[e-mail]>; Tue, 8 Apr 2003 14:43:21 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 08 Apr 2003 14:43:20 -0700 (PDT)
Date: Tue, 08 Apr 2003 14:38:40 -0700 (PDT)
From: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-reply-to: "Your message dated Tue, 08 Apr 2003 21:10:43 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[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]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> [Lawrence Greenfield]:
> >
> >   From RFC 3028, section 8.2:
> >
> >      command = identifier arguments ( ";" / block )
> >
> >      argument = string-list / number / tag
> >
> >      arguments = *argument [test / test-list]
> >
> >   Your "set" action is implicitly extending 'argument' to allow for
> >   something that is lexically identical to an 'identifier'. This
> >   extension needs to be made explicit.

> oh dear.  I've missed that entirely.

> (it's not lexically identical, ${_foo} is not allowed, though that
> should be changed for internal consistency.)

> >   You then have to resolve the parsing ambiguity, since
> >
> >   set variable "string";
> >
> >   can be produced by
> >
> >   command -> identifier arguments ;
> >           -> identifier *argument ;
> >           -> identifier variable *argument ;

> so your grammar change here is

> -   argument = string-list / number / tag
> +   argument = variable / string-list / number / tag

> ?

> >           [...]
> >           -> identifier variable string ;
> >
> >   OR
> >
> >   command -> identifier arguments ;
> >           -> identifier *argument test ;
> >           -> identifier test ;
> >           -> identifier identifier arguments ;
> >           -> identifier identifier *argument ;
> >           -> identifier identifier string-list *argument ;
> >           -> identifier identifier string *argument ;
> >           -> identifier identifier string ;
> >
> >   which are obviously two different parse trees.

> sorry, I don't follow this expansion.  does this assume a different
> grammar change?

> so, we have (at least) three options.

>   a) change SET into taking two strings.

>          SET "from" "${1}";

>      the slightly nasty consequence of this is that the string
>      specifying the variable itself can contain variable references.
>      it is impossible to know at compile time whether the resulting
>      variable name is valid.

It isn't like there aren't all sorts of error conditions that can arise in
sieve scripts already. I have no problem with creating one more.

>   b) change SET into using a tag for the variable name.

>          SET :from "${1}";

>      this looks funny, and also creates a namespace problem if we add
>      modifiers such as :upper.

Bad idea IMO.

>   c) change the base grammar of Sieve.  my suggestion is

>        - command = identifier arguments ( ";" / block )
>        + command = 1*identifier arguments ( ";" / block )

>      as far as I can tell, this does not introduce any ambiguity.

While it isn't a matter of consequence to my own implementation, I really
dislike making such a change at this point.

I think (a) is the way to go.

> >   >  does require carry over?  I'd say "no".  variables shouldn't either.
> >
> >   It's not clear to me. Nor is it clear that sites won't want to
> >   have variables cascade.

> isn't this an issue that should be dealt with in an "include"
> extension or something?

Exactly. There is a big difference between having multiple sieve scripts
and building up a single script from subscripts. Variables should not
cross from one to the other in the former case, they should in the latter
since it is purely a construction technique for producing a single
sieve script.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38LUHJM017948 for <[e-mail]>; Tue, 8 Apr 2003 14:30:17 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38LUHZF017947 for ietf-mta-filters-bks; Tue, 8 Apr 2003 14:30:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38LUEJM017942 for <[e-mail]>; Tue, 8 Apr 2003 14:30:15 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 08 Apr 2003 14:30:10 -0700 (PDT)
Date: Tue, 08 Apr 2003 14:21:34 -0700 (PDT)
From: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-reply-to: "Your message dated Tue, 08 Apr 2003 11:22:51 -0700" <[e-mail]>
To: Jutta Degener <[e-mail]>
Cc: [e-mail], Kjetil Torgrim Homme <[e-mail]>, [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]> <[e-mail]> <[e-mail]> <[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>

> On Tue, Apr 08, 2003 at 10:23:11AM -0700, [e-mail] wrote:
> > > the match order for [ a, b ] [ A, B ] should be aA, bA, aB, bB.  this
> > > means that messages sent to both addresses will be forwarded to
> > > <[e-mail]>, i.e. the first match string has precedence.
> > > in this example, what the wildcard matches is irrelevant.
> >
> > Cute. I can live with it.

> I'm not happy.  Before this, I could stop matching when any combination
> matched.  Now I have to either keep reading to the end just in case a
> variable assignment changes, or figure out in advance whether any of
> the strings following use any variables and keep reading to the end only
> if that is true.

Er, I never said that expressions shouldn't short circuit. I think they
should. But this issue, it seems to me, is independent of short circuiting.

The point here is that the saved non-wildcarded parts of the pattern can
be useful. Not that expressions must be fully evaluated. On the contrary,
if they are fully evaluated the non-wildcarded parts aren't nearly as useful.

> By the way, coupling variable assignments and matches _really_ makes
> life interesting for anyone implementing streaming matches such as "body".

Coupling variable assignmens and matches doesn't change the problem in 
any material way. How about:

   set foo "bar"
   if header :contains "to" "foo"  {set foo "bletch"}
   if body :contains "${foo}"

So as I noted previously, the addition of variables and their use in body
effectively eliminates streaming matches.

> Without them, it's possible to at least predict a finite number of
> possible variable values and match those in parallel in one pass.

Yep. I plan to either preclude the use of variables and body or else
disallow variables in body arguments because of this.

> These are extreme examples that don't affect the ability to parallelize
> the more common fixed choices, but I'm not looking forward to the
> extra complexity, and I don't think it's justified by functional
> benefits.

The functional benefits of variables are enormous -- I receive many more
requests that can be satisfied with variables than I do for the ability
to search bodies.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38L8TJM017214 for <[e-mail]>; Tue, 8 Apr 2003 14:08:29 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38L8Sdg017213 for ietf-mta-filters-bks; Tue, 8 Apr 2003 14:08:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38L8RJM017207 for <[e-mail]>; Tue, 8 Apr 2003 14:08:27 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 1930KR-00021v-00 for [e-mail]; Tue, 8 Apr 2003 23:08:27 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Tue, 8 Apr 2003 23:08:27 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 08 Apr 2003 23:08:27 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 61
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>

[Jutta Degener]:
>
>   On Tue, Apr 08, 2003 at 10:23:11AM -0700, [e-mail] wrote:
>   > > the match order for [ a, b ] [ A, B ] should be aA, bA, aB,
>   > > bB.  this means that messages sent to both addresses will be
>   > > forwarded to <[e-mail]>, i.e. the first match
>   > > string has precedence.  in this example, what the wildcard
>   > > matches is irrelevant.
>   > 
>   > Cute. I can live with it.
>   
>   I'm not happy.  Before this, I could stop matching when any
>   combination matched.
>
>   Now I have to either keep reading to the end just in case a
>   variable assignment changes, or figure out in advance whether any
>   of the strings following use any variables and keep reading to the
>   end only if that is true.

okay, I see your problem.  so which match is returned should be
undefined?  that's fine with me.  if the user needs a specific
ordering, he can split the expression.

>   By the way, coupling variable assignments and matches _really_
>   makes life interesting for anyone implementing streaming matches
>   such as "body".
>
>   Without them, it's possible to at least predict a finite number of
>   possible variable values and match those in parallel in one pass.

neat!

>   With variables, you may not be able to predict what string a later
>   match will match against, because the match pattern itself may contain
>   variables that are set as the result of previous match patterns.
>   
>   	if body :matches "*call(*,*)*",
>   	{
>   		if body :matches "*response(${3},${2})*"
>   		{
>   			...
>   		}
>   	}
>   
>   These are extreme examples that don't affect the ability to
>   parallelize the more common fixed choices, but I'm not looking
>   forward to the extra complexity, and I don't think it's justified
>   by functional benefits.

one sledgehammer is to declare that no variable expansion is performed
on match patterns.  it may seem a little arbitrary in the spec, and
indeed it can't be expressed in the grammar without _large_ changes to
it, but efficiency of implementation may trump expressiveness here.

since body isn't out as an RFC yet, an alternative approach is to
change _that_.  for instance, implementations can be allowed to refuse
searches with non-constant matching patterns.  (this can be determined
at script upload time, right?)

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38L8HJM017198 for <[e-mail]>; Tue, 8 Apr 2003 14:08:17 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38L8HZr017197 for ietf-mta-filters-bks; Tue, 8 Apr 2003 14:08:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from sift.mirapoint.com (IDENT:[e-mail] [63.107.133.19]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38L8FJM017192 for <[e-mail]>; Tue, 8 Apr 2003 14:08:15 -0700 (PDT)
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 ABQ69574; Tue, 8 Apr 2003 14:05:05 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 08 Apr 2003 14:05:56 -0700
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: Lawrence Greenfield <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; 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>

[e-mail] wrote:

>>   (1) The ${0}, ${1} all-digit variables should be set and modified by the
>>       glob-style :matches mechanism in addition to :regex. It really should
>>       not be necessary to implement regex in order to get the ability to
>>       set variables based on message inputs. For example:
>>    
>>
>>This leads to ambiguity, however.
>>    
>>
>Good point, but it is an ambiguity that is easily resolved simply by saying
>glob patterns have to implement greedy matching when variables are used.
>  
>
I implemented a mostly-linear time glob algorithm by implementing 
minimal matching left-to-right.  I am opposed to any semantic that would 
result in pattern matching being fairly expensive (specifically, any 
algorithm that results in * being recursive is bad).

If I had done minimal-matching right-to-left, would the result have been 
greedy?  (This would resolve my objection.)

Let me know if this doesn't make sense; I'm not an expert on this.

Tim




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38KCdJM015106 for <[e-mail]>; Tue, 8 Apr 2003 13:12:39 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38KCdqE015105 for ietf-mta-filters-bks; Tue, 8 Apr 2003 13:12:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38KCbJM015099 for <[e-mail]>; Tue, 8 Apr 2003 13:12:37 -0700 (PDT)
Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h38KCXKN018719 for <[e-mail]>; Tue, 8 Apr 2003 15:12:34 -0500 (CDT)
Received: from att.com (unknown[135.210.27.119](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20030408201136gw100nj0kte> (Authid: tony); Tue, 8 Apr 2003 20:11:36 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Apr 2003 16:11:55 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[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>

Kjetil Torgrim Homme wrote:
>>  I think this is fine for features that only enable certain forms
>>  of syntax (since they basically dissapear at parsing time), but is
>>  somewhat less good for things that change global state of the
>>  interpreter.
>>  
>>  Implicit keep is another "global state" issue that jumps to mind.
>>  
>>  I think I'm currently of the opinion that all global state
>>  (including variables, implicit keep, etc) should be global for the
>>  entire execution.  However, the effects of require which only
>>  affect parsing should be limited to the current script only.
> 
> if script one require variables, and set variable foo to bar, and
> script two doesn't require variables, and contain the string "${foo}",
> what should happen?  it seems to me you're saying that the string
> should be left alone.  also, if script two does require variables, the
> value of foo will become available, and the string will be expanded to
> "bar".

I'm of the other mind, though. If script one sets ${foo}, I would NOT 
expect script two to see the value of ${foo}. I'd expect the variable 
state to be reset between scripts.

	Tony Hansen
	[e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38JlwJM014277 for <[e-mail]>; Tue, 8 Apr 2003 12:47:58 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38Jlwvu014276 for ietf-mta-filters-bks; Tue, 8 Apr 2003 12:47:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38JluJM014272 for <[e-mail]>; Tue, 8 Apr 2003 12:47:57 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 192z4Y-0005vV-00 for [e-mail]; Tue, 8 Apr 2003 21:47:58 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Tue, 8 Apr 2003 21:47:58 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 08 Apr 2003 21:47:58 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 47
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>

[Tony Hansen]:
>
>   Kjetil Torgrim Homme wrote:
>   >>  Other languages have benefitted from namespaces. It might be
>   >>  worthwhile exploring that concept, particularly if there are
>   >>  preset variables. For example, instead of the preset variable
>   >>  name ${year}, you'd instead have ${time.year}. Thoughts?
>   >
>   > how should the namespace namespace be governed?  a registry?
>   > only available to extensions specified in RFCs?
>   
>   If setdate is comparable to a "require", then defining such an
>   addition should define the namespace that it places its data into.
>   Perhaps it should be ${setdate.year}, ${setdate.month}, etc.

this would work.  (there need not be a one-to-one relationship between
the name of the action/extension and the namespace, "date.year" would
work just as well.)

essentially, this is "only available to extensions specified in RFCs".
the question is if it's needed, the variable names themselves will be
carefully controlled and collisions can be avoided relatively easily.
the main benefit is that system variables look syntactically different
from user variables, and we could also make them read-only if we like.

it seems to me that namespaces are more useful if the user are allowed
to use them.  however, the user can do that, simply by imposing his
own rules for variable naming.  e.g., prefix all variables with "kj_".

>   More complex packages might want to use more fully qualified
>   names:
>   
>   	require "example";
>   	setfoo ...;
>   	setbar ...;
>   
>   	${example.foo.handle}
>   	${example.bar.contenttype}
>   
>   to make certain that they don't conflict with the "foo" and "bar"
>   namespaces of other "require" constructs.

nice, but I think this is over-engineering, and most of the effect can
be had by substituting an underscore for the period.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38JSXJM012857 for <[e-mail]>; Tue, 8 Apr 2003 12:28:33 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38JSXpv012856 for ietf-mta-filters-bks; Tue, 8 Apr 2003 12:28:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38JSVJM012849 for <[e-mail]>; Tue, 8 Apr 2003 12:28:32 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 192yll-0002EW-00 for [e-mail]; Tue, 8 Apr 2003 21:28:33 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Tue, 8 Apr 2003 21:28:33 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 08 Apr 2003 21:28:33 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 30
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>

[Rob Siemborski]:
>
>   Currently Cyrus's include draft has require being scoped to the
>   current script.

ah, I haven't seen that.  perhaps you could put it up at
http://www.cyrusoft.com/sieve/#documents ?

>   I think this is fine for features that only enable certain forms
>   of syntax (since they basically dissapear at parsing time), but is
>   somewhat less good for things that change global state of the
>   interpreter.
>   
>   Implicit keep is another "global state" issue that jumps to mind.
>   
>   I think I'm currently of the opinion that all global state
>   (including variables, implicit keep, etc) should be global for the
>   entire execution.  However, the effects of require which only
>   affect parsing should be limited to the current script only.

if script one require variables, and set variable foo to bar, and
script two doesn't require variables, and contain the string "${foo}",
what should happen?  it seems to me you're saying that the string
should be left alone.  also, if script two does require variables, the
value of foo will become available, and the string will be expanded to
"bar".

this seems reasonable to me.
-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38JAiJM009915 for <[e-mail]>; Tue, 8 Apr 2003 12:10:44 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38JAitU009914 for ietf-mta-filters-bks; Tue, 8 Apr 2003 12:10:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38JAgJM009905 for <[e-mail]>; Tue, 8 Apr 2003 12:10:43 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 192yUW-0006bc-00 for [e-mail]; Tue, 8 Apr 2003 21:10:44 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Tue, 8 Apr 2003 21:10:43 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 08 Apr 2003 21:10:43 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 92
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>

[Lawrence Greenfield]:
>
>   From RFC 3028, section 8.2:
>   
>      command = identifier arguments ( ";" / block )
>   
>      argument = string-list / number / tag
>   
>      arguments = *argument [test / test-list]
>   
>   Your "set" action is implicitly extending 'argument' to allow for
>   something that is lexically identical to an 'identifier'. This
>   extension needs to be made explicit.

oh dear.  I've missed that entirely.

(it's not lexically identical, ${_foo} is not allowed, though that
should be changed for internal consistency.)

>   You then have to resolve the parsing ambiguity, since
>   
>   set variable "string";
>   
>   can be produced by 
>   
>   command -> identifier arguments ; 
>           -> identifier *argument ;
>           -> identifier variable *argument ;

so your grammar change here is

-   argument = string-list / number / tag
+   argument = variable / string-list / number / tag

?

>           [...]
>           -> identifier variable string ;
>   
>   OR
>   
>   command -> identifier arguments ;
>           -> identifier *argument test ;
>           -> identifier test ;
>           -> identifier identifier arguments ;
>           -> identifier identifier *argument ;
>           -> identifier identifier string-list *argument ;
>           -> identifier identifier string *argument ;
>           -> identifier identifier string ;
>   
>   which are obviously two different parse trees.

sorry, I don't follow this expansion.  does this assume a different
grammar change?

so, we have (at least) three options.

  a) change SET into taking two strings.

         SET "from" "${1}";

     the slightly nasty consequence of this is that the string
     specifying the variable itself can contain variable references.
     it is impossible to know at compile time whether the resulting
     variable name is valid.

  b) change SET into using a tag for the variable name.

         SET :from "${1}";

     this looks funny, and also creates a namespace problem if we add
     modifiers such as :upper.

  c) change the base grammar of Sieve.  my suggestion is

       - command = identifier arguments ( ";" / block )
       + command = 1*identifier arguments ( ";" / block )

     as far as I can tell, this does not introduce any ambiguity.

>   >  does require carry over?  I'd say "no".  variables shouldn't either.
>   
>   It's not clear to me. Nor is it clear that sites won't want to
>   have variables cascade.

isn't this an issue that should be dealt with in an "include"
extension or something?

thank you for your feedback!

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38IWiJM007469 for <[e-mail]>; Tue, 8 Apr 2003 11:32:44 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38IWikC007468 for ietf-mta-filters-bks; Tue, 8 Apr 2003 11:32:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38IWgJM007464 for <[e-mail]>; Tue, 8 Apr 2003 11:32:42 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 192xtj-00044z-00 for [e-mail]; Tue, 8 Apr 2003 20:32:43 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Tue, 8 Apr 2003 20:32:43 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 08 Apr 2003 20:32:43 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 22
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>

[Ned Freed]:
>
>   > while this is easy to explain and understand, my original
>   > suggestion was
>   >
>   >    ${1} - String before the last a
>   >    ${2} - "a"
>   >    ${3} - String after the last a.
>   >
>   > which I now realise may have merit when matching two lists
>   > against eachother or when using the anyof test.
>   
>   Hmm. OK, I can see some utility here. Although I have to say this
>   is getting awfully tricky and I'd rather see such stuff done with
>   two separate tests.

you're right, the added expressiveness is not worth the complication.
if N tests is deemed unacceptable by the user, he will probably find
that :regex is available in most implementations anyway.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38IURJM007395 for <[e-mail]>; Tue, 8 Apr 2003 11:30:27 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38IURTu007394 for ietf-mta-filters-bks; Tue, 8 Apr 2003 11:30:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38IUPJM007390 for <[e-mail]>; Tue, 8 Apr 2003 11:30:25 -0700 (PDT)
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h38ITGal016823 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 8 Apr 2003 11:29:31 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h38IMtqu030357; Tue, 8 Apr 2003 11:26:06 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id BF0BD17996; Tue,  8 Apr 2003 11:22:51 -0700 (PDT)
Date: Tue, 8 Apr 2003 11:22:51 -0700
From: Jutta Degener <[e-mail]>
To: [e-mail]
Cc: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
Message-ID: <[e-mail]>
References: <[e-mail]> <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h38IMtqu030357
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 Tue, Apr 08, 2003 at 10:23:11AM -0700, [e-mail] wrote:
> > the match order for [ a, b ] [ A, B ] should be aA, bA, aB, bB.  this
> > means that messages sent to both addresses will be forwarded to
> > <[e-mail]>, i.e. the first match string has precedence.
> > in this example, what the wildcard matches is irrelevant.
> 
> Cute. I can live with it.

I'm not happy.  Before this, I could stop matching when any combination
matched.  Now I have to either keep reading to the end just in case a
variable assignment changes, or figure out in advance whether any of
the strings following use any variables and keep reading to the end only
if that is true.

By the way, coupling variable assignments and matches _really_ makes
life interesting for anyone implementing streaming matches such as "body".

Without them, it's possible to at least predict a finite number of
possible variable values and match those in parallel in one pass.

With variables, you may not be able to predict what string a later
match will match against, because the match pattern itself may contain
variables that are set as the result of previous match patterns.

	if body :matches "*call(*,*)*",
	{
		if body :matches "*response(${3},${2})*"
		{
			...
		}
	}

These are extreme examples that don't affect the ability to parallelize
the more common fixed choices, but I'm not looking forward to the
extra complexity, and I don't think it's justified by functional
benefits.

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38Hf1JM003391 for <[e-mail]>; Tue, 8 Apr 2003 10:41:01 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38Hf1R7003390 for ietf-mta-filters-bks; Tue, 8 Apr 2003 10:41:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HexJM003383 for <[e-mail]>; Tue, 8 Apr 2003 10:40:59 -0700 (PDT)
Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h38Hetdg013409; Tue, 8 Apr 2003 13:40:55 -0400
Date: Tue, 8 Apr 2003 13:40:55 -0400 (EDT)
From: Rob Siemborski <[e-mail]>
To: Lawrence Greenfield <[e-mail]>
cc: [e-mail], Kjetil Torgrim Homme <[e-mail]>
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

On Tue, 8 Apr 2003, Lawrence Greenfield wrote:

>    does require carry over?  I'd say "no".  variables shouldn't either.
>
> It's not clear to me. Nor is it clear that sites won't want to have
> variables cascade.

Currently Cyrus's include draft has require being scoped to the current
script.  I think this is fine for features that only enable certain forms
of syntax (since they basically dissapear at parsing time), but is
somewhat less good for things that change global state of the interpreter.

Implicit keep is another "global state" issue that jumps to mind.

I think I'm currently of the opinion that all global state
(including variables, implicit keep, etc) should be global for the entire
execution.  However, the effects of require which only affect parsing
should be limited to the current script only.

I do think Larry is correct that there are many cases that will be hard to
understand without formal syntax.

-Rob

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HdtJM003344 for <[e-mail]>; Tue, 8 Apr 2003 10:39:55 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38HdtAQ003343 for ietf-mta-filters-bks; Tue, 8 Apr 2003 10:39:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HdrJM003337 for <[e-mail]>; Tue, 8 Apr 2003 10:39:54 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 08 Apr 2003 10:39:47 -0700 (PDT)
Date: Tue, 08 Apr 2003 10:27:45 -0700 (PDT)
From: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-reply-to: "Your message dated Mon, 07 Apr 2003 23:24:50 -0400" <[e-mail]>
To: Lawrence Greenfield <[e-mail]>
Cc: [e-mail], Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[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>

> More problems:

> * Semantics

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

> This is central to the semantics of the language; this isn't a SHOULD.

Agreed. This has to be a MUST. I will also point out that this has some
interesting implications when it comes to having a body test, implications that
may cause me not to support the use of string substitutions into body tests.
(Basically I want to be able to do a single scan of the message that does all
the body checks at  the same time.)

> It should also be made clear that variables are expanded once, not
> repeatedly.

Yep. Thought of that one but forgot to mention it.

> * Syntactic structure

> The "set" action doesn't fit into the Sieve grammar, as something that is
> identical to an "identifier" is not a valid argument.

I guess that means we have to quote it. Yuck, but we do what we have to do...

> * Scope

> --On Monday, April 07, 2003 2:39 PM -0700 [e-mail] wrote:

> > As for scope, I think global scope is the right, and indeed the only
> > realistic, choice.

> Global scope is a wonderful choice that years of programming language
> theory has shown to be an extremely bad thing.

And as any Pascal programmer such as myself can tell you, the complexity
associated with scoped variables has been shown to be a bad then when it isn't
necessary.

> When Sieve scripts are run in serial (as many implementations now allow) do
> variables carry over from one to another? Why or why not?

I don't think they should carry over. As for why, it is because it makes
all sorts of unpredictable behavior very likely.

> If and when people start thinking about includes and functions, scope
> becomes even more important.

> * Numeric variables

> When does the side effect of tests have it's effect on numeric variables?
> After the test? Only inside the if?

I would say after.

> Does the ${1} in the second test refer to the variable set in the first
> test? Or does it refer to the previously set variable?

Cute. My implementation currently does the former, but I have no strong opinion
here.

> if (allof (header :regex "Foo" "${1}(.*)", header :regex "Bar" "${1}(.*)"))
> {
> }

> * Numeric variables

> What does nested grouping do?

> header :regex "Foo" "((a|b))*"?

That IMO is an issue for the regex draft. As for how it should be handled
there, I think that we should find some set of consistent capture semantics
from some regular expression system we like and follow it. Does the
Posix regexp spec cover capture?

> * Numeric variables

> Does a failed matching clear all numeric variables?

My personal preference would be "no".

> * Program analysis

> I guess some of what's bothering me is that there are several invasive
> language changes with this draft that make it significantly more difficult
> to analyze the language to make sure it isn't mutually contradictory, and
> more difficult to analyze a piece of a program without global analysis.

> . Tests now alter global state (thus the short-circuit problem)

> . Variable expansion can drastically change patterns to match against,
> preventing certain pre-compilation strategies.

Agreed, but IMO the benefits far outweigh the disadvantages. Like it or
not, there is a large class of operations sieve currently cannot do and which
people really really really want to be able to do. I have to tell customers
"no, you cannot do that at present with sieve" at least a couple of times
every month, and that they have to use procmail or something similar instead.
This really isn't an acceptable state of affairs IMO.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HQxJM002882 for <[e-mail]>; Tue, 8 Apr 2003 10:26:59 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38HQxww002881 for ietf-mta-filters-bks; Tue, 8 Apr 2003 10:26:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HQsJM002874 for <[e-mail]>; Tue, 8 Apr 2003 10:26:57 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 08 Apr 2003 10:26:51 -0700 (PDT)
Date: Tue, 08 Apr 2003 10:23:11 -0700 (PDT)
From: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-reply-to: "Your message dated Tue, 08 Apr 2003 18:47:41 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[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]> <[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>

> >   > or how about "*a*"?
> >
> >   ${1} - String before the last a
> >   ${2} - String after the last a.

> while this is easy to explain and understand, my original suggestion
> was

>    ${1} - String before the last a
>    ${2} - "a"
>    ${3} - String after the last a.

> which I now realise may have merit when matching two lists against
> eachother or when using the anyof test.

Hmm. OK, I can see some utility here. Although I have to say this is getting
awfully tricky and I'd rather see such stuff done with two separate tests.

>    if header :matches [ "To", "Cc" ] [ "foo@*.no", "bar@*.com" ] {
>         redirect "kjetilho+${1}ifi.uio.no";
>    }

> the match order for [ a, b ] [ A, B ] should be aA, bA, aB, bB.  this
> means that messages sent to both addresses will be forwarded to
> <[e-mail]>, i.e. the first match string has precedence.
> in this example, what the wildcard matches is irrelevant.

Cute. I can live with it.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HIsJM002545 for <[e-mail]>; Tue, 8 Apr 2003 10:18:54 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38HIsXf002544 for ietf-mta-filters-bks; Tue, 8 Apr 2003 10:18:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HIoJM002538 for <[e-mail]>; Tue, 8 Apr 2003 10:18:52 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 08 Apr 2003 10:18:48 -0700 (PDT)
Date: Mon, 07 Apr 2003 19:23:02 -0700 (PDT)
From: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-reply-to: "Your message dated Tue, 08 Apr 2003 02:07:18 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[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>

> >   (1) The ${0}, ${1} all-digit variables should be set and modified by the
> >       glob-style :matches mechanism in addition to :regex. It really should
> >       not be necessary to implement regex in order to get the ability to
> >       set variables based on message inputs. For example:
> >
> >       require ["variables", "envelope", "subaddress"];
> >       if allof(envelope :all :is "from" "a@b",
> >                envelope :detail :matches "to" "*")
> >         redirect "d+${1}@e"
> >
> >       Of course glob style patterns don't have the ability to
> >       specify which wildcard characters capture and which do not,
> >       but I really don't this this will be a problem in practice.

> your example shows that it is possible to do useful things with it, at
> least.

> it is possible to add, though.  one method is to split the match
> string on the meta characters.  consider the string "*@*.com" -- we
> split this in four, "*", "@", "*" and ".com".  ${2} and ${4} will
> always be "@" and ".com" (if there's a match), but ${1} and ${3} will
> contain the matching characters.

> does this sound too complicated for too little gain?

I really don't see the point of storing the static parts of the pattern. It
will also confuse people familiar with capture systems for patterns, since
AFAIK none of them work this way.

So yes, I think this is too complex for too little gain.

> isn't it likely
> that those who implement variables will also implement regex?

Well, I for one intend to provide both, but regex will be disabled by default
and given some of the security risks I expect it will have I doubt if many
users of ours will be willing to enable it.

> >       I suggest minimum maximums of 64 variables that can each hold
> >       998 characters.

> while there is a tradition for 998 characters as a maximum line
> length, I think it is very low for this application.  remember that
> some people may want to put longish vacation messages inside
> variables.  I suggest 30000 characters (not octets) and an even
> hundred variables as minimum.

Well, it isn't clear to me that we want to encourage storing massive texts in
variables. I think the preferred approach is to use variables to store smallish
substitutions into larger texts.

Philosophy aside, I'm more concerned about limits on the all-digit variables
since they come into being automatically than I am on the limits on explicitly
specified variables. I could tolerate having a large limit on variables in
general as long as a smaller limit could apply to all-digit variables. Although
come to think of it, the base specification allows considerable leeway on
implementation limits, so I guess I could consider limits on :matches as an
implementation limit allowed by the base specification.

> >   (3) The draft needs to make it clear that ${} constructs are not
> >       interpreted in a special way inside of strings unless the
> >       "variables" extension is listed in a require clause.

> not sure what you want here.  either a clarification in the
> introduction like:

>    This is an extension to the Sieve language defined by [SIEVE].  It
>    adds support for storing and referencing data in string variables.
> +  The mechanisms detailed in this document will only apply to Sieve
> +  scripts which include a require clause for the "variables"
> +  extension.

This is what I meant.

> or, do you want to outlaw making a different extension which is
> mutually incompatible with "variables"?  is that even possible to do
> without updating the base specification?

No, nothing like that. I suppose it is possible for two extensions to
be incompatible in some way, but that's a bridge we can cross if we ever
come to it.

> >   (5) Other than we decide on something and stick with it, I have no
> >       preference for modifier ordering.

> let's stick to prefixing (function call like), then.

WFM, although there have been some other objections here...

> >   (6) The selection of specific lowercasing or uppercasing rules for
> >       lower: and upper: needs to be done by specifying a
> >       comparator. Comparators have implement case conversion
> >       rules. Chris Newman has a new draft that cleans up the
> >       situation surrounding the comparator registry but it isn't out
> >       as an I-D yet.

> interesting.  do you know where I can get a copy?  I wonder how to
> cram this into the modifier syntax, though.  perhaps the current
> approach is completely wrong.  rather than stick modifiers inside the
> strings, we could make them modify the SET action.  it seems a better
> fit to fit other elements of Sieve (both syntax and semantics).

A copy was posted to the imapext list on 26-Feb. Hopefully Chris will
be able to post an updated version to the I-D directory soon.

>     SET :upper :comparator "i;ascii-casemap" name "${1}"

I like this a lot better than the present modifier syntax. You do need to
specify the combining rules for :upper/:lower/:upperfirst/:lowerfirst. I think
the rule should be that :upper and :lower are incompatiblei with each and so
are :upperfirst and :lowerfirst. And if :Xfirst is specified along with :Y, :Y
is done prior to :Xfirst.

> "i;ascii-casemap" would be the default comparator for SET.  I'm not
> sure what the meaning of using "i;ascii-numeric" or "i;octet" with SET
> should be.  they may make more sense if other modifiers are added in
> the future.

They would represent an identity case mapping I guess. I believe Chris plans to
deal with this issue in his document.

> >   (7) The setdate operator accept a "time zone" argument. And this is
> >       exactly what it should take. However, what's currently
> >       specified is a time offset, not a time zone -- the former is
> >       something like -0800 while the latter is something like
> >       "US/Pacific". Unfortunately the IETF does not presently have a
> >       time zone rules registry. This has been a problem for some
> >       time and I don't see it changing any time soon.

> what would it take to get it changed?  it seems to me they could just
> take (a subset of) the Olson database and decree it as official.

The problem is that the Olson database is constantly being changed and updated,
which means any snapshot you take has a good chance of being at odds with
reality in fairly short order. (A political rather than technical base tends to
do this... I understand that there are 1-2 updates every month or so.) So
absent the wherewithall to basically have IANA act as a handler for the Olson
effort or something similar, I see serious problems here.

> >       I suggest that the correct approach to take is the one RFC
> >       2445 uses. I would also like to allow a time offset as an
> >       argument to setdate, but zone support is what's needed.

> interesting, thanks for the reference.  do you mean to include the
> whole vocabulary to define a time zone?  that seems very complex to
> me.

You can simply refer to it. No need to repeat it.

> one pragmatic approach is to allow "well-known" time zones with a
> fallback offset value supplied by the user:

>   setdate "US-Eastern" "-0500"

> to allow the user to discover that the time zone was unknown, a
> variable called "timezone" would be set to the value actually used.
> there should be a note that if IETF establishes a registry for time
> zones, the values in it SHOULD be used.  if no fallback value is
> specified, use the server's default.

> actually, with ${timezone} available, the fallback can be implemented
> by the user.  we simply need to mandate that the time offset syntax is
> supported as a valid "time zone".

>     setdate "US-Eastern";
>     if not string "${timezone}" "US-Eastern" {
>         setdate "-0500";
>     }

Interesting. I could go with this.

> >   (8) The default zone for setdate should probably be the zone local
> >       to the server. I think this makes a lot more sense than GMT.

> the objection to that was that a Sieve script should behave the same
> way even if it was moved to a server in a different time zone.  e.g.,
> imagine a local ISP in the UK being swallowed up by a pan-European ISP
> which centralises all email servers in Brussels.  that must lead to
> breakage for customers.

Then by all means make the zone one that's local to the user rather than to the
server. I really don't think having a default of UTC is the right answer here.

> >   (9) The specification of setdate needs to state that every setdate
> >       in a given script operates on a single, consistent date/time
> >       value that does not change throughout the execution of the
> >       script.

> agreed.  how about this?

>     These variables SHOULD reference the time when execution of the
>     Sieve script reaches the statement.
> +   The result of all calls to setdate MUST refer to the same point in
> +   time.

Works for me.

> >   (10) I had been planning to write up a specification for currentdate
> >        and date tests. The former would allow testing of current
> >        date information while the latter would be similar to the
> >        address test except it would operate on fields containing
> >        date information.
> >    [...]
> >    setdate "+0200"                     if currentdate :year :is "2003"
> >    if string :is "${year}" "2003"        ...
> >      ...

> the currentdate syntax is obviously easier to read in tests.

Yes, but harder to deal with in actions. I don't feel comfortable trying to
predict whether actions are going to be more common than tests.

> >        I'm inclined to go with setdate at this point, mostly because
> >        the setdate syntax seems simpler to use overall.

> it allows general use without an IF and SET for every value needed,
> yeah.

Exactly.

> >        My one remaining concern is that setdate doesn't match up
> >        well with the obvious syntax the date test needs to have.

> what date tests are needed?  Sieve is quite expressive already.  an
> example:

>   require [ "variables", "vacation", "relational" ];
>   setdate "+0200";
>   if string :value "le" "${year}-${month}-${day}" "2003-09-18" {
>         vacation "I'm on my holidays, I'll be back on Sept. 19th";
>   }

Date would test date values in headers. There are all sorts of those, and
there is considerable value in being able to test them.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HG4JM002447 for <[e-mail]>; Tue, 8 Apr 2003 10:16:04 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38HG4Sf002446 for ietf-mta-filters-bks; Tue, 8 Apr 2003 10:16:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38HG2JM002441 for <[e-mail]>; Tue, 8 Apr 2003 10:16:03 -0700 (PDT)
Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h38HG1df011329; Tue, 8 Apr 2003 13:16:01 -0400
Date: Tue, 8 Apr 2003 13:16:01 -0400
Message-Id: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.3
To: [e-mail], Kjetil Torgrim Homme <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h38HG3JM002442
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>

   From: Kjetil Torgrim Homme <[e-mail]>
   Date: 08 Apr 2003 06:27:05 +0200

   >   * Syntactic structure
   >   
   >   The "set" action doesn't fit into the Sieve grammar, as something
   >   that is identical to an "identifier" is not a valid argument.

   I don't understand what you mean here.

>From RFC 3028, section 8.2:

   command = identifier arguments ( ";" / block )

   argument = string-list / number / tag

   arguments = *argument [test / test-list]

Your "set" action is implicitly extending 'argument' to allow for
something that is lexically identical to an 'identifier'. This
extension needs to be made explicit.

You then have to resolve the parsing ambiguity, since

set variable "string";

can be produced by 

command -> identifier arguments ; 
        -> identifier *argument ;
        -> identifier variable *argument ;
        -> identifier variable string-list *argument ;
        -> identifier variable string *argument ;
        -> identifier variable string ;

OR

command -> identifier arguments ;
        -> identifier *argument test ;
        -> identifier test ;
        -> identifier identifier arguments ;
        -> identifier identifier *argument ;
        -> identifier identifier string-list *argument ;
        -> identifier identifier string *argument ;
        -> identifier identifier string ;

which are obviously two different parse trees.

   >   Global scope is a wonderful choice that years of programming
   >   language theory has shown to be an extremely bad thing.
   >   
   >   When Sieve scripts are run in serial (as many implementations now
   >   allow) do variables carry over from one to another? Why or why
   >   not?

   does require carry over?  I'd say "no".  variables shouldn't either.

It's not clear to me. Nor is it clear that sites won't want to have
variables cascade.

[ ... explanations elided ... ]

I'm not convinced that Sieve-with-variables is a simple enough
language to explain without the use of formal semantics. I will
attempt to find a simple reference to post to the list.

Larry




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38H3FJM001921 for <[e-mail]>; Tue, 8 Apr 2003 10:03:15 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38H3Epm001920 for ietf-mta-filters-bks; Tue, 8 Apr 2003 10:03:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38H3DJM001910 for <[e-mail]>; Tue, 8 Apr 2003 10:03:13 -0700 (PDT)
Received: from maillennium.att.com ([135.25.114.99]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h38H39ii014894 for <[e-mail]>; Tue, 8 Apr 2003 13:03:09 -0400 (EDT)
Received: from att.com (unknown[135.210.27.119](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20030408170211gw100nj1ode> (Authid: tony); Tue, 8 Apr 2003 17:02:12 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Apr 2003 13:02:42 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]>	<[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>

Kjetil Torgrim Homme wrote:
>>  Question:
>>  
>>  Should the date variables ALWAYS be preset without executing the
>>  setdate command?
> 
> no.  you may consider the setdate action a different kind of
> "require".  the intent is that other actions can be added later to set
> variables, without breaking compatibility since the user has to call
> the action(s) explicitly.  (if setdate was an extension, we would have
> no way of specifying timezone, so there is good reason to make it an
> action.)
> 
>>  Other languages have benefitted from namespaces. It might be
>>  worthwhile exploring that concept, particularly if there are
>>  preset variables. For example, instead of the preset variable name
>>  ${year}, you'd instead have ${time.year}. Thoughts?
> 
> how should the namespace namespace be governed?  a registry?  only
> available to extensions specified in RFCs?

If setdate is comparable to a "require", then defining such an addition 
should define the namespace that it places its data into. Perhaps it 
should  be ${setdate.year}, ${setdate.month}, etc. More complex packages 
  might want to use more fully qualified names:

	require "example";
	setfoo ...;
	setbar ...;

	${example.foo.handle}
	${example.bar.contenttype}

to make certain that they don't conflict with the "foo" and "bar" 
namespaces of other "require" constructs.

Whoever defines a "require" extension that sets variables somehow would 
be responsible for defining the corresponding namespace used by its 
variables' names.

	Tony Hansen
	[e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38GmIJM001198 for <[e-mail]>; Tue, 8 Apr 2003 09:48:18 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38GmI4K001197 for ietf-mta-filters-bks; Tue, 8 Apr 2003 09:48:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38GmGJM001193 for <[e-mail]>; Tue, 8 Apr 2003 09:48:17 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 192wG5-0005Bs-00 for [e-mail]; Tue, 8 Apr 2003 18:47:41 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Tue, 8 Apr 2003 18:47:41 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 08 Apr 2003 18:47:41 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 29
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>

[Ned Freed]:
>
>   > or how about "*a*"?
>   
>   ${1} - String before the last a
>   ${2} - String after the last a.

while this is easy to explain and understand, my original suggestion
was

   ${1} - String before the last a
   ${2} - "a"
   ${3} - String after the last a.

which I now realise may have merit when matching two lists against
eachother or when using the anyof test.

   if header :matches [ "To", "Cc" ] [ "foo@*.no", "bar@*.com" ] {
        redirect "kjetilho+${1}ifi.uio.no";
   }

the match order for [ a, b ] [ A, B ] should be aA, bA, aB, bB.  this
means that messages sent to both addresses will be forwarded to
<[e-mail]>, i.e. the first match string has precedence.
in this example, what the wildcard matches is irrelevant.

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38GTHJM000509 for <[e-mail]>; Tue, 8 Apr 2003 09:29:17 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38GTHPX000508 for ietf-mta-filters-bks; Tue, 8 Apr 2003 09:29:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38GTFJM000504 for <[e-mail]>; Tue, 8 Apr 2003 09:29:16 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 192vyB-0004ke-00 for [e-mail]; Tue, 8 Apr 2003 18:29:11 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Tue, 8 Apr 2003 18:29:10 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 08 Apr 2003 18:29:10 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 47
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>

[Tony Hansen]:
>
>   Kjetil Torgrim Homme wrote:
>   >     setdate "US-Eastern";
>   >     if not string "${timezone}" "US-Eastern" {
>   >         setdate "-0500";
>   >     }
>   
>   Isn't "X/Y", as in "US/Eastern", the accepted format for compound
>   timezone names?

yes, that is the name used in Unix.  however, in the iCalendar
standard (2445) examples they use a dash.  reading more closely, they
do say

|      Note: This document does not define a naming convention for
|      time zone identifiers. Implementers may want to use the naming
|      conventions defined in existing time zone specifications such
|      as the public-domain Olson database [TZ]. The specification of
|      globally unique time zone identifiers is not addressed by this
|      document and is left for future study.

so going with the slash is probably better.  thanks.

>   Question:
>   
>   Should the date variables ALWAYS be preset without executing the
>   setdate command?

no.  you may consider the setdate action a different kind of
"require".  the intent is that other actions can be added later to set
variables, without breaking compatibility since the user has to call
the action(s) explicitly.  (if setdate was an extension, we would have
no way of specifying timezone, so there is good reason to make it an
action.)

>   Other languages have benefitted from namespaces. It might be
>   worthwhile exploring that concept, particularly if there are
>   preset variables. For example, instead of the preset variable name
>   ${year}, you'd instead have ${time.year}. Thoughts?

how should the namespace namespace be governed?  a registry?  only
available to extensions specified in RFCs?

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38E1iJM019340 for <[e-mail]>; Tue, 8 Apr 2003 07:01:44 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38E1iGA019339 for ietf-mta-filters-bks; Tue, 8 Apr 2003 07:01:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38E1gJM019333 for <[e-mail]>; Tue, 8 Apr 2003 07:01:42 -0700 (PDT)
Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h38E1bKN003697 for <[e-mail]>; Tue, 8 Apr 2003 09:01:37 -0500 (CDT)
Received: from att.com (unknown[135.210.112.5](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20030408140040gw100nj1kae> (Authid: tony); Tue, 8 Apr 2003 14:00:40 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Apr 2003 10:01:06 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
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>

Tony Hansen wrote:
> 
> Question:
> 
> Should the date variables ALWAYS be preset without executing the setdate 
> command?

Let me expand on this a bit. The idea was that the purpose of setdate 
changes to simply resetting the values to a different timezone. If you 
don't execute the setdate command, then the variables get preset to a 
value based on UTC.

     Tony Hansen
     [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38DbvJM017516 for <[e-mail]>; Tue, 8 Apr 2003 06:37:57 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38DbvNs017515 for ietf-mta-filters-bks; Tue, 8 Apr 2003 06:37:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38DbtJM017511 for <[e-mail]>; Tue, 8 Apr 2003 06:37:55 -0700 (PDT)
Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h38DbjKN018414 for <[e-mail]>; Tue, 8 Apr 2003 08:37:50 -0500 (CDT)
Received: from att.com (unknown[135.210.112.5](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20030408133648gw100nj0sme> (Authid: tony); Tue, 8 Apr 2003 13:36:48 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Apr 2003 09:37:21 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[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>

Kjetil Torgrim Homme wrote:
> [[e-mail]]:
> 
> actually, with ${timezone} available, the fallback can be implemented
> by the user.  we simply need to mandate that the time offset syntax is
> supported as a valid "time zone".
> 
>     setdate "US-Eastern";
>     if not string "${timezone}" "US-Eastern" {
>         setdate "-0500";
>     }

Isn't "X/Y", as in "US/Eastern", the accepted format for compound 
timezone names?


Question:

Should the date variables ALWAYS be preset without executing the setdate 
command?

Other languages have benefitted from namespaces. It might be worthwhile 
exploring that concept, particularly if there are preset variables. For 
example, instead of the preset variable name ${year}, you'd instead have 
${time.year}. Thoughts?

	Tony Hansen
	[e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3897BJM024777 for <[e-mail]>; Tue, 8 Apr 2003 02:07:11 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3897BSE024776 for ietf-mta-filters-bks; Tue, 8 Apr 2003 02:07:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mout0.freenet.de ([e-mail] [194.97.50.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38979JM024771 for <[e-mail]>; Tue, 8 Apr 2003 02:07:09 -0700 (PDT)
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with asmtp (Exim 4.14) id 192p4H-0006gG-J4 for [e-mail]; Tue, 08 Apr 2003 11:07:01 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with smtp (Exim 4.14 #2) id 192p4H-0005pE-GV for [e-mail]; Tue, 08 Apr 2003 11:07:01 +0200
Received: (qmail 7306 invoked by uid 100); 8 Apr 2003 09:07:01 -0000
Date: 8 Apr 2003 09:07:01 -0000
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: Matching NUL characters
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>

> >   o MIME decoding may not be implemented and everything is (legally)
> >     treated as literal, although implementing it is a strong SHOULD.
> >     If not implemented, comparison works unless 8-bit characters are
> >     encountered.
>
> no, MIME decoding is required.

It is not, because decoding etc. in section 2.7.2 is only a SHOULD and
followed by:

   If implementations fail to support the above behavior, they MUST
   conform to the following:

      No two strings can be considered equal if one contains octets
      greater than 127.

So it is not *required*, but it's not clear what is required.  That's
subject to interpretation.

> >   o  Broken words are treated as literal strings (MUAs either do that or
> >      decode them to junk, when their parser fails)
>
> words that doesn't match the grammer are treated as literals.  how to
> treat words that broken for other reasons is specified in RFC 2047
> section 6.

I see the following in section 6:

   A mail reader need not attempt to display the text associated with an
   'encoded-word' that is incorrectly formed.  However, a mail reader
   MUST NOT prevent the display or handling of a message because an
   'encoded-word' is incorrectly formed.

So what is sieve supposed to do with incorrect words and where is that
defined?

   If the mail reader does not support the character set used, it may
   (a) display the 'encoded-word' as ordinary text (i.e., as it appears
   in the header), (b) make a "best effort" to display using such
   characters as are available, or (c) substitute an appropriate message
   indicating that the decoded text could not be displayed.

That's fine for a human interface, but an automated filter should
have a determined behaviour.

> >   o  Correct words with unknown character sets are treated as literal
> >      strings.  The assumption that all unknown character sets are
> >      one-byte codes and identical to US-ASCII in their lower 128
> >      octets is not sound.
>
> remember that you can only compare against literal UTF-8 strings
> (well, at least until we have a variables extension), so the
> alternative is to make _all_ matches against strings in an unknown
> character set fail.  that is not very useful.

The alternative is not to decode and convert what can't be decoded
and converted.  If the word is broken, or the character set is unknown,
then don't decode and convert it.

> >   Rationale: I would like the following test to be true:
> >   
> >      Subject: abc =?iso-8859-1?q?=c3abc?= =?unknown?q?def?=
> >   
> >      header : contains ["Subject"] ["abc"]
> >   
> >   The header can not be decoded entirely, so Sieve scripts should
> >   view it as the UTF-8 character for capital A with diaresis,
> >   followed by "abc" and "=?unknown?q??=".
> >   
> >   RFC 3028 would let the test fail, because the _whole_ header could
> >   not be converted and there is an 8-bit character.
>
> actually, this isn't clear in the RFC.  the string "abc" doesn't
> contain 8-bit characters, and neither does the matching substring
> "abc"...  I think the RFC can be read either way.  I favour that the
> test is allowed to fail, though.

I favour well determined behaviour.

Concerning my original point of NUL characters, I read RFC 2047 again:

   Only printable and white space character data should be encoded using
   this scheme.  However, since these encoding schemes allow the
   encoding of arbitrary octet values, mail readers that implement this
   decoding should also ensure that display of the decoded data on the
   recipient's terminal will not cause unwanted side-effects.

First, the requirement of printable and white space character data is
a SHOULD.  Second, an embedded NUL causing a string to be truncated,
is an "unwanted side-effect" to me, but I have to accept it's only a
SHOULD, too.

This can probably be interpreted in sieve implementations failing to
match the substring "def" in "=?iso-8859-1?q?abc=00def?=" to be correct.
Amazing, isn't it?

Again, I favour well determined behaviour.  All those SHOULDs make it
very hard to implement Sieve, which is not helpful.  Converting some to
MUSTs would make is much easier.

Michael


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h384R9JM017963 for <[e-mail]>; Mon, 7 Apr 2003 21:27:09 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h384R96F017962 for ietf-mta-filters-bks; Mon, 7 Apr 2003 21:27:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h384R7JM017958 for <[e-mail]>; Mon, 7 Apr 2003 21:27:08 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 192khO-00025s-00 for [e-mail]; Tue, 8 Apr 2003 06:27:06 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Tue, 8 Apr 2003 06:27:06 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 08 Apr 2003 06:27:05 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 148
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>

[Lawrence Greenfield]:
>
>   More problems:
>   
>   * Semantics
>   
>   >    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.
>   
>   This is central to the semantics of the language; this isn't a
>   SHOULD.

the wording isn't good, I welcome help.  the intent was to allow
static analysis to optimise variable references away.  perhaps an
"as-if" rule is understood, so changing the SHOULD into a MUST is a
non-problem.

>   It should also be made clear that variables are expanded once, not
>   repeatedly.

good point.

    When the string is evaluated, substrings matching variable-ref shall
    be replaced by the value of variable-name.
+   Only one pass through the string shall be done.

one of the examples ("${dollar}{beep}") demonstrates this.

>   * Syntactic structure
>   
>   The "set" action doesn't fit into the Sieve grammar, as something
>   that is identical to an "identifier" is not a valid argument.

I don't understand what you mean here.

>   Global scope is a wonderful choice that years of programming
>   language theory has shown to be an extremely bad thing.
>   
>   When Sieve scripts are run in serial (as many implementations now
>   allow) do variables carry over from one to another? Why or why
>   not?

does require carry over?  I'd say "no".  variables shouldn't either.

>   If and when people start thinking about includes and functions,
>   scope becomes even more important.

let's address that when the need arises.  for now, consider SET to
implicitly declare the variable to have file scope.  add LOCAL or a
generic DECLARE action if you want them.  I think they are overkill
for Sieve, but we'll see.

>   * Numeric variables
>   
>   When does the side effect of tests have it's effect on numeric
>   variables? After the test? Only inside the if?

after the test.

as it happens, I just rewrote that part of the spec to cater for
:matches as well as :regex.  here's the new text:

3.2 Numeric variables

   The decimal value of the numeric variable name will index the list of
   matching strings from the most recently evaluated match of type
   ":matches" or ":regex".  The list is empty if the match was
   unsuccessful.

   For ":matches", the list will contain one string for each wildcard in
   the match pattern.  Each string holds what the corresponding wildcard
   expands to, possibly the empty string.  The wildcards expand
   greedily.

   For ":regex", the list will contain the strings corresponding to
   the group operators.  The groups are ordered by the position of the
   opening parenthesis, from left to right.

   The first string in the list has index 1.  If the index is out of
   range, the empty string will be substituted.  Index 0 returns the
   number of strings in the list.

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

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

        # this is equivalent to the above:
        if header :matches "List-ID" "<*@" {
             fileinto "lists.${1}"; stop;
        }

        if header :matches [ "To", "Cc" ] "coyote@**.com" {
             # ${0} is always "2", and ${2} is always the empty string.
             fileinto "business.${1}"; stop;
        } else {
             # ${0} is always "0"
             stop;
        }

=== excerpt ends ===

>   Does the ${1} in the second test refer to the variable set in the
>   first test? Or does it refer to the previously set variable?
>   
>   if (allof (header :regex "Foo" "${1}(.*)", header :regex "Bar"
>   "${1}(.*)")) {
>   }

it refers to the variable set in the first test.

>   * Numeric variables
>   
>   What does nested grouping do?
>   
>   header :regex "Foo" "((a|b))*"?

the traditional thing, see above.

>   * Numeric variables
>   
>   Does a failed matching clear all numeric variables?

yes.

>   * Program analysis
>   
>   I guess some of what's bothering me is that there are several
>   invasive language changes with this draft that make it
>   significantly more difficult to analyze the language to make sure
>   it isn't mutually contradictory, and more difficult to analyze a
>   piece of a program without global analysis.
>   
>   . Tests now alter global state (thus the short-circuit problem)
>   
>   . Variable expansion can drastically change patterns to match
>   against, preventing certain pre-compilation strategies.

there is no doubt optimisation becomes harder, but in the end system
efficiency could improve since some long Sieve scripts now can be
expressed much more compactly.

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h383OuJM016547 for <[e-mail]>; Mon, 7 Apr 2003 20:24:56 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h383OuB0016546 for ietf-mta-filters-bks; Mon, 7 Apr 2003 20:24:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h383OsJM016542 for <[e-mail]>; Mon, 7 Apr 2003 20:24:54 -0700 (PDT)
Received: from majormajor.rem.cmu.edu (LEG-C600.REM.cmu.edu [128.2.4.198]) (user=leg mech=GSSAPI (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h383Otdg007924 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 7 Apr 2003 23:24:55 -0400
Date: Mon, 07 Apr 2003 23:24:50 -0400
From: Lawrence Greenfield <[e-mail]>
To: [e-mail]
cc: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
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>

More problems:

* Semantics

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

This is central to the semantics of the language; this isn't a SHOULD.

It should also be made clear that variables are expanded once, not 
repeatedly.

* Syntactic structure

The "set" action doesn't fit into the Sieve grammar, as something that is 
identical to an "identifier" is not a valid argument.

* Scope

--On Monday, April 07, 2003 2:39 PM -0700 [e-mail] wrote:

> As for scope, I think global scope is the right, and indeed the only
> realistic, choice.

Global scope is a wonderful choice that years of programming language 
theory has shown to be an extremely bad thing.

When Sieve scripts are run in serial (as many implementations now allow) do 
variables carry over from one to another? Why or why not?

If and when people start thinking about includes and functions, scope 
becomes even more important.

* Numeric variables

When does the side effect of tests have it's effect on numeric variables? 
After the test? Only inside the if?

Does the ${1} in the second test refer to the variable set in the first 
test? Or does it refer to the previously set variable?

if (allof (header :regex "Foo" "${1}(.*)", header :regex "Bar" "${1}(.*)")) 
{
}

* Numeric variables

What does nested grouping do?

header :regex "Foo" "((a|b))*"?

* Numeric variables

Does a failed matching clear all numeric variables?

* Program analysis

I guess some of what's bothering me is that there are several invasive 
language changes with this draft that make it significantly more difficult 
to analyze the language to make sure it isn't mutually contradictory, and 
more difficult to analyze a piece of a program without global analysis.

. Tests now alter global state (thus the short-circuit problem)

. Variable expansion can drastically change patterns to match against, 
preventing certain pre-compilation strategies.

Larry



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h382IEJM013081 for <[e-mail]>; Mon, 7 Apr 2003 19:18:14 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h382IEpt013080 for ietf-mta-filters-bks; Mon, 7 Apr 2003 19:18:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h382IDJM013074 for <[e-mail]>; Mon, 7 Apr 2003 19:18:13 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 192igd-0006ZM-00 for [e-mail]; Tue, 8 Apr 2003 04:18:11 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Tue, 8 Apr 2003 04:18:11 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 08 Apr 2003 04:18:10 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 57
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>

[Ned Freed]:
>
>   [Lawrence Greenfield]:
>   > can no longer short circut due to:
>   >
>   > "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."
>   
>   I don't think that was the intent, and if it was, I think it
>   should be changed. I read "latest" as meaning "the latest
>   operation that was performed.

yes.  I've changed it to "most recently evaluated match".

>   Big mistake IMO. Short circuit rules should still apply. The base
>   specification recommends short circuit evaluation of lists. This
>   should be changed to a requirement when variables are in use.

short circuit is fine, but:

    if header :matches [ "To", "Cc" ] [ "coyote@*.com", "*@*.com" ] {
         ...
    }

which tests are done first?  if we care about effiency, it is best to
do all tests against the same match expression first.

   "To" :matches "coyote@*.com"
   "Cc" :matches "coyote@*.com"
   "To" :matches "*@*.com"
   "Cc" :matches "*@*.com"

this seems intuitively correct, since the first list contains
"synonomous" headers for the purpose of the match.  it also gives
natural precedence to the order of the match strings (most important
first).

>   > Modifiers should be omitted from this specification. These are
>   > functions; if we're going to define functions, fine. If not, fine.
>   
>   I have no problem with this approach either.

since folder names are case sensitive, a method for normalising input
into all lower case or similar is highly desirable.

>   Given that variable names are explicitly limited to ASCII
>   alphanumeric I fail to see an issue on this point. As for scope, I
>   think global scope is the right, and indeed the only realistic,
>   choice.

if the need ever arises, we can define a action (say, "LOCAL") to set
variables with block scope.  I don't intend to turn Sieve into a
general purpose programming language, so I'll leave it out for now :-)

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h380GFJM007290 for <[e-mail]>; Mon, 7 Apr 2003 17:16:15 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h380GFLO007289 for ietf-mta-filters-bks; Mon, 7 Apr 2003 17:16:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h380G8JM007270 for <[e-mail]>; Mon, 7 Apr 2003 17:16:09 -0700 (PDT)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 192gmQ-0000tL-00 for [e-mail]; Tue, 8 Apr 2003 02:16:02 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Tue, 8 Apr 2003 02:09:26 +0200
To: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 08 Apr 2003 02:07:18 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 201
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>

[[e-mail]]:
>
>   I have just finished implementing this draft. Nice work -- It was
>   considerably easier to do than I expected.

thank you.

>   (1) The ${0}, ${1} all-digit variables should be set and modified by the
>       glob-style :matches mechanism in addition to :regex. It really should
>       not be necessary to implement regex in order to get the ability to
>       set variables based on message inputs. For example:
>   
>       require ["variables", "envelope", "subaddress"];
>       if allof(envelope :all :is "from" "a@b",
>                envelope :detail :matches "to" "*")
>         redirect "d+${1}@e"
>   
>       Of course glob style patterns don't have the ability to
>       specify which wildcard characters capture and which do not,
>       but I really don't this this will be a problem in practice.

your example shows that it is possible to do useful things with it, at
least.

it is possible to add, though.  one method is to split the match
string on the meta characters.  consider the string "*@*.com" -- we
split this in four, "*", "@", "*" and ".com".  ${2} and ${4} will
always be "@" and ".com" (if there's a match), but ${1} and ${3} will
contain the matching characters.

does this sound too complicated for too little gain?  isn't it likely
that those who implement variables will also implement regex?

>       The presence of "variables" in the require list should be
>       sufficient to enable setting of the all-digit variables by
>       :matches.

I agree.

>   (2) Implementations should be able to impose limits on the total
>       number of variables as well as the size of any particular
>       variable.

good catch!

>       I suggest minimum maximums of 64 variables that can each hold
>       998 characters.

while there is a tradition for 998 characters as a maximum line
length, I think it is very low for this application.  remember that
some people may want to put longish vacation messages inside
variables.  I suggest 30000 characters (not octets) and an even
hundred variables as minimum.

>   (3) The draft needs to make it clear that ${} constructs are not
>       interpreted in a special way inside of strings unless the
>       "variables" extension is listed in a require clause.

not sure what you want here.  either a clarification in the
introduction like:

   This is an extension to the Sieve language defined by [SIEVE].  It
   adds support for storing and referencing data in string variables.
+  The mechanisms detailed in this document will only apply to Sieve
+  scripts which include a require clause for the "variables"
+  extension.

or, do you want to outlaw making a different extension which is
mutually incompatible with "variables"?  is that even possible to do
without updating the base specification?

>   (4) There's a comment to the effect that fileinto needs to be
>       extended to create folders if they don't already exist. As far
>       as I can tell the specification of fileinto in RFC 3028 is
>       silent on the folder creation issue. Our implementation
>       certainly allows folder creation by fileinto; I suspect others
>       do as well. But regardless, I think this is a matter that
>       needs to be clarified in the base sieve specification; I don't
>       think it calls for a separate extension.

okay.  clearly independent of "variables", anyhow.

>   (5) Other than we decide on something and stick with it, I have no
>       preference for modifier ordering.

let's stick to prefixing (function call like), then.

>   (6) The selection of specific lowercasing or uppercasing rules for
>       lower: and upper: needs to be done by specifying a
>       comparator. Comparators have implement case conversion
>       rules. Chris Newman has a new draft that cleans up the
>       situation surrounding the comparator registry but it isn't out
>       as an I-D yet.

interesting.  do you know where I can get a copy?  I wonder how to
cram this into the modifier syntax, though.  perhaps the current
approach is completely wrong.  rather than stick modifiers inside the
strings, we could make them modify the SET action.  it seems a better
fit to fit other elements of Sieve (both syntax and semantics).

    SET :upper :comparator "i;ascii-casemap" name "${1}"

"i;ascii-casemap" would be the default comparator for SET.  I'm not
sure what the meaning of using "i;ascii-numeric" or "i;octet" with SET
should be.  they may make more sense if other modifiers are added in
the future.

sorry, I should have thought of that approach earlier.

>   (7) The setdate operator accept a "time zone" argument. And this is
>       exactly what it should take. However, what's currently
>       specified is a time offset, not a time zone -- the former is
>       something like -0800 while the latter is something like
>       "US/Pacific". Unfortunately the IETF does not presently have a
>       time zone rules registry. This has been a problem for some
>       time and I don't see it changing any time soon.

what would it take to get it changed?  it seems to me they could just
take (a subset of) the Olson database and decree it as official.

>       I suggest that the correct approach to take is the one RFC
>       2445 uses. I would also like to allow a time offset as an
>       argument to setdate, but zone support is what's needed.

interesting, thanks for the reference.  do you mean to include the
whole vocabulary to define a time zone?  that seems very complex to
me.

one pragmatic approach is to allow "well-known" time zones with a
fallback offset value supplied by the user:

  setdate "US-Eastern" "-0500"

to allow the user to discover that the time zone was unknown, a
variable called "timezone" would be set to the value actually used.
there should be a note that if IETF establishes a registry for time
zones, the values in it SHOULD be used.  if no fallback value is
specified, use the server's default.

actually, with ${timezone} available, the fallback can be implemented
by the user.  we simply need to mandate that the time offset syntax is
supported as a valid "time zone".

    setdate "US-Eastern";
    if not string "${timezone}" "US-Eastern" {
        setdate "-0500";
    }

>   (8) The default zone for setdate should probably be the zone local
>       to the server. I think this makes a lot more sense than GMT.

the objection to that was that a Sieve script should behave the same
way even if it was moved to a server in a different time zone.  e.g.,
imagine a local ISP in the UK being swallowed up by a pan-European ISP
which centralises all email servers in Brussels.  that must lead to
breakage for customers.

>   (9) The specification of setdate needs to state that every setdate
>       in a given script operates on a single, consistent date/time
>       value that does not change throughout the execution of the
>       script.

agreed.  how about this?

    These variables SHOULD reference the time when execution of the
    Sieve script reaches the statement.
+   The result of all calls to setdate MUST refer to the same point in
+   time.

>   (10) I had been planning to write up a specification for currentdate
>        and date tests. The former would allow testing of current
>        date information while the latter would be similar to the
>        address test except it would operate on fields containing
>        date information.
>    [...]
>    setdate "+0200"                     if currentdate :year :is "2003"
>    if string :is "${year}" "2003"        ...
>      ...

the currentdate syntax is obviously easier to read in tests.

>        I'm inclined to go with setdate at this point, mostly because
>        the setdate syntax seems simpler to use overall.

it allows general use without an IF and SET for every value needed,
yeah.

>        My one remaining concern is that setdate doesn't match up
>        well with the obvious syntax the date test needs to have.

what date tests are needed?  Sieve is quite expressive already.  an
example:

  require [ "variables", "vacation", "relational" ];
  setdate "+0200";
  if string :value "le" "${year}-${month}-${day}" "2003-09-18" {
        vacation "I'm on my holidays, I'll be back on Sept. 19th";
  }

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37MDrJM024088 for <[e-mail]>; Mon, 7 Apr 2003 15:13:53 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37MDrJW024087 for ietf-mta-filters-bks; Mon, 7 Apr 2003 15:13:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37MDmJM024056 for <[e-mail]>; Mon, 7 Apr 2003 15:13:51 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 07 Apr 2003 15:13:38 -0700 (PDT)
Date: Mon, 07 Apr 2003 14:39:06 -0700 (PDT)
From: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-reply-to: "Your message dated Mon, 07 Apr 2003 17:08:53 -0400" <[e-mail]>
To: Lawrence Greenfield <[e-mail]>
Cc: Kjetil Torgrim Homme <[e-mail]>, [e-mail], [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>

>    (1) The ${0}, ${1} all-digit variables should be set and modified by the
>        glob-style :matches mechanism in addition to :regex. It really should
>        not be necessary to implement regex in order to get the ability to
>        set variables based on message inputs. For example:

> This leads to ambiguity, however.

Good point, but it is an ambiguity that is easily resolved simply by saying
glob patterns have to implement greedy matching when variables are used.

> What does:

> envelope :detail :matches "to" "**"

${1} - full detail field
${2} - empty string

> or how about "*a*"?

${1} - String before the last a
${2} - String after the last a.

> do? Is it greedy?

AFAIK 3028 didn't say, so the variables document should say that greedy matching
is to be employed.

> Also, this draft might be a little surprising to implementors since
> something like:

>            if header :regex "List-ID" ["<alpha(.*)@", "(.*)beta@"] {
>              fileinto "lists.${1}"; stop;
>            }

> can no longer short circut due to:

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

I don't think that was the intent, and if it was, I think it should be
changed. I read "latest" as meaning "the latest operation that was performed.
So if you have

	    if header :matches "subject" "*a*" ...
	    if header :matches "subject" "*b*" ...

where the subject contains both an "a" and a "b" the values of ${0}, ${1}, ...
would be set by the "*b*" pattern.

> So _all_ regular expressions have to be tried and the last of the
> matches causes the binding.

Big mistake IMO. Short circuit rules should still apply. The base specification
recommends short circuit evaluation of lists. This should be changed to a
requirement when variables are in use. The same is also true of anyof. (Allof
doesn't matter as far as I can tell.)

>    (5) Other than we decide on something and stick with it, I have no
>        preference for modifier ordering.

> Modifiers should be omitted from this specification. These are
> functions; if we're going to define functions, fine. If not, fine.

I have no problem with this approach either.

> There are many other problems with this draft, ranging from i18n
> concerns: "Variable names are case insensitive." to ones that will
> potentially significant problems later on ("All variables have global
> scope.").

Given that variable names are explicitly limited to ASCII alphanumeric I fail
to see an issue on this point. As for scope, I think global scope is the right,
and indeed the only realistic, choice.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37L8uJM010705 for <[e-mail]>; Mon, 7 Apr 2003 14:08:56 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37L8u52010704 for ietf-mta-filters-bks; Mon, 7 Apr 2003 14:08:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37L8sJM010692 for <[e-mail]>; Mon, 7 Apr 2003 14:08:54 -0700 (PDT)
Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h37L8rrg028639; Mon, 7 Apr 2003 17:08:53 -0400
Date: Mon, 7 Apr 2003 17:08:53 -0400
Message-Id: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.3
To: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
References: <[e-mail]>
User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
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>

   Date: Sun, 06 Apr 2003 07:09:40 -0700 (PDT)
   From: [e-mail]

   (1) The ${0}, ${1} all-digit variables should be set and modified by the
       glob-style :matches mechanism in addition to :regex. It really should
       not be necessary to implement regex in order to get the ability to
       set variables based on message inputs. For example:

This leads to ambiguity, however.

What does:

envelope :detail :matches "to" "**"
or how about "*a*"?

do? Is it greedy?

Also, this draft might be a little surprising to implementors since
something like:

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

can no longer short circut due to:

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

So _all_ regular expressions have to be tried and the last of the
matches causes the binding.

   (5) Other than we decide on something and stick with it, I have no
       preference for modifier ordering.

Modifiers should be omitted from this specification. These are
functions; if we're going to define functions, fine. If not, fine.

There are many other problems with this draft, ranging from i18n
concerns: "Variable names are case insensitive." to ones that will
potentially significant problems later on ("All variables have global
scope.").

Larry



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37JOpJM015459 for <[e-mail]>; Mon, 7 Apr 2003 12:24:51 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37JOp9h015458 for ietf-mta-filters-bks; Mon, 7 Apr 2003 12:24:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37JOkJM015438 for <[e-mail]>; Mon, 7 Apr 2003 12:24:49 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 07 Apr 2003 12:24:40 -0700 (PDT)
Date: Sun, 06 Apr 2003 07:09:40 -0700 (PDT)
From: [e-mail]
Subject: Re: variables draft (draft-homme-sieve-variables-00.txt)
In-reply-to: "Your message dated Sat, 22 Mar 2003 01:59:38 +0100" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail], [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>

I have just finished implementing this draft. Nice work -- It was considerably
easier to do than I expected.

Of course I now have a number of comments:

(1) The ${0}, ${1} all-digit variables should be set and modified by the
    glob-style :matches mechanism in addition to :regex. It really should
    not be necessary to implement regex in order to get the ability to
    set variables based on message inputs. For example:

    require ["variables", "envelope", "subaddress"];
    if allof(envelope :all :is "from" "a@b",
             envelope :detail :matches "to" "*")
      redirect "d+${1}@e"

    Of course glob style patterns don't have the ability to specify
    which wildcard characters capture and which do not, but I really don't
    this this will be a problem in practice.

    The presence of "variables" in the require list should be sufficient
    to enable setting of the all-digit variables by :matches.

(2) Implementations should be able to impose limits on the total number of
    variables as well as the size of any particular variable. With such
    limits it is easy to write scripts that consume an unreasonable amount
    of space:

    require "variables";
    set a "aaaaaaaaaa";
    set a "${a}${a}${a}${a}${a}${a}${a}${a}${a}${a}";
    set a "${a}${a}${a}${a}${a}${a}${a}${a}${a}${a}";
    set a "${a}${a}${a}${a}${a}${a}${a}${a}${a}${a}";
    set a "${a}${a}${a}${a}${a}${a}${a}${a}${a}${a}";
    ...

    That's already 100000 characters, with no end in sight.

    I suggest minimum maximums of 64 variables that can each hold 998
    characters.

(3) The draft needs to make it clear that ${} constructs are not interpreted
    in a special way inside of strings unless the "variables" extension is
    listed in a require clause.

(4) There's a comment to the effect that fileinto needs to be extended to
    create folders if they don't already exist. As far as I can tell the
    specification of fileinto in RFC 3028 is silent on the folder creation
    issue. Our implementation certainly allows folder creation by fileinto;
    I suspect others do as well. But regardless, I think this is a matter
    that needs to be clarified in the base sieve specification; I don't think
    it calls for a separate extension.

(5) Other than we decide on something and stick with it, I have no preference
    for modifier ordering.

(6) The selection of specific lowercasing or uppercasing rules for lower: and
    upper: needs to be done by specifying a comparator. Comparators have
    implement case conversion rules. Chris Newman has a new draft that
    cleans up the situation surrounding the comparator registry but it isn't
    out as an I-D yet.

(7) The setdate operator accept a "time zone" argument. And this is exactly
    what it should take. However, what's currently specified is a time offset,
    not a time zone -- the former is something like -0800 while the latter is
    something like "US/Pacific". Unfortunately the IETF does not presently have
    a time zone rules registry. This has been a problem for some time and
    I don't see it changing any time soon. I suggest that the correct
    approach to take is the one RFC 2445 uses. I would also like to allow
    a time offset as an argument to setdate, but zone support is what's needed.

(8) The default zone for setdate should probably be the zone local to the
    server. I think this makes a lot more sense than GMT.

(9) The specification of setdate needs to state that every setdate in a
    given script operates on a single, consistent date/time value that does not
    change throughout the execution of the script. If you don't do this you
    can get some unpleasant boundary cases. Note that it is entirely
    reasonable to use setdate multiple times in a single script, either
    because of automated script construction or else because someone
    wants the current date in different time offsets.

(10) I had been planning to write up a specification for currentdate and date
     tests. The former would allow testing of current date information while
     the latter would be similar to the address test except it would operate on
     fields containing date information.

     Setdate and currentdate provide equivalent functionality: Setdate combined
     with the string test give you the ability to test current date information
     while currentdate combined with :matches and the set action give you the
     ability to get date information into the variable of your choice. Of course
     each one is better syntax-wise at doing what it is directly designed to
     do:

    setdate "+0200"                     if currentdate :year :matches "*"
    fileinto "${year}-${month}"           set year "${1}"
                                        if currentdate :month :matches "*"
                                          set month "${1}"
                                        fileinto "${year}-${month}"

    setdate "+0200"                     if currentdate :year :is "2003"
    if string :is "${year}" "2003"        ...
      ...

     I'm inclined to go with setdate at this point, mostly because the
     setdate syntax seems simpler to use overall. My one remaining concern
     is that setdate doesn't match up well with the obvious syntax the
     date test needs to have. So I'd appreciate feedback from others on this
     point.

That's enough for now. As I said at the beginning, I think this is very good
document and I hope we can advance it sooner rather than later.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37EvEJM006803 for <[e-mail]>; Mon, 7 Apr 2003 07:57:14 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37EvESg006802 for ietf-mta-filters-bks; Mon, 7 Apr 2003 07:57:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mail.epost.de (mail.epost.de [193.28.100.164] (may be forged)) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37EvCJM006789 for <[e-mail]>; Mon, 7 Apr 2003 07:57:13 -0700 (PDT)
Received: from dhcp200.hq (212.95.126.10) by mail.epost.de (6.7.015) (authenticated as [e-mail]) id 3E8BDB240005AD80 for [e-mail]; Mon, 7 Apr 2003 16:57:11 +0200
From: Marc Mutz <[e-mail]>
Organization: "Old Europe" - and proud
To: [e-mail]
Subject: Re: Proposed MANAGESIEVE changes
Date: Mon, 7 Apr 2003 16:23:57 +0200
User-Agent: KMail/1.5.9
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_/nYk+JxIcTkQPQO"; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[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>

--Boundary-02=_/nYk+JxIcTkQPQO
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Sunday 06 April 2003 15:42, Ken Murchison wrote:
<snip>
> No, we _want_ AUTHID.  AUTHID is the authentication identifier, NOT
> and authentication mechanism name.
<snip>

You mean authid like in what some sasl mechnisms support beside the=20
userid? Hmm, is there another URL scheme that uses ;AUTHID=3D for that?

In any case, I think ;AUTH=3D should be added, too, since it's quite=20
standard in URL schemes in the IMAP/mail realm: ACAP, IMAP, POP3 all=20
use it. Having both will also point out that they're describing=20
different things.

Marc

=2D-=20
We notice things that don't work. We don't notice things that do.
We notice computers, we don't notice pennies.
We notice e-book readers, we don't notice books.
                                          -- Douglas Adams

--Boundary-02=_/nYk+JxIcTkQPQO
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+kYn+3oWD+L2/6DgRAgdkAJ9oxVoB2bTrpoqj98FBBoJo3Lib8QCfSaVE
VjO1RLXfgpX3Wgssn0EkayY=
=OD9q
-----END PGP SIGNATURE-----

--Boundary-02=_/nYk+JxIcTkQPQO--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h36DhEJM006136 for <[e-mail]>; Sun, 6 Apr 2003 06:43:14 -0700 (PDT)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h36DhE5J006135 for ietf-mta-filters-bks; Sun, 6 Apr 2003 06:43:14 -0700 (PDT)
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 h36DhDJM006131 for <[e-mail]>; Sun, 6 Apr 2003 06:43:13 -0700 (PDT)
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 h36Dh2TO003075 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Sun, 6 Apr 2003 09:43:06 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sun, 06 Apr 2003 09:42:31 -0400
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: Proposed MANAGESIEVE changes
References: <[e-mail]> <[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>

Marc Mutz wrote:
> 
> On Saturday 05 April 2003 15:40, Ken Murchison wrote:
> <snip>
> > > authinfo = userid [ ";AUTHID=" authid ]
> > Sure.  No complaints here.
> <snip>
> 
> Please follow rfc2192, rfc2384 and probably others that have something
> like
> 
> authinfo = userid [ ";AUTH=" authid ]
> authid = "*" / sasl-authid
> sasl-authid = any mechanism identifier registered for SASL
> 
> (the point is about AUTH vs. AUTHID).

No, we _want_ AUTHID.  AUTHID is the authentication identifier, NOT and
authentication mechanism name.

-- 
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 h35G8BJM019197 for <[e-mail]>; Sat, 5 Apr 2003 08:08:11 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35G8Bj6019196 for ietf-mta-filters-bks; Sat, 5 Apr 2003 08:08:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35G89JM019192 for <[e-mail]>; Sat, 5 Apr 2003 08:08:10 -0800 (PST)
Received: from dirichlet.Physik.Uni-Bielefeld.DE (dirichlet.Physik.Uni-Bielefeld.DE [129.70.125.234]) by max.kde.org (Postfix) with ESMTP id A6F2EB385D for <[e-mail]>; Sat,  5 Apr 2003 18:08:09 +0200 (CEST)
From: Marc Mutz <[e-mail]>
Organization: "Old Europe" - and proud
To: [e-mail]
Subject: Re: Proposed MANAGESIEVE changes
Date: Sat, 5 Apr 2003 17:39:40 +0200
User-Agent: KMail/1.5.9
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Sjvj+nTiR1unf2l"; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[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>

--Boundary-02=_Sjvj+nTiR1unf2l
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Saturday 05 April 2003 15:40, Ken Murchison wrote:
<snip>
> > authinfo =3D userid [ ";AUTHID=3D" authid ]
> Sure.  No complaints here.
<snip>

Please follow rfc2192, rfc2384 and probably others that have something=20
like

authinfo =3D userid [ ";AUTH=3D" authid ]
authid =3D "*" / sasl-authid
sasl-authid =3D any mechanism identifier registered for SASL

(the point is about AUTH vs. AUTHID).

Marc

=2D-=20
Ich gegen meinen Bruder.
Ich und mein Bruder gegen unseren Cousin.
Ich, mein Bruder und unser Cousin gegen unsere Nachbarn.
Wir alle gegen den Fremden.
                                      -- Beduinen-Sprichwort

--Boundary-02=_Sjvj+nTiR1unf2l
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+jvjS3oWD+L2/6DgRAtm6AKC6kgm+/oF/QTejJ2ihh8fIvGd2YgCgueRF
lF4JvLWk2xMVf5pF5DKBrKE=
=FC75
-----END PGP SIGNATURE-----

--Boundary-02=_Sjvj+nTiR1unf2l--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35DejJM009681 for <[e-mail]>; Sat, 5 Apr 2003 05:40:45 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h35DejJg009680 for ietf-mta-filters-bks; Sat, 5 Apr 2003 05:40:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h35DehJM009672 for <[e-mail]>; Sat, 5 Apr 2003 05:40:43 -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 h35DeRTO007693 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Sat, 5 Apr 2003 08:40:37 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sat, 05 Apr 2003 08:40:23 -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: Proposed MANAGESIEVE changes
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>

Chris Newman wrote:
> 
> begin  quotation by Ken Murchison on 2003/4/1 14:35 -0500:
> 
> > 2. Based on Cyrus Murder/virtdomains work, Rob Siemborski and I propose
> > the following augmented Sieve URL grammar:
> >
> >
> > sieveurl = "sieve://" [ [ authinfo "@" ] hostport ] "/" scriptname
> >
> > authinfo = authid [ ";" userid ]
> >
> > authid = userid = *( unreserved | escaped |
> >                      ":" | "&" | "=" | "+" | "$" | "," )
> >
> > scriptname = *pchar
> 
> Please try to keep the authinfo syntax compatible with RFC 2192 authinfo.
> 
> I suggest instead:
> 
> authinfo = userid [ ";AUTHID=" authid ]


Sure.  No complaints here.

-- 
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 h354EpJM022278 for <[e-mail]>; Fri, 4 Apr 2003 20:14:51 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h354EpJx022277 for ietf-mta-filters-bks; Fri, 4 Apr 2003 20:14:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h354EoJM022272 for <[e-mail]>; Fri, 4 Apr 2003 20:14:50 -0800 (PST)
Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA27869 for <[e-mail]>; Fri, 4 Apr 2003 21:14:54 -0700 (MST)
Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 04 Apr 2003 21:12:38 -0700 (MST)
Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 04 Apr 2003 21:12:37 -0700 (MST)
Date: Fri, 04 Apr 2003 20:11:16 -0800
From: Chris Newman <[e-mail]>
Subject: Re: Matching NUL characters
In-reply-to: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.3 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-message-flag: Outlook: the best virus distribution system around
References: <[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>

Anyone who uses a NUL of any flavor in this context deserves to lose. 
Implementations should be free to drop the NUL or truncate the line at a NUL, 
regardless of whether it is encoded.

RFC 2822 deprecated the NUL character, and I think we can and should deprecate 
an encoded NUL when RFC 2047 is revised -- one of the important steps moving 
forward on the standards track is to deprecate features that aren't useful and 
cause interoperability problems.  Encoded NUL certainly meets that test.

So I am opposed to adding _any_ additional complexity to Sieve in order to 
support NUL.

                - Chris

begin  quotation by [e-mail] on 2003/4/3 21:58 +0000:
> as defined by RFC 3028, Sieve scripts may not contain NUL characters.
> MIME encoded headers may contain them (encoded), though, and there is
> currently no way to match them with Sieve.  For that reason I suggest
> to change paragraph 2.4.2 of the RFC to define \0 being a representation
> of the NUL character.
>
> I know, that's quite a change, but it's quite a bug, too. ;-) Btw, both
> Mutt and Outlook Express don't show anything after a MIME encoded NUL
> characters, so they simply decode it and, given C strings, terminate the
> string that way, because nobody ever thought about how to handle them.
> If a sieve implementation is not subject to this bug, then most likely
> it could support \0 pretty easy.  Otherwise some work is required anyway
> to fix the bug.
>
> While extending the meaning of \, I suggest to use the Java \u notation
> to specify unicode characters.  Sieve scripts are written in UTF-8 for
> good reasons, but being able to use non-ASCII characters without having
> to use UTF-8 would be great.  That's just an idea, though, and not really
> required like \0 is.
>
> I am currently writing my own sieve implementation as extension to Exim.
> Hacking MIME decoding, I discovered the problem above and Tim Showalter
> suggested I join the list.  It's not the first issue I had with the RFC
> so far, but the first that asks for a change in the language.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3545rJM021807 for <[e-mail]>; Fri, 4 Apr 2003 20:05:53 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3545qrg021806 for ietf-mta-filters-bks; Fri, 4 Apr 2003 20:05:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3545qJM021802 for <[e-mail]>; Fri, 4 Apr 2003 20:05:52 -0800 (PST)
Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA24642 for <[e-mail]>; Fri, 4 Apr 2003 21:05:55 -0700 (MST)
Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 04 Apr 2003 21:05:55 -0700 (MST)
Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 04 Apr 2003 21:05:54 -0700 (MST)
Date: Fri, 04 Apr 2003 20:04:37 -0800
From: Chris Newman <[e-mail]>
Subject: Re: Proposed MANAGESIEVE changes
In-reply-to: <[e-mail]>
To: Ken Murchison <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.3 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-message-flag: Outlook: the best virus distribution system around
References: <[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>

begin  quotation by Ken Murchison on 2003/4/1 14:35 -0500:

> 2. Based on Cyrus Murder/virtdomains work, Rob Siemborski and I propose
> the following augmented Sieve URL grammar:
>
>
> sieveurl = "sieve://" [ [ authinfo "@" ] hostport ] "/" scriptname
>
> authinfo = authid [ ";" userid ]
>
> authid = userid = *( unreserved | escaped |
>                      ":" | "&" | "=" | "+" | "$" | "," )
>
> scriptname = *pchar

Please try to keep the authinfo syntax compatible with RFC 2192 authinfo.

I suggest instead:

authinfo = userid [ ";AUTHID=" authid ]

                - Chris



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h351AnJM013760 for <[e-mail]>; Fri, 4 Apr 2003 17:10:49 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h351An0I013759 for ietf-mta-filters-bks; Fri, 4 Apr 2003 17:10:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h351AhJM013742 for <[e-mail]>; Fri, 4 Apr 2003 17:10:43 -0800 (PST)
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by pat.uio.no with esmtp (Exim 2.12 #7) id 191cCj-0000OX-00 for [e-mail]; Sat, 5 Apr 2003 03:10:45 +0200
Received: (from kjetilho@localhost) by vingodur.ifi.uio.no ; Sat, 5 Apr 2003 03:10:45 +0200
To: [e-mail]
Subject: Re: Matching NUL characters
References: <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 05 Apr 2003 03:10:45 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 82
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>

[[e-mail]]:
>
>   > I'm not sure about that.  I wasn't here when the draft was discussed,
>   > but it seems to me "Implementations decode header charsets to UTF-8"
>   > is as normative as a MUST.  "Implementations should decode charsets
>   > ..." is a cop-out since it is _very_ hard to support every charset in
>   > existence.  the list of required charsets is therefore listed
>   > explicitly instead.
>   
>   That may have been the intention, but there should be no room for
>   interpretation, so let's fix it.  I see three issues:
>   
>   o  Must MIME decoding of correct words succeed?
>   o  How are broken words treated?

this is specified in RFC 2047.

>   o  How are unknown character sets treated?

this is specified in the Sieve RFC.

>   The current RFC says, although not in a way that is overly clear,
>   and which may not even reflect the intention when it was written:
>   
>   o MIME decoding may not be implemented and everything is (legally)
>     treated as literal, although implementing it is a strong SHOULD.
>     If not implemented, comparison works unless 8-bit characters are
>     encountered.

no, MIME decoding is required.

>   o  Behaviour for broken words is not specified.

RFC 2047.

>   o  Unknown character sets are not converted, but assumed to be the
>      one-byte code US-ASCII.  Comparison fails if 8-bit characters are
>      encountered.

yes.

>   You don't seem to agree with that, and neither do I, so I suggest:
>   
>   o  MIME decoding MUST be implemented.
>   o  Broken words are treated as literal strings (MUAs either do that or
>      decode them to junk, when their parser fails)

words that doesn't match the grammer are treated as literals.  how to
treat words that broken for other reasons is specified in RFC 2047
section 6.

>   o  Correct words with unknown character sets are treated as literal
>      strings.  The assumption that all unknown character sets are
>      one-byte codes and identical to US-ASCII in their lower 128
>      octets is not sound.

remember that you can only compare against literal UTF-8 strings
(well, at least until we have a variables extension), so the
alternative is to make _all_ matches against strings in an unknown
character set fail.  that is not very useful.

>   Rationale: I would like the following test to be true:
>   
>      Subject: abc =?iso-8859-1?q?=c3abc?= =?unknown?q?def?=
>   
>      header : contains ["Subject"] ["abc"]
>   
>   The header can not be decoded entirely, so Sieve scripts should
>   view it as the UTF-8 character for capital A with diaresis,
>   followed by "abc" and "=?unknown?q??=".
>   
>   RFC 3028 would let the test fail, because the _whole_ header could
>   not be converted and there is an 8-bit character.

actually, this isn't clear in the RFC.  the string "abc" doesn't
contain 8-bit characters, and neither does the matching substring
"abc"...  I think the RFC can be read either way.  I favour that the
test is allowed to fail, though.

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h350CLJM011263 for <[e-mail]>; Fri, 4 Apr 2003 16:12:21 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h350CLST011262 for ietf-mta-filters-bks; Fri, 4 Apr 2003 16:12:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h350CFJM011253 for <[e-mail]>; Fri, 4 Apr 2003 16:12:19 -0800 (PST)
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h350CHal014747 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Fri, 4 Apr 2003 16:12:17 -0800 (PST)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h350AuTY008615; Fri, 4 Apr 2003 16:12:17 -0800
Received: by jutta.sendmail.com (Postfix, from userid 500) id A6B231799B; Fri,  4 Apr 2003 16:10:03 -0800 (PST)
Date: Fri, 4 Apr 2003 16:10:03 -0800
From: Jutta Degener <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Last Call: Sieve -- Subaddress Extension - NUL
Message-ID: <[e-mail]>
References: <[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.3.24i
X-Filtered: Sendmail MIME Filter v2.3.1 foon.sendmail.com h350AuTY008615
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 Fri, Apr 04, 2003 at 08:39:55AM -0000, [e-mail] wrote:
> 
> > Michael, I believe that we are not talking about the same thing, and 
> > there's nothing to worry about, and no change to the RFC needed.
> 
> I think you misunderstood me.  I just jumped into the list and I am
> talking about how to match this:
> 
>   Subject: =?iso-8859-1?q?=00text?=
> 
> Sieve can't do that right now other than by using a pattern match.

I'm not convinced sieve needs to address this.

>From RFC 2047, section 5, use of encoded-words in message headers:

#  Only printable and white space character data should be encoded using
#  this scheme.  However, since these encoding schemes allow the
#  encoding of arbitrary octet values, mail readers that implement this
#  decoding should also ensure that display of the decoded data on the
#  recipient's terminal will not cause unwanted side-effects.
#
#  Use of these methods to encode non-textual data (e.g., pictures or
#  sounds) is not defined by this memo. [...]

I'd conclude that by using RFC 2047 to encode NUL bytes, you're
sending bogus data.  (It isn't printable or white space.)

I don't think the sieve language needs to be extended to address
the specific details of bogosity, no more than it should be extended
to deal with e.g. octet sequences that don't occur in UTF-8 at all,
yet could be encoded in a header.

Sieve has made a deliberate design choice to deal with pieces of
text as logical UTF-8 strings (and not as physical sequences of
octets).  I think you're unhappy with that design choice, but I
don't think you've identified a flaw in its implementation.

--

While we're talking about binary data:

Over lunch at the last IETF, I got the sense that people wanted
a way of executing binary comparisons on MIME part contents, mainly
to roll their own virus checking (in spite of the overlap
with a "virustest" command).

I said then that I'd like to have a "hex" comparator that can
compare binary strings as part of the "body" command.  Due to
the fact that sieve works with UTF-8 strings, that just didn't
work out as a comparator in the sense of "i;octet"; instead, the
next version of "body" will have a new :binary match-type,
a version of "content" that works in the hex domain.

Here's what that text looks like so far:

| 4.4 Body Transform ":binary"
| 
|    If the body transform is ":binary", the rules for selecting MIME
|    body parts for matching are the same as with the ":content"
|    body transform.
| 
|    MIME parts encoded in "quoted-printable" or "base64" content
|    transfer encodings MUST be decoded prior to the match.
|    MIME parts in other transfer encodings MAY be decoded, omitted
|    from the test, or processed as raw data.
| 
|    Unlike in :content, the charset of the :binary MIME content is
|    disregarded.   Instead, the match against the keys provided in
|    the "body" statement proceeds as if the file's content data had
|    been translated into space-separated hex bytes of the form
|    [0-9a-f][0-9a-f] prior to matching.
| 
|    Search expressions MUST NOT match across MIME part boundaries.
|    MIME headers of the containing text MUST NOT be included in the
|    data.
| 
|    If the optional ":offset <start: number>" is provided, the
|    binary match is executed after skipping <number> octets of
|    the binary data.  (Note that the offset counts bytes of the
|    internal data, not characters of the hexadecimal representation.)
| 
|    Example:
|    	require ["body", "fileinto"];
| 
| 	# Save any message with any application MIME part that contains
| 	# an ascii C string representation of "Hello, World!" into the
| 	# "helloworld" folder. 
| 	
| 	if body :binary ["application"]
| 		:contains "48 65 6c 6c 6f 2c 20 57 6f 72 6c 64 21 00"
| 	{
| 		fileinto "helloworld";
| 		stop;
| 	}
| 
| 	# Check if the bytes at offsets 1000...1003 match some fictitious
| 	# signature 44, 3c, 0, 1; if yes, reject the message.
| 
| 	if body :binary ["application"] :offset 1000 :matches "44 3c 00 01 *"
| 	{
| 		reject "example virus detected";
| 		stop;
| 	}

Originally, I didn't have spaces between the hex values, but
that meant that "c2" would match in "0c20" unless I made up a
new strictly pairwise comparator as well -- and some things are
just too clumsy to describe.  Besides, I think it actually looks
better this way.

There was also no mention of :offset over lunch, and it may be
that I'm going too far and should leave that to :regex instead;
but it did seem common enough to warrant an explicit mechanism.

Jutta Degener <[e-mail]>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34DC9JM001408 for <[e-mail]>; Fri, 4 Apr 2003 05:12:09 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34DC98v001407 for ietf-mta-filters-bks; Fri, 4 Apr 2003 05:12:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34DC8JM001398 for <[e-mail]>; Fri, 4 Apr 2003 05:12:08 -0800 (PST)
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with asmtp (Exim 4.14) id 191QzI-0003Vo-D7 for [e-mail]; Fri, 04 Apr 2003 15:12:08 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with smtp (Exim 4.14 #2) id 191QzI-0005xd-6q for [e-mail]; Fri, 04 Apr 2003 15:12:08 +0200
Received: (qmail 2977 invoked by uid 100); 4 Apr 2003 13:12:08 -0000
Date: 4 Apr 2003 13:12:08 -0000
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: Matching NUL characters
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'm not sure about that.  I wasn't here when the draft was discussed,
> but it seems to me "Implementations decode header charsets to UTF-8"
> is as normative as a MUST.  "Implementations should decode charsets
> ..." is a cop-out since it is _very_ hard to support every charset in
> existence.  the list of required charsets is therefore listed
> explicitly instead.

That may have been the intention, but there should be no room for
interpretation, so let's fix it.  I see three issues:

o  Must MIME decoding of correct words succeed?
o  How are broken words treated?
o  How are unknown character sets treated?

The current RFC says, although not in a way that is overly clear, and
which may not even reflect the intention when it was written:

o  MIME decoding may not be implemented and everything is (legally) treated
   as literal, although implementing it is a strong SHOULD.  If not
   implemented, comparison works unless 8-bit characters are encountered.
o  Behaviour for broken words is not specified.
o  Unknown character sets are not converted, but assumed to be the
   one-byte code US-ASCII.  Comparison fails if 8-bit characters are
   encountered.

You don't seem to agree with that, and neither do I, so I suggest:

o  MIME decoding MUST be implemented.
o  Broken words are treated as literal strings (MUAs either do that or
   decode them to junk, when their parser fails)
o  Correct words with unknown character sets are treated as literal
   strings.  The assumption that all unknown character sets are one-byte
   codes and identical to US-ASCII in their lower 128 octets is not sound.

Rationale: I would like the following test to be true:

   Subject: abc =?iso-8859-1?q?=c3abc?= =?unknown?q?def?=

   header : contains ["Subject"] ["abc"]

The header can not be decoded entirely, so Sieve scripts should view it
as the UTF-8 character for capital A with diaresis, followed by "abc"
and "=?unknown?q??=".

RFC 3028 would let the test fail, because the _whole_ header could not
be converted and there is an 8-bit character.

Michael


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34BVPJM022625 for <[e-mail]>; Fri, 4 Apr 2003 03:31:25 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34BVPNP022623 for ietf-mta-filters-bks; Fri, 4 Apr 2003 03:31:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34BVJJM022618 for <[e-mail]>; Fri, 4 Apr 2003 03:31:19 -0800 (PST)
Received: from tiu.ifi.uio.no ([129.240.65.210]) by pat.uio.no with esmtp (Exim 2.12 #7) id 191PPj-0000rO-00 for [e-mail]; Fri, 4 Apr 2003 13:31:19 +0200
Received: (from kjetilho@localhost) by tiu.ifi.uio.no ; Fri, 4 Apr 2003 13:31:18 +0200 (MEST)
To: [e-mail]
Subject: Re: Matching NUL characters
References: <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 04 Apr 2003 13:31:18 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 68
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>

[[e-mail]]:
>
>   > I don't believe this is true.  every implementation must understand
>   > that the sequence of N octets making up one UTF-8 character is _one_
>   > character, not N.
>   
>   Where would it make a difference, if the implementation could not
>   decode headers to UTF-8, which is allowed? Quoting section 2.7.2:
>   
>   ----------
>      Implementations decode header charsets to UTF-8.  Two strings are
>      considered equal if their UTF-8 representations are identical.
>      Implementations should decode charsets represented in the forms
>      specified by [MIME] for both message headers and bodies.
>      Implementations must be capable of decoding US-ASCII, ISO-8859-1,
>      the ASCII subset of ISO-8859-* character sets, and UTF-8.
>   
>   If implementations fail to support the above behavior, they MUST
>   conform to the following:
>   
>      No two strings can be considered equal if one contains octets
>      greater than 127.
>   ----------
>   
>   To me, that means an implementation could entirely forget about UTF-8.
>   If someone used a script that contains UTF-8 characters, it does not
>   make a difference but for comparisons, and those are always false if
>   the string contains UTF-8 encoding for unicode characters >127.

I'm not sure about that.  I wasn't here when the draft was discussed,
but it seems to me "Implementations decode header charsets to UTF-8"
is as normative as a MUST.  "Implementations should decode charsets
..." is a cop-out since it is _very_ hard to support every charset in
existence.  the list of required charsets is therefore listed
explicitly instead.

so the fallback rule only applies to headers containing unknown
charsets.  if the decoded header contains octets with 8th bit set, it
can never match anything.

>   Personally, I am surprised that UTF-8 aware string comparisons do
>   not require an extension, since RFC conforming Sieve implementations
>   do not absolutely have to support it.  Depending on the (conforming)
>   implementation, the following test may be true or false
>   
>      Subject: =?iso-8859-1?q?abc=80def?=
>   
>      header :contains ["Subject"] ["abc"]
>   
>   "Fail to support the above behaviour" means "fail to decode MIME words"
>   (no MIME support) or "fail to decode MIME words to UTF-8" (MIME support,
>   but no character set translation).  If the intention was different,
>   the specification should be, too.

the specification may not be completely clear, but let's not postulate
that broken behaviour is allowed if we don't have to.

btw, if you change the header to

  Subject: =?iso-8859-15?q?abc=a0def?=

the implementation can fail to decode it to UTF-8, and the fallback
rule applies.  I'm not completely sure, but I think the test MUST fail
due to the existence of U+A0 in the subject string.

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34AgdJM014857 for <[e-mail]>; Fri, 4 Apr 2003 02:42:39 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34Agdp2014856 for ietf-mta-filters-bks; Fri, 4 Apr 2003 02:42:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mout0.freenet.de ([e-mail] [194.97.50.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34AgbJM014845 for <[e-mail]>; Fri, 4 Apr 2003 02:42:37 -0800 (PST)
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with asmtp (Exim 4.14) id 191Oeb-00033q-0L for [e-mail]; Fri, 04 Apr 2003 12:42:37 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with smtp (Exim 4.14 #2) id 191Oea-0001pL-TW for [e-mail]; Fri, 04 Apr 2003 12:42:36 +0200
Received: (qmail 2879 invoked by uid 100); 4 Apr 2003 10:42:31 -0000
Date: 4 Apr 2003 10:42:31 -0000
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: Matching NUL characters
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>

> >     Subject: =?iso-8859-1?q?abc=00def?=
> >   
> >   and the tests:
> >   
> >     header :contains ["Subject"] ["abc"]
> >     header :contains ["Subject"] ["def"]
> >     header :matches ["Subject"] ["abc?def"]
> >   
> >   An implementation that evaluates the second or third test as false
> >   is broken, isn't it?
>
> granted.  good example.

Well, that means the implementation must already be able to deal with
strings containing NUL characters somewhere already.

> I don't believe this is true.  every implementation must understand
> that the sequence of N octets making up one UTF-8 character is _one_
> character, not N.

Where would it make a difference, if the implementation could not decode
headers to UTF-8, which is allowed? Quoting section 2.7.2:

----------
   Implementations decode header charsets to UTF-8.  Two strings are
   considered equal if their UTF-8 representations are identical.
   Implementations should decode charsets represented in the forms
   specified by [MIME] for both message headers and bodies.
   Implementations must be capable of decoding US-ASCII, ISO-8859-1,
   the ASCII subset of ISO-8859-* character sets, and UTF-8.

If implementations fail to support the above behavior, they MUST
conform to the following:

   No two strings can be considered equal if one contains octets
   greater than 127.
----------

To me, that means an implementation could entirely forget about UTF-8.
If someone used a script that contains UTF-8 characters, it does not
make a difference but for comparisons, and those are always false if
the string contains UTF-8 encoding for unicode characters >127.

Personally, I am surprised that UTF-8 aware string comparisons do
not require an extension, since RFC conforming Sieve implementations
do not absolutely have to support it.  Depending on the (conforming)
implementation, the following test may be true or false

   Subject: =?iso-8859-1?q?abc=80def?=

   header :contains ["Subject"] ["abc"]

"Fail to support the above behaviour" means "fail to decode MIME words"
(no MIME support) or "fail to decode MIME words to UTF-8" (MIME support,
but no character set translation).  If the intention was different,
the specification should be, too.

Michael


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h349wHJM011098 for <[e-mail]>; Fri, 4 Apr 2003 01:58:17 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h349wHI4011097 for ietf-mta-filters-bks; Fri, 4 Apr 2003 01:58:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h349wFJM011088 for <[e-mail]>; Fri, 4 Apr 2003 01:58:16 -0800 (PST)
Received: from tiu.ifi.uio.no ([129.240.65.210]) by pat.uio.no with esmtp (Exim 2.12 #7) id 191Nxe-00055w-00 for [e-mail]; Fri, 4 Apr 2003 11:58:14 +0200
Received: (from kjetilho@localhost) by tiu.ifi.uio.no ; Fri, 4 Apr 2003 11:58:14 +0200 (MEST)
To: [e-mail]
Subject: Re: Matching NUL characters
References: <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 04 Apr 2003 11:58:14 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 48
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>

[[e-mail]]:
>
>   > I suggest you propose an extension.  an implementation that follows
>   > the current RFC should not be rendered incompatible.
>   
>   I thought about an extension, too, but what should be the result
>   of the following two matches (as specified by the RFC) given
>   those comparisons, if we have the header
>   
>     Subject: =?iso-8859-1?q?abc=00def?=
>   
>   and the tests:
>   
>     header :contains ["Subject"] ["abc"]
>     header :contains ["Subject"] ["def"]
>     header :matches ["Subject"] ["abc?def"]
>   
>   An implementation that evaluates the second or third test as false
>   is broken, isn't it?

granted.  good example.

>   > if you want the "\0" escape, you can't express U+ef followed by zero.
>   >
>   >   \uef\0 => U+ef NUL
>   >
>   > "\u0" is so short "\0" is superfluous.  the number of escapes
>   > should be kept to a minimum.
>   
>   Not entirely.  RFC 3028 allows not to implement UTF-8 comparisons,
>   which means the input script may be in UTF-8, but the
>   implementation is not aware of that, and it makes no sense to use
>   anything but ASCII characters in that case.

I don't believe this is true.  every implementation must understand
that the sequence of N octets making up one UTF-8 character is _one_
character, not N.

>   That allows a simple implementation and such an implementation
>   probably would not understand \u escapes, but it still requires \0
>   to encode the NUL character.

I don't agree.  and I still think that to change the backslash, you
need to make an extension.

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h348vwJM004456 for <[e-mail]>; Fri, 4 Apr 2003 00:57:58 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h348vwCN004455 for ietf-mta-filters-bks; Fri, 4 Apr 2003 00:57:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h348vvJM004451 for <[e-mail]>; Fri, 4 Apr 2003 00:57:57 -0800 (PST)
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout1.freenet.de with asmtp (Exim 4.14) id 191N1D-0003h7-Qu for [e-mail]; Fri, 04 Apr 2003 10:57:51 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx5.freenet.de with smtp (Exim 4.14 #2) id 191N1D-0008Ta-ML for [e-mail]; Fri, 04 Apr 2003 10:57:51 +0200
Received: (qmail 2583 invoked by uid 100); 4 Apr 2003 08:57:51 -0000
Date: 4 Apr 2003 08:57:51 -0000
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: Matching NUL characters
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>

> >   If a sieve implementation is not subject to this bug, then most
> >   likely it could support \0 pretty easy.  Otherwise some work is
> >   required anyway to fix the bug.
>
> I suggest you propose an extension.  an implementation that follows
> the current RFC should not be rendered incompatible.

I thought about an extension, too, but what should be the result
of the following two matches (as specified by the RFC) given
those comparisons, if we have the header

  Subject: =?iso-8859-1?q?abc=00def?=

and the tests:

  header :contains ["Subject"] ["abc"]
  header :contains ["Subject"] ["def"]
  header :matches ["Subject"] ["abc?def"]

An implementation that evaluates the second or third test as false is
broken, isn't it? To fix that, adding NUL support is required.  It
would not shed a good light onto sieve if the above tests only evaluate
as true if the scripts begins with

  require "no_NUL_bug";

And even that would require conforming implementations to artificially
introduce the bug when that extension is not selected.

> if you want the "\0" escape, you can't express U+ef followed by zero.
>
>   \uef\0 => U+ef NUL
>
> "\u0" is so short "\0" is superfluous.  the number of escapes whould
> be kept to a minimum.

Not entirely.  RFC 3028 allows not to implement UTF-8 comparisons,
which means the input script may be in UTF-8, but the implementation
is not aware of that, and it makes no sense to use anything but
ASCII characters in that case.  That allows a simple implementation
and such an implementation probably would not understand \u escapes,
but it still requires \0 to encode the NUL character.

Michael


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h348dvJM002210 for <[e-mail]>; Fri, 4 Apr 2003 00:39:57 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h348dv2Y002209 for ietf-mta-filters-bks; Fri, 4 Apr 2003 00:39:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h348dtJM002201 for <[e-mail]>; Fri, 4 Apr 2003 00:39:56 -0800 (PST)
Received: from [194.97.55.147] (helo=mx4.freenet.de) by mout2.freenet.de with asmtp (Exim 4.14) id 191Mjr-0007TY-DM for [e-mail]; Fri, 04 Apr 2003 10:39:55 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx4.freenet.de with smtp (Exim 4.14 #2) id 191Mjr-0005LD-6q for [e-mail]; Fri, 04 Apr 2003 10:39:55 +0200
Received: (qmail 2476 invoked by uid 100); 4 Apr 2003 08:39:55 -0000
Date: 4 Apr 2003 08:39:55 -0000
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: Last Call: Sieve -- Subaddress Extension - NUL
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>

> Michael, I believe that we are not talking about the same thing, and 
> there's nothing to worry about, and no change to the RFC needed.

I think you misunderstood me.  I just jumped into the list and I am
talking about how to match this:

  Subject: =?iso-8859-1?q?=00text?=

Sieve can't do that right now other than by using a pattern match.

Michael


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h348BuJM028227 for <[e-mail]>; Fri, 4 Apr 2003 00:11:56 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h348BuiK028226 for ietf-mta-filters-bks; Fri, 4 Apr 2003 00:11:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h348BsJM028213 for <[e-mail]>; Fri, 4 Apr 2003 00:11:55 -0800 (PST)
Received: from tiu.ifi.uio.no ([129.240.65.210]) by pat.uio.no with esmtp (Exim 2.12 #7) id 191MIj-00076T-00 for [e-mail]; Fri, 4 Apr 2003 10:11:53 +0200
Received: (from kjetilho@localhost) by tiu.ifi.uio.no ; Fri, 4 Apr 2003 10:11:53 +0200 (MEST)
To: [e-mail]
Subject: Re: Matching NUL characters
References: <[e-mail]>
From: Kjetil Torgrim Homme <[e-mail]>
Date: 04 Apr 2003 10:11:52 +0200
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 50
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>

[[e-mail]]:
>
>   as defined by RFC 3028, Sieve scripts may not contain NUL
>   characters.  MIME encoded headers may contain them (encoded),
>   though, and there is currently no way to match them with Sieve.
>   For that reason I suggest to change paragraph 2.4.2 of the RFC to
>   define \0 being a representation of the NUL character.
>   
>   I know, that's quite a change, but it's quite a bug, too. ;-) Btw,
>   both Mutt and Outlook Express don't show anything after a MIME
>   encoded NUL characters, so they simply decode it and, given C
>   strings, terminate the string that way, because nobody ever
>   thought about how to handle them.

since the wording is quite explicit in the Sieve standard, I'd rather
say that this was intentional.  it complicates implementation to
support the NUL character, for little benefit.

>   If a sieve implementation is not subject to this bug, then most
>   likely it could support \0 pretty easy.  Otherwise some work is
>   required anyway to fix the bug.

I suggest you propose an extension.  an implementation that follows
the current RFC should not be rendered incompatible.

>   While extending the meaning of \, I suggest to use the Java \u
>   notation to specify unicode characters.  Sieve scripts are written
>   in UTF-8 for good reasons, but being able to use non-ASCII
>   characters without having to use UTF-8 would be great.  That's
>   just an idea, though, and not really required like \0 is.

in that case I suggest an arbitrary length of hexadecimal digits,
e.g., \u0 == \u00000000.  otherwise we'll get a mess when characters
outside the basic plane are needed.  (encode to UTF-16 yourself, let
the Sieve implementation convert that to UTF-8 -- ugly!)  note that
you can terminate the hex sequence with a backslash, this never gives
ambiguity since the only escaped characters are backslash, doublequote
and "u".  e.g.,

  \u0\foo => NUL f o o
  
if you want the "\0" escape, you can't express U+ef followed by zero.

  \uef\0 => U+ef NUL

"\u0" is so short "\0" is superfluous.  the number of escapes whould
be kept to a minimum.

-- 
Kjetil T.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3411nJM028044 for <[e-mail]>; Thu, 3 Apr 2003 17:01:49 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3411nFM028043 for ietf-mta-filters-bks; Thu, 3 Apr 2003 17:01:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp.us.messagingengine.com (ny3.fastmail.fm [66.111.4.4]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3411kJM028032 for <[e-mail]>; Thu, 3 Apr 2003 17:01:48 -0800 (PST)
Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by server3.messagingengine.com (Postfix) with ESMTP id 818B05017F for <[e-mail]>; Thu,  3 Apr 2003 20:01:47 -0500 (EST)
Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by messagingengine.com with SMTP; Thu, 03 Apr 2003 20:01:46 -0500
X-Epoch: 1049418106
X-Sasl-enc: J6z/xZnrwaMCXA4ARmLFpA
Received: from elvey.fastmail.fm (adsl-64-166-23-45.dsl.snfc21.pacbell.net [64.166.23.45]) by www.fastmail.fm (Postfix) with ESMTP id CE3462F738 for <[e-mail]>; Thu,  3 Apr 2003 20:01:44 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2003 17:01:44 -0800
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: Sieve -- Subaddress Extension - NUL
References: <[e-mail]> <[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>

Alexey Melnikov wrote:

>Ken Murchison wrote:
>  
>
>>I was just asked what would happen if this extension is used on an
>>address such as:
>>
>>[e-mail]
>>
>>I'm proposing adding the following text to the draft:
>>
>>"NOTE: If the separator character occurs more than once in the
>>local-part,
>>then the address SHOULD be split at the left-most separator."
>>
>>Does this seem sufficient?  Should this be a MUST instead of a SHOULD?
>>Any other thoughts?
>>    
>>
>
>IMHO, this should be MUST and it is sufficient.
>
I concur, and since brought this all up, that means there's no 
disagreement.  :)


However, regarding Michael's NUL comment:
Michael, I believe that we are not talking about the same thing, and 
there's nothing to worry about, and no change to the RFC needed.  The 
null key ("") that I was referring to, and that the subadress extension 
refers to is the empty string.  Sematically, it's a string of 0 
characters, not a string with one character with the value 0. (Except 
that it might be stored such that it looks that way - in languages such 
as C, it might be stored as a pointer to a an array of 0 characters 
followed by the value 0.)
The NUL (ASCII 0) referred to in 2.4.2 of the RFC is a character with 
the value 0, often used in languages such as C to indicate the end of a 
string, and therefore cannot be part of a string (which is probably why 
it is forbidden by the RFC.)  You'l note that the RFC separately refers 
to the null key (""); certainly these are different things.  Cool?


Finally, I noticed that 2.7.1 of the RFC states in part:

The null key ("") is contained in all values.

That answers question 4. There's just a bug in the implementation I use; 
smooth sailing for the subaddress draft.

Therefore there IS a way to match the null key:

header :contains "Subject" ""
should return true for all mail with a Subject header, including an 
extant but empty one.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33LwBJM016714 for <[e-mail]>; Thu, 3 Apr 2003 13:58:11 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33LwA5v016713 for ietf-mta-filters-bks; Thu, 3 Apr 2003 13:58:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mout0.freenet.de ([e-mail] [194.97.50.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33Lw9JM016708 for <[e-mail]>; Thu, 3 Apr 2003 13:58:09 -0800 (PST)
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout0.freenet.de with asmtp (Exim 4.14) id 191Cik-0003yy-BB for [e-mail]; Thu, 03 Apr 2003 23:58:06 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx5.freenet.de with smtp (Exim 4.14 #2) id 191Cik-0005vf-8w for [e-mail]; Thu, 03 Apr 2003 23:58:06 +0200
Received: (qmail 2238 invoked by uid 100); 3 Apr 2003 21:58:00 -0000
Date: 3 Apr 2003 21:58:00 -0000
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Matching NUL characters
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>

Hello,

as defined by RFC 3028, Sieve scripts may not contain NUL characters.
MIME encoded headers may contain them (encoded), though, and there is
currently no way to match them with Sieve.  For that reason I suggest
to change paragraph 2.4.2 of the RFC to define \0 being a representation
of the NUL character.

I know, that's quite a change, but it's quite a bug, too. ;-) Btw, both
Mutt and Outlook Express don't show anything after a MIME encoded NUL
characters, so they simply decode it and, given C strings, terminate the
string that way, because nobody ever thought about how to handle them.
If a sieve implementation is not subject to this bug, then most likely
it could support \0 pretty easy.  Otherwise some work is required anyway
to fix the bug.

While extending the meaning of \, I suggest to use the Java \u notation
to specify unicode characters.  Sieve scripts are written in UTF-8 for
good reasons, but being able to use non-ASCII characters without having
to use UTF-8 would be great.  That's just an idea, though, and not really
required like \0 is.

I am currently writing my own sieve implementation as extension to Exim.
Hacking MIME decoding, I discovered the problem above and Tim Showalter
suggested I join the list.  It's not the first issue I had with the RFC
so far, but the first that asks for a change in the language.

Michael


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33JDpJM004611 for <[e-mail]>; Thu, 3 Apr 2003 11:13:51 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33JDpnq004610 for ietf-mta-filters-bks; Thu, 3 Apr 2003 11:13:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33JDlJM004605 for <[e-mail]>; Thu, 3 Apr 2003 11:13:50 -0800 (PST)
Received: from messagingdirect.com (dhcp198-169.esys.ca [198.161.92.169]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h33JHHV00313; Thu, 3 Apr 2003 12:17:17 -0700
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2003 12:17:12 -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: Ken Murchison <[e-mail]>
CC: [e-mail]
Subject: Re: Last Call: Sieve -- Subaddress Extension to Proposed Standard
References: <[e-mail]> <[e-mail]> <[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>

Ken Murchison wrote:

> I was just asked what would happen if this extension is used on an
> address such as:
>
> [e-mail]
>
> I'm proposing adding the following text to the draft:
>
> "NOTE: If the separator character occurs more than once in the
> local-part,
> then the address SHOULD be split at the left-most separator."
>
> Does this seem sufficient?  Should this be a MUST instead of a SHOULD?
> Any other thoughts?

IMHO, this should be MUST and it is sufficient.

Cheers,
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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33IpcJM003459 for <[e-mail]>; Thu, 3 Apr 2003 10:51:38 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33IpcuK003458 for ietf-mta-filters-bks; Thu, 3 Apr 2003 10:51:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33IpaJM003452 for <[e-mail]>; Thu, 3 Apr 2003 10:51:37 -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 h33IpXTN001883 for <[e-mail]>; Thu, 3 Apr 2003 13:51:33 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2003 13:54:26 -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]> <[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>

I was just asked what would happen if this extension is used on an
address such as:

[e-mail]


I'm proposing adding the following text to the draft:

"NOTE: If the separator character occurs more than once in the
local-part,
then the address SHOULD be split at the left-most separator."


Does this seem sufficient?  Should this be a MUST instead of a SHOULD? 
Any other thoughts?

-- 
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 h33IUhJM002672 for <[e-mail]>; Thu, 3 Apr 2003 10:30:43 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33IUhZP002671 for ietf-mta-filters-bks; Thu, 3 Apr 2003 10:30:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from smtp.us.messagingengine.com (ny3.fastmail.fm [66.111.4.4]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33IUdJM002665 for <[e-mail]>; Thu, 3 Apr 2003 10:30:42 -0800 (PST)
Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id 6166A4DDC3 for <[e-mail]>; Thu,  3 Apr 2003 13:30:39 -0500 (EST)
Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by messagingengine.com with SMTP; Thu, 03 Apr 2003 13:30:38 -0500
X-Epoch: 1049394638
X-Sasl-enc: xdMBIxIy8GUIUgB8I/ssmQ
Received: from elvey.fastmail.fm (adsl-64-166-23-45.dsl.snfc21.pacbell.net [64.166.23.45]) by www.fastmail.fm (Postfix) with ESMTP id 67B91237F1 for <[e-mail]>; Thu,  3 Apr 2003 13:30:36 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2003 10:30:36 -0800
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: Sieve -- Subaddress Extension to Proposed Standard
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>

>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
>
>  
>
Ken, looks good. 4 comments:

1)You might find FastMail's subdomain detail implementation interesting, 
as documented at
http://www.fastmail.fm/docs/faqparts/AliasesAndVirtualDomains.htm#SubDomain 
.
It meshes well with your proposed extension - this comment is just an 
FYI, not a request for any change.
It exists because many systems don't allow + in email addresses, and 
because it's cool.
By the time SIEVE sees the email, however, the address has been 
converted, so Sieve can see the canonical form that your extension 
understands:

[e-mail] ([e-mail] instead of [e-mail])
This canonical form is in the envelope to, which is (I agree) the best address to test against.

Example (trimmed) header

Received: ... for <[e-mail]>; Fri, 28 Mar 2003 17:23:09 -0500 (EST)
X-Delivered-to: <[e-mail]>
Received: ... for <[e-mail]>; Fri, 28 Mar 2003 17:23:08 -0500 (EST)
Subject: Welcome to the "wireless" mailing list
From: [e-mail]
To: [e-mail]



2)Does the spec leave undefined  how it would parse

[e-mail]?  It seems to assume only one separator character.
I suggest :user reference the "leftmost separator" and :detail reference the "rightmost separator".
That would leave detail1 unextractable by this extension however.


3)Suggested correction:
envelope :detail ["to", "cc", "bcc"] "foo"
is nonsense; envelopes don't have "cc" or "bcc"; eliminate them.


4)(Question for anyone on the list:) 
 - Apropos use of the null key ("") in this extension:
Should 

header :contains "Subject" "" 

return true for all mail with a Subject header?  
Perhaps its an implementation error , but this type| of test doesn't work on FastMail (which uses Cyrus IMAP); exists must be used.  
My reading of the spec is that this should ("MUST") work.  


Let me know what you think.  I didn't email [e-mail] or 
[e-mail]; didn't seem to make sense at this juncture.

-Matthew Elvey







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JWIJM015074 for <[e-mail]>; Tue, 1 Apr 2003 11:32:18 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31JWIOf015073 for ietf-mta-filters-bks; Tue, 1 Apr 2003 11:32:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JWHJM015064 for <[e-mail]>; Tue, 1 Apr 2003 11:32:17 -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 h31JWBTN021253 for <[e-mail]>; Tue, 1 Apr 2003 14:32:11 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 01 Apr 2003 14:35: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: [e-mail]
Subject: Proposed MANAGESIEVE changes
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>

Here are the proposed changes to MANAGESIEVE that I mentioned at IETF. 
These have been sent to and accepted by Tim Martin already:

1. Based on the fact that the server no longer auto-issues the
capabilities response (per draft -04), paragraph 3 of section 2.2 should
be changed to something like (stolen from RFC 2595):

      Once TLS has been started, the client MUST discard cached
      information about server capabilities and SHOULD re-issue the
      CAPABILITY command.  This is necessary to protect against
      man-in-the-middle attacks which alter the capabilities list prior
      to STARTTLS.  The server MAY advertise different capabilities
      after STARTTLS.


2. Based on Cyrus Murder/virtdomains work, Rob Siemborski and I propose
the following augmented Sieve URL grammar:


sieveurl = "sieve://" [ [ authinfo "@" ] hostport ] "/" scriptname

authinfo = authid [ ";" userid ]

authid = userid = *( unreserved | escaped | 
                     ":" | "&" | "=" | "+" | "$" | "," )

scriptname = *pchar


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