Subject: escapes in sieve strings

From: Philip Guenther <[email-masked]>
Date: Sun, 27 Feb 2005 22:50:13 -0800

Personally, I'm a bit mixed on the wisdom of changing the interpretation
of escapes in sieve scripts, mainly because the original spec defined
the meaning of _all_ escapes instead of only defining those that were
required ( \\ and \" ) while leaving other escapes as having undefined
behavior.  An implementation that complies with RFC 3028 cannot
simultaneously comply with a specification that requires \0 to be
treated as a NUL or \u0025 to be treated as a percent sign.

If the WG decides that breaking backwards compability on this point is
worthwhile, then I would suggest we go ahead and explicitly warn script
authors that future extensions or revisions MAY redefine other
backslash-character combinations and that scripts should therefore avoid
extraneous backslash escapes.

Also, please note that currently, backslashes are only special in quoted
strings and not in multi-line strings.  That leaves a choice of either
a) making quoted strings strictly more 'powerful' that multi-line
   strings, or
b) changing the interpretation of backslashes in multi-line strings.

Personally, I find (b) a non-starter.

Regarding the discussion around how to express NUL, I would rather
_only_ have \u and \U, so that NUL would be \u0000 (or \U00000000).  I
dislike escape sequences that are neither fixed length (like \u and \U)
nor bracketed (like perl5's \P{name}).

Philip Guenther

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Mon, 28 Feb 2005 14:26:29 +0100

> extraneous backslash escapes.

agreed.

> Personally, I find (b) a non-starter.

agreed.

> _only_ have \u and \U, so that NUL would be \u0000 (or \U00000000).

then it is impossible to express arbitrary octets, e.g., 0xFF, since
it's not a valid UTF-8 sequence.

> I dislike escape sequences that are neither fixed length (like \u and \U)

agreed.
-- 
Kjetil T.

Subject: Re: escapes in sieve strings
From: Kjetil Torgrim Homme <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: [email-masked]
Date: Mon, 28 Feb 2005 14:26:29 +0100
Sender: [email-masked]

> extraneous backslash escapes.

agreed.

> Personally, I find (b) a non-starter.

agreed.

> _only_ have \u and \U, so that NUL would be \u0000 (or \U00000000).

then it is impossible to express arbitrary octets, e.g., 0xFF, since
it's not a valid UTF-8 sequence.

> I dislike escape sequences that are neither fixed length (like \u and \U)

agreed.
-- 
Kjetil T.

To: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: escapes in sieve strings
Date: Sun, 27 Feb 2005 22:50:13 -0800
Sender: [email-masked]

Philip Guenther

Date: Wed, 23 Feb 2005 22:06:05 +0000
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: "Mark E. Mallett" <[email-masked]>, [email-masked]
Subject: Re: Sieve base-spec revision I-D
Sender: [email-masked]

Kjetil Torgrim Homme wrote:

>>I could also see a \0<alpha> sequence having extra
>>meaning, e.g. '\0xnn' for hex.  
>>
>>What would be the need for \uXXXX that a series of multiple escaped
>>bytes couldn't provide?
>>    
>>
>
>it's more convenient than having to do the UTF-8 coding yourself.  not
>that it's hard, I could even do it in my head, but it's error prone.
>
I second this.

>it also puts an additional burden on Sieve script builders, they need to
>convert back and forth before presenting the rule for the user.
>  
>

Subject: Re: Sieve base-spec revision I-D
From: Kjetil Torgrim Homme <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked]
Date: Tue, 22 Feb 2005 21:22:55 +0100
Sender: [email-masked]

On Tue, 2005-02-22 at 13:26 -0500, Mark E. Mallett wrote:
> On Wed, Feb 16, 2005 at 05:36:26AM +0100, Kjetil Torgrim Homme wrote:
> > I wish
> > there were an escape for including octets by value in strings, e.g.
> > "\x00".  that would be an incompatible change, can we do that?
> > 
> > (if so, I'd want "\uXXXX" and "\UXXXXXXXX" for Unicode, too (same syntax
> > as Java and C99))
> 
> I agree with wanting to be able to specify octets by value.  I'd hate to
> do it with a leading alpha character though, as '\x' is supposed to mean
> 'x'.  I've done it a la C escapes, with '\0nnn' meaning an octal value,
> where you only have to make '0' special, and I don't think \0 sequences
> being special would come as as much of a shock as \<alpha> sequences
> being special.

perhaps, but I don't think it makes much difference.  FWIW, I did a
quick survey of our user's Sieve scripts (a little more than 2000
scripts), and none of them had extraneous backslashes.  only one user
had (wrongly) written "\." in a regex context.

I don't like \0nnn since it is AFAIK a syntax not used in any other
language, also octal is a bit old-school :-)

(C-style \nnn for octal is problematic since it is variable width.)

> I could also see a \0<alpha> sequence having extra
> meaning, e.g. '\0xnn' for hex.  
> 
> What would be the need for \uXXXX that a series of multiple escaped
> bytes couldn't provide?

it's more convenient than having to do the UTF-8 coding yourself.  not
that it's hard, I could even do it in my head, but it's error prone.  it
also puts an additional burden on Sieve script builders, they need to
convert back and forth before presenting the rule for the user.

-- 
Kjetil T.

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 22 Feb 2005 13:26:24 -0500
To: Kjetil Torgrim Homme <[email-masked]>
Cc: Philip Guenther <[email-masked]>, [email-masked]
Subject: Re: Sieve base-spec revision I-D
Sender: [email-masked]

On Wed, Feb 16, 2005 at 05:36:26AM +0100, Kjetil Torgrim Homme wrote:
> there is a slight problem since a header can use encoding to include NUL
> and other problematic characters, and the Sieve interpreter undoes this
> in order to present it all as UTF-8 or plain octets to the user.  I wish
> there were an escape for including octets by value in strings, e.g.
> "\x00".  that would be an incompatible change, can we do that?
> 
> (if so, I'd want "\uXXXX" and "\UXXXXXXXX" for Unicode, too (same syntax
> as Java and C99))

I agree with wanting to be able to specify octets by value.  I'd hate to
do it with a leading alpha character though, as '\x' is supposed to mean
'x'.  I've done it a la C escapes, with '\0nnn' meaning an octal value,
where you only have to make '0' special, and I don't think \0 sequences
being special would come as as much of a shock as \<alpha> sequences
being special.  I could also see a \0<alpha> sequence having extra
meaning, e.g. '\0xnn' for hex.  

What would be the need for \uXXXX that a series of multiple escaped
bytes couldn't provide?

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 22 Feb 2005 13:20:31 -0500
To: Philip Guenther <[email-masked]>
Cc: [email-masked]
Subject: Re: Sieve base-spec revision I-D
Sender: [email-masked]

On Tue, Feb 15, 2005 at 04:22:52PM -0800, Philip Guenther wrote:
> 
> The other open issues on my list are:
> 
> 1) removal of the "Tests MUST NOT have side effects" restriction.
>    We must permit the behavior of the 'variables' extension; do we
>    still want to discourage side-effects in general or should the
>    last two paragraphs of section 2.5 simply be dropped?

I would either drop them, or isolate the side-effect prohibition to
the message only (i.e., may change the state of the filter, but
must not change the message).

BTW, since the intent is to make accomodation for the variables
extension, perhaps the introductory text about how variables are
not provided (two places) should be amended.

One other minor thing noted:

2.10.2.  Implicit Keep

   > An implicit keep is performed if a message is not written to a
   > mailbox, redirected to a new address, rejected, or explicitly thrown
   > out.  That is, if a fileinto, a keep, a redirect, or a discard is
   > performed, an implicit keep is not.

You've added "rejected" to the first sentence (as well as modifying
4.1), so you should probably also add "reject" to the second sentence.

(of course, this is muddled somewhat by :copy ...)

mm

Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked]
Date: Fri, 18 Feb 2005 12:57:48 +0100
Sender: [email-masked]

On Thu, 2005-02-17 at 22:39 -0500, Mark E. Mallett wrote:
> On Fri, Feb 18, 2005 at 01:10:16AM +0100, Kjetil Torgrim Homme wrote:
> > On Thu, 2005-02-17 at 18:44 -0500, Mark E. Mallett wrote:
> > 
> > > > > 4.  Action set
> > > > > 
> > > > >    > An illegal name MUST cause a syntax error.
> > > > > 
> > > > > "MUST be detected as a syntax error" ?  (at compile time?  runtime?)
>
> I guess I'm just being anal.  I think of an invalid name as being a
> syntax error rather than causing a syntax error.  That was behind "must
> be detected as a syntax error."

ah, it didn't register as suggested replacement text, I'm just blind.
fixed, thanks.
-- 
Kjetil T.

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>, "Mark E. Mallett" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Date: Fri, 18 Feb 2005 11:56:53 -0000
Sender: [email-masked]

> I agree, I can't really think of a use case for the count, so I probably
> shouldn't have included it in the first place.
> 
> > I'd rather have both, though, and providing them is really a minor thing,
> > no matter how late it is.
> 
> anyone else have an opinion?

My expectation would be that ${0} is the match.  I've never had a need for the number of parts that matched.  It was something I read in the draft though "oh that's different to what I expect" but then I didn't have a big problem with it so didn't mention it.  Indeed as already mentioned, adding another set of () is all you need if ${0} has a different meaning.

Nigel

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 17 Feb 2005 22:39:30 -0500
To: Kjetil Torgrim Homme <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Sender: [email-masked]

On Fri, Feb 18, 2005 at 01:10:16AM +0100, Kjetil Torgrim Homme wrote:
> On Thu, 2005-02-17 at 18:44 -0500, Mark E. Mallett wrote:
> 
> > > > 4.  Action set
> > > > 
> > > >    > An illegal name MUST cause a syntax error.
> > > > 
> > > > "MUST be detected as a syntax error" ?  (at compile time?  runtime?)
> >
> > Just to be clear, my main comment was about the wording "must cause a
> > syntax error" being wrong.  The parenthesised "compile time or runtime"
> > was a side comment and yeah, it's probably obvious that it's compile
> > time.
> 
> what's wrong?  you mean s/cause/handled as/ ?

I guess I'm just being anal.  I think of an invalid name as being a
syntax error rather than causing a syntax error.  That was behind "must
be detected as a syntax error."

mm

Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked]
Date: Fri, 18 Feb 2005 01:10:16 +0100
Sender: [email-masked]

On Thu, 2005-02-17 at 18:44 -0500, Mark E. Mallett wrote:
> My prediction is that something returning the entire match string will
> be much more useful than something returning the count of matches.

I agree, I can't really think of a use case for the count, so I probably
shouldn't have included it in the first place.

> I'd rather have both, though, and providing them is really a minor thing,
> no matter how late it is.

anyone else have an opinion?

>> > [${0} is the match, ${#} is the count]
> > > Or keep ${0} as the count, and add something else (e.g. ${*}) as the
> > > complete match string.

${*} (shell) or ${&} (sed, Perl), I guess.  ${0} as match corresponds to
e.g. awk.  ${:} as in Python's [:] could work, too, but is strange
without the range.  so many options ...

> > explicit is better than implicit -- users can just add an extra pair of
> > parentheses.  (this only applies to :regex.  for :matches, the match
> > string is always equal to the source string.)
> 
> Indeed it is- it's still useful to be able to access it.

you're right, that's actually awkward to do with :matches without this
feature:

   if header :matches ["To", "Cc"] ["kj*", "za*"]

the above needs to be replaced by four individual statements.  whether
that is _compelling_, I'll leave for someone else to say :-)

> > > 4.  Action set
> > > 
> > >    > An illegal name MUST cause a syntax error.
> > > 
> > > "MUST be detected as a syntax error" ?  (at compile time?  runtime?)
>
> Just to be clear, my main comment was about the wording "must cause a
> syntax error" being wrong.  The parenthesised "compile time or runtime"
> was a side comment and yeah, it's probably obvious that it's compile
> time.

what's wrong?  you mean s/cause/handled as/ ?

-- 
Kjetil T.

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 17 Feb 2005 18:44:21 -0500
To: Kjetil Torgrim Homme <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Sender: [email-masked]

[sorry, I'm slow]

On Mon, Feb 07, 2005 at 12:41:26AM +0100, Kjetil Torgrim Homme wrote:
> On Sat, 2005-02-05 at 17:01 -0500, Mark E. Mallett wrote:
> > 
> > Hmm, I glossed over this before.  There are other environments
> > (including typical regex implementations) where it's common to have
> > submatch 0 represent the entire matched string.  Access to the number of
> > strings is useful, but so is access to the entire match (probably more
> > so than the number of matches, since that's predictable from the pattern
> > used).  Since it's nice to be consistent with what people might already
> > be used to, I'd recommend having index 0 be the entire match, and something
> > else be the count of the matches.  Maybe a special ${#} for the number
> > of matches.
> 
> I think too little is gained by this change to incorporate it at this
> stage.

My prediction is that something returning the entire match string will
be much more useful than something returning the count of matches.
I'd rather have both, though, and providing them is really a minor thing,
no matter how late it is.

> > Or keep ${0} as the count, and add something else (e.g. ${*}) as the
> > complete match string.
> 
> explicit is better than implicit -- users can just add an extra pair of
> parentheses.  (this only applies to :regex.  for :matches, the match
> string is always equal to the source string.)

Indeed it is- it's still useful to be able to access it.

> > 4.  Action set
> > 
> >    > An illegal name MUST cause a syntax error.
> > 
> > "MUST be detected as a syntax error" ?  (at compile time?  runtime?)
> 
> from RFC 3028, 2.10.6:
> 
>    In any programming language, there are compile-time and run-time
>    errors.
> 
>    Compile-time errors are ones in syntax that are detectable if a
>    syntax check is done.
> 
> so compile-time.

Just to be clear, my main comment was about the wording "must cause a
syntax error" being wrong.  The parenthesised "compile time or runtime"
was a side comment and yeah, it's probably obvious that it's compile
time.

-mm-

From: "Nigel Swinson" <[email-masked]>
To: "Daniel" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Thu, 17 Feb 2005 18:06:59 -0000
Sender: [email-masked]

> RFC 2806 defines the "tel" URL scheme - is this what you are looking for?
> 
> Daniel

Yeah perfect!  Thanks Daniel!  I found RFC 3966 is the newer version of 2806, and it goes OTT for the purposes for Sieve, but if we pick selected bits of the BNF we get:
 
   telephone-subscriber = global-number / local-number
   global-number        = global-number-digits *par
   local-number         = [I'd suggest we'd not allow this]
   par                  = [I'd suggest we'd not allow this]
   global-number-digits = "+" *phonedigit DIGIT *phonedigit
   phonedigit           = DIGIT / [ visual-separator ]
   visual-separator     = "-" / "." / "(" / ")"

Then it's a fairly trivial case of binning the visual-separators and you should be left with a string of numbers prefixed with a +. :o)

Nigel

From: "Nigel Swinson" <[email-masked]>
To: "Michael Haardt" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Thu, 17 Feb 2005 17:56:06 -0000
Sender: [email-masked]

> Again, over here people pay per part.  One SMS part has a fixed cost,
> billed (mostly) to the sender.  Very long SMS contain multiple parts.
> If other telephone networks follow this model, then it makes more
> sense to let people specify the maximum number of parts allowed,
> which dirctly translates to money, cutting the message after that.
> What good is a limit of 170 characters, if 1-160 characters cost one
> unit and 161-320 cost two units? Then again, I may give a message with
> many UTF-8 characters that will be dropped when converting to IA5, so
> people won't understand why sometimes 200 characters "fit" in 170 octets.
> With parts, they indirectly say "you can spend this much money" and do
> not need to care about encoding or number of octets.

I'm in the UK so it's the same for me too.  You are detailing the exact reason why I proposed :limit being a message limit rather than a character limit (which was in the original I-Draft).  My "message" is your "part", we're gunning for the same thing.  :o)

> > If we are to offer a standard, then maybe we should just drop the "To"
> > as well, as in the vast majority of cases I'd imagine users will know
> > who the message was sent to.
> 
> Not if they have multiple mailboxes, like office and private.

So will that be more common?  With only 140 8 byte characters to play with, using up approximately 40 for what might always be the same might be quite a lot....  Ideally we'd pick a default which had no internationalisation issues, so maybe not even use the word "From"....  But perhaps the subject has no place in the draft anyway...

Nigel

Date: Thu, 17 Feb 2005 16:32:52 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Sieve-Notify and potential associative arrays.
Sender: [email-masked]

On Thu, Feb 17, 2005 at 02:43:31PM -0000, Nigel Swinson wrote:
> > So what if no number is specified, either explicit or implicit? Should
> > the action be ignored or cause the script to fail? The same question
> > arises on invalid number strings.  I vote for ignoring invalid numbers
> > and actions without any number at all.
> 
> I think if phone numbers are supplied, then the implementation SHOULD
> raise a compile error if the supplied string is not valid.

You assume that Sieve scripts are always compiled, but in fact RFC 3028
allows for them to be interpreted, too.  Invalid phone numbers are
like invalid header names in comparisons to me.  It's not specified
what happens in this case.  My implementation generates an error to
ease debugging, but does so when interpreting the script.

> Ok :o)  And if more than the limit are specified, then this would be a compile error?

Or a runtime error. :)

> The :limit parameter I was proposing was meant to apply after any
> character set encoding of the message.  I'm not familiar with IA5, I had
> hoped we could just pipe UTF8 and then truncate at some appropriate point.
> So I'm not sure in what way your proposed :parts differs to my :limit?

Again, over here people pay per part.  One SMS part has a fixed cost,
billed (mostly) to the sender.  Very long SMS contain multiple parts.
If other telephone networks follow this model, then it makes more
sense to let people specify the maximum number of parts allowed,
which dirctly translates to money, cutting the message after that.
What good is a limit of 170 characters, if 1-160 characters cost one
unit and 161-320 cost two units? Then again, I may give a message with
many UTF-8 characters that will be dropped when converting to IA5, so
people won't understand why sometimes 200 characters "fit" in 170 octets.
With parts, they indirectly say "you can spend this much money" and do
not need to care about encoding or number of octets.

> I wasn't actually proposing we standardize the default message format,
> just describing what I was going to use, but that is an interesting idea
> :o)  That could make your sieve action just:
> 
>    sms;

Yes, if you have a mailbox property that contains a phone number, but
I wouldn't make that even a SHOULD, but optional.

> If we are to offer a standard, then maybe we should just drop the "To"
> as well, as in the vast majority of cases I'd imagine users will know
> who the message was sent to.

Not if they have multiple mailboxes, like office and private.

Michael

From: "Nigel Swinson" <[email-masked]>
To: "Michael Haardt" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Thu, 17 Feb 2005 14:43:31 -0000
Sender: [email-masked]

> Sorry for the late reply, but I sent this previously with a sender
> that's not subscribed to the list.

:o)

> It may be easier to specify different actions than different extensions
> to notify, at least current extension specifications make me think so.
> So I don't mind to split things up.

Ok :o)
 
> >  The :recipient tag specifies the target phone numbers to send this SMS
> >  to.  If not present, the implementation should try to send the SMS to the
> >  owner of the script where the number is held by the sieve implementation,
> >  ie a mailbox property.
> 
> As long as that's not a "SHOULD try", it is fine with me.  Enforcing a new
> mailbox property in order to use this extension would not be nice at all.

Good point, I'm fine with this.

> So what if no number is specified, either explicit or implicit? Should
> the action be ignored or cause the script to fail? The same question
> arises on invalid number strings.  I vote for ignoring invalid numbers
> and actions without any number at all.

I think if phone numbers are supplied, then the implementation SHOULD raise a compile error if the supplied string is not valid.  If no phone number is supplied then the implementation SHOULD try use a default, and if this is not available then the implementation SHOULD notify the user of the error but MUST NOT fail the execution of the script.  I had a look to see what was specified in the vacation draft, but didn't find any comments relating to what I think are similair issues.

> >  If present, specifies the target number, and it
> >  can also be a list of numbers if more than one recipient is desired.
> 
> Please let the implementation limit the maximum amount of specified
> recipients or sms actions.

Ok :o)  And if more than the limit are specified, then this would be a compile error?

> I think that must be a MUST. :) I am sure the TON/NPI for the
> international numbers you described is defined by a standard that could
> be referenced here, I just don't know which one.

Ok, I guess when the time comes we'll need to find it and reference it.

> >  The message is a string, whereby variable expansion is also
> >  permitted. The limit is the maximum number of SMS messages that the
> >  server can send.  Given that each message typically has a cost associated
> >  with it, the limit by default will be whatever produces the least cost
> >  which in today?s terms is 1 message (140 bytes) but may change in the
> >  future.
> 
> Over here, up to 160 octets do fit in a single message.  I think that
> the EUR currency sign is encoded in two octets, though.  The character
> set is IA5, so we have to specify what happens to unicode characters that
> can not be translated to IA5.  I am used to gateways just dropping them.
> 
> Of course you could apply the length after IA5 translation, but how
> about specifying the cost in number of messages (:parts)?

The :limit parameter I was proposing was meant to apply after any character set encoding of the message.  I'm not familiar with IA5, I had hoped we could just pipe UTF8 and then truncate at some appropriate point.  So I'm not sure in what way your proposed :parts differs to my :limit?

> I prefer this:
> 
>                From <sender-address> To <recipient-address>: 
> <Subject>\r\n<body>
> 
> I would like to allow the implementation to use a different default
> format.  In case it has access to a language mailbox property, it should
> be allowed to send a message in the users native language by default.

I wasn't actually proposing we standardize the default message format, just describing what I was going to use, but that is an interesting idea :o)  That could make your sieve action just:

   sms;

If we are to offer a standard, then maybe we should just drop the "To" as well, as in the vast majority of cases I'd imagine users will know who the message was sent to.

> >  One way to get his is using the proposed $name$ variables which seem
> >  pretty ugly next to what we've worked so hard on with the variables
> >  extension, and also is pretty inflexible.
> 
> Agreed.

:o)
 
> There are two remaining issues: Rate limiting and security.  I suggest
> a new extension which specifies a condition for rate limiting, e.g.
> named token buckets, to keep that out of sms.  It may be useful to forward
> mail to expensive gateway addresses as well.  The sms/notify extension
> should not offer builtin rate limiting.  

Reminds me of an old post that I can't find just now todo with gathering statistics about how long various extensions were taking so as to limit the capabilities of scripts...

> With concern to security: The
> implementation SHOULD enforce that SMS are only sent to verified numbers.
> Otherwise, one typo suffices to annoy someone else like hell, apart
> from letting him read part of your mail.

I'm still dreaming of the day when phone numbers don't exist in the user domain at all, and rather we move completely over to using the localpart@domainname format for email, post, phone, sms, fax.  I'm told the model in the US is that the recipient pays for receiving an SMS, and I'm amazed to hear that it works!  Apparently you can disable SMS from certain senders as a way of protecting against error/mallicious use.

Thanks for the comments!

Nigel

Date: Wed, 16 Feb 2005 14:16:20 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Sieve-Notify and potential associative arrays.
Sender: [email-masked]

Sorry for the late reply, but I sent this previously with a sender
that's not subscribed to the list.

On Wed, Feb 02, 2005 at 02:21:49AM -0000, Nigel Swinson wrote:
>  It seems to me that the notify extension is trying to do too much
>  in supporting notification by email, SMS or indeed any arbitrary
>  notification mechanism.  It was pointed out quickly how many complex
>  internationalization issues you have to deal with when composing
>  emails, but you have completely different concerns when dealing with
>  SMS messages, so I'm not sure it makes sense to bundle them.

It may be easier to specify different actions than different extensions
to notify, at least current extension specifications make me think so.
So I don't mind to split things up.

>we should therefore have something more along these lines:
>
>  Syntax:   sms [":recipient" <recipient-numbers: string-list>] 
>[:limit <number>] <message: string>
>
>  The :recipient tag specifies the target phone numbers to send this SMS
>  to.  If not present, the implementation should try to send the SMS to the
>  owner of the script where the number is held by the sieve implementation,
>  ie a mailbox property.

As long as that's not a "SHOULD try", it is fine with me.  Enforcing a new
mailbox property in order to use this extension would not be nice at all.

So what if no number is specified, either explicit or implicit? Should
the action be ignored or cause the script to fail? The same question
arises on invalid number strings.  I vote for ignoring invalid numbers
and actions without any number at all.

>  If present, specifies the target number, and it
>  can also be a list of numbers if more than one recipient is desired.

Please let the implementation limit the maximum amount of specified
recipients or sms actions.

>  Each phone number must begin with a + and include the country code to
>  ensure that the script will work regardless of location of server/script.

I think that must be a MUST. :) I am sure the TON/NPI for the
international numbers you described is defined by a standard that could
be referenced here, I just don't know which one.

>  The message is a string, whereby variable expansion is also
>  permitted. The limit is the maximum number of SMS messages that the
>  server can send.  Given that each message typically has a cost associated
>  with it, the limit by default will be whatever produces the least cost
>  which in today?s terms is 1 message (140 bytes) but may change in the
>  future.

Over here, up to 160 octets do fit in a single message.  I think that
the EUR currency sign is encoded in two octets, though.  The character
set is IA5, so we have to specify what happens to unicode characters that
can not be translated to IA5.  I am used to gateways just dropping them.

Of course you could apply the length after IA5 translation, but how
about specifying the cost in number of messages (:parts)?

>  Which brings me on to variables.  Each of these different notification
>  types, and also the vacation extension to a certain degree, has the need
>  to author messages, and likely include sections of the triggering message.
>  So suppose I want to author what I think is a fairly reasonable SMS
>  which looks like this:
>             [To:<recipient-addresss>From:<sender-address>] 
><Subject>\r\n<body>

I prefer this:

               From <sender-address> To <recipient-address>: 
<Subject>\r\n<body>

I would like to allow the implementation to use a different default
format.  In case it has access to a language mailbox property, it should
be allowed to send a message in the users native language by default.

>  One way to get his is using the proposed $name$ variables which seem
>  pretty ugly next to what we've worked so hard on with the variables
>  extension, and also is pretty inflexible.

Agreed.

There are two remaining issues: Rate limiting and security.  I suggest
a new extension which specifies a condition for rate limiting, e.g.
named token buckets, to keep that out of sms.  It may be useful to forward
mail to expensive gateway addresses as well.  The sms/notify extension
should not offer builtin rate limiting.  With concern to security: The
implementation SHOULD enforce that SMS are only sent to verified numbers.
Otherwise, one typo suffices to annoy someone else like hell, apart
from letting him read part of your mail.

Michael

Date: Wed, 16 Feb 2005 09:42:37 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Sieve base-spec revision I-D
Sender: [email-masked]

On Tue, Feb 15, 2005 at 06:42:33PM -0800, Philip Guenther wrote:
> <editor hat off>
> 
> If I want to search for control characters in a message's subject
> (or body, using the body extension) or include them in a vacation
> reply or notification message, why shouldn't I be able to?
> 
> <editor hat on>

>From the Exim Sieve implementation:

----------
Sieve scripts can not contain NUL characters in strings, but mail
headers could contain MIME encoded NUL characters, which could never
be matched by Sieve scripts using exact comparisons.  For that reason,
this implementation extends the Sieve quoted string syntax with \0
to describe a NUL character, violating \0 being the same as 0 in
RFC 3028.  Even without using \0, the following tests are all true in
this implementation.  Implementations that use C-style strings will only
evaulate the first test as true.

Subject: =?iso-8859-1?q?abc=00def

header :contains "Subject" ["abc"]
header :contains "Subject" ["def"]
header :matches "Subject" ["abc?def"]

Note that by considering Sieve to be a MUA, RFC 2047 can be interpreted
in a way that NUL characters truncating strings is allowed for Sieve
implementations, although not recommended.  It is further allowed to use
encoded NUL characters in headers, but that's not recommended either.
The above example shows why.  Good code should still be able to deal
with it.
----------

I doubt repeating it makes a difference to anybody here, but I would
really like if RFC 3028 specified behaviour of the above comparisons.

Michael

Subject: Re: Sieve base-spec revision I-D
From: Kjetil Torgrim Homme <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: [email-masked]
Date: Wed, 16 Feb 2005 05:36:26 +0100
Sender: [email-masked]

On Tue, 2005-02-15 at 18:42 -0800, Philip Guenther wrote:
> Kjetil Torgrim Homme <[email-masked]> writes:
> <shrug>  Looking again, I see the various IETF webpages aren't
> consist on this, some using "email" or "Email", others using "e-mail"
> or "E-mail".  I find Donald Knuth's argument for "email", as
> reproduced by W. Richard Stevens at:
> 	http://www.kohala.com/start/papers.others/knuth.email.html
> 
> persuasive, but if there's consensus to go the other way I'll change it.

I don't find that persuasive.  the natural progression is "electronic
mail" -> "e-mail" -> "mail".  the latter is another keystroke saved. :-)

> While the prose of RFC 3028 at least partially addresses the presence
> of NUL, HTAB, CR, and LF in scripts, it doesn't ban any other valid
> UTF-8 character.  Can you speak more on why you think control codes
> should be banned from strings and comments?

"they're ugly and will mostly serve as a projectile ejector which users
can aim at their lower extremities".

but I've already changed my mind :-).  we need to mimic what [IMAIL]
accepts at least for strings and multi-line strings.  to make it easier
to comment out parts of the code, we should not make the syntax for
comments more restrictive.

NUL should be disallowed completely.

> >if we keep control characters, solitary CR or LF should be accepted just
> >as any other odd control character.

that is, with no special meaning.  this is more lax than [IMAIL], which
says

   - CR and LF MUST only occur together as CRLF; they MUST NOT appear
     independently in the body.

the grammar makes it clear that the same is true for the headers.  if
you prefer to be as strict as [IMAIL], that's fine by me, too.

> If I want to search for control characters in a message's subject
> (or body, using the body extension) or include them in a vacation
> reply or notification message, why shouldn't I be able to?

for vacation, you can use ":mime" and do the quoted-printable thing
yourself.

there is a slight problem since a header can use encoding to include NUL
and other problematic characters, and the Sieve interpreter undoes this
in order to present it all as UTF-8 or plain octets to the user.  I wish
there were an escape for including octets by value in strings, e.g.
"\x00".  that would be an incompatible change, can we do that?

(if so, I'd want "\uXXXX" and "\UXXXXXXXX" for Unicode, too (same syntax
as Java and C99))

> >wrt bracket-comment, I don't think you need to complicate it much more:
> >
> >bracket-comment = "/*" (*(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) / "*")
> >"*/"
> 
> That, like the version in 3028, permits "*/" in the middle of a
> comment.

I don't think so, note the placement of the parentheses.  but no matter.

> >a clarification about ":matches" would be useful: the pattern must match
> >the entire string.
> 
> How about the following for 2.7.1, paragraph 5, first sentence:
> 	The ":matches" match type specifies a wildcard match using
> 	the characters "*" and "?"; the entire value must be matched.

ok, but I think I prefer s/value/value argument/
-- 
Kjetil T.

Date: Tue, 15 Feb 2005 21:56:13 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Sieve base-spec revision I-D
Sender: [email-masked]

--==========1DBF34C61EEBD0FF3C8D==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

> It missed at least one of the deadlines

Yes... ARGH!  9 *AM* Monday, not 9 *PM* Monday.  Grr.  So I missed it
also, having submitted the "relational" draft Monday afternoon.  :-(
Here's what I submitted, and I'll resubmit it after the IETF meeting.
The only substantive change is in the formal grammar, where I've added
definitions of the comparison terms ("gt", "ge", "lt", "le", "eq",
"ne").

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

--==========1DBF34C61EEBD0FF3C8D==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-sieve-3431bis-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-ietf-sieve-3431bis-00.txt";
 size=15219

Sieve Working Group                                         W. =
Segmuller
Internet Draft                                                  B. =
Leiba
Obsoletes: 3431 (if approved)            IBM T.J. Watson Research =
Center
Document: draft-ietf-sieve-3431bis-00.txt                  February =
2005
                                                     Expires August =
2005
                   Sieve Extension: Relational Tests
Status of this Document
   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.
   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.
   This Internet-Draft will expire on August 14, 2005.
Copyright Notice
   Copyright (C) The Internet Society (2005).
Abstract
   This document describes the RELATIONAL extension to the Sieve mail
   filtering language defined in RFC 3028.  This extension extends
   existing conditional tests in Sieve to allow relational operators.=20
W. Segmuller, B. Leiba    Expires August 2005                  [Page 1]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
   In addition to testing their content, it also allows for testing of
   the number of entities in header and envelope fields. =20
Meta-information on this document
   This information is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.
   This document is intended to be an update to the existing
   "relational" extension to the Sieve mail filtering language,
   available from the RFC repository as
   <ftp://ftp.isi.edu/in-notes/rfc3431.txt>.
   This document and the Sieve language itself are being discussed on
   the MTA Filters mailing list at <mailto:[email-masked]>.=20
   Subscription requests can be sent to
   <mailto:[email-masked]?body=3Dsubscribe> (send an
   email message with the word "subscribe" in the body).  More
   information on the mailing list along with a WWW archive of back
   messages is available at <http://www.imc.org/ietf-mta-filters/>.
Conventions used in this document
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119. =20
   Conventions for notations are as in [SIEVE] section 1.1, including
   the use of [KEYWORDS] and "Syntax:" label for the definition of
   action and tagged arguments syntax, and the use of [ABNF]. =20
   The capability string associated with extension defined in this
   document is "relational".
1. Introduction
   Sieve [SIEVE] is a language for filtering e-mail messages at the =
time
   of final delivery.  It is designed to be implementable on either a
   mail client or mail server.  It is meant to be extensible, simple,
   and independent of access protocol, mail architecture, and operating
   system.  It is suitable for running on a mail server where users may
   not be allowed to execute arbitrary programs, such as on black box
   Internet Messages Access Protocol (IMAP) servers, as it has no
   variables, loops, nor the ability to shell out to external programs. =

   The RELATIONAL extension provides relational operators on the
W. Segmuller, B. Leiba    Expires August 2005                  [Page 2]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
   address, envelope, and header tests.  This extension also provides a
   way of counting the entities in a message header or address field. =20
   With this extension, the sieve script may now determine if a field =
is
   greater than or less than a value instead of just equivalent.  One
   use is for the x-priority field: move messages with a priority
   greater than 3 to the "work on later" folder.  Mail could also be
   sorted by the from address.  Those userids that start with 'a'-'m' =
go
   to one folder, and the rest go to another folder. =20
   The sieve script can also determine the number of fields in the
   header, or the number of addresses in a recipient field.  For
   example: are there more than 5 addresses in the to and cc fields. =20
2. Comparators
   This document does not define any comparators or exempt any
   comparators from the require clause.  Any comparator used, other =
than
   "i;octet" and "i;ascii-casemap", MUST be declared a require clause =
as
   defined in [SIEVE]. =20
   The "i;ascii-numeric" comparator, as defined in [ACAP], MUST be
   supported for any implementation of this extension.  The comparator
   "i;ascii-numeric" MUST support at least 32 bit unsigned integers. =20
   Larger integers MAY be supported.  Note: the "i;ascii-numeric"
   comparator does not support negative numbers. =20
3. Match Type
   This document defines two new match types.  They are the VALUE match
   type and the COUNT match type. =20
   The syntax is:
       MATCH-TYPE =3D/ COUNT / VALUE
       COUNT =3D ":count" relational-match
       VALUE =3D ":value" relational-match
       relational-match =3D DQUOTE ( "gt" / "ge" / "lt"
                                   / "le" / "eq" / "ne" ) DQUOTE
          ; "gt" means "greater than", the C operator ">".
          ; "ge" means "greater than or equal", the C operator ">=3D".
          ; "lt" means "less than", the C operator "<".
          ; "le" means "less than or equal", the C operator "<=3D".
W. Segmuller, B. Leiba    Expires August 2005                  [Page 3]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
          ; "eq" means "greater than", the C operator "=3D=3D".
          ; "ne" means "greater than", the C operator "!=3D".
3.1.  Match Type Value
   The VALUE match type does a relational comparison between strings. =20
   The VALUE match type may be used with any comparator which returns
   sort information. =20
   Leading and trailing white space MUST be removed from the value of
   the message for the comparison.  White space is defined as=20
       SP / HTAB / CRLF
   A value from the message is considered the left side of the =
relation.=20
   A value from the test expression, the key-list for address, =
envelope,
   and header tests, is the right side of the relation. =20
   If there are multiple values on either side or both sides, the test
   is considered true, if any pair is true.
3.2.  Match Type Count
   The COUNT match type first determines the number of the specified
   entities in the message and does a relational comparison of the
   number of entities to the values specified in the test expression. =20
   The COUNT match type SHOULD only be used with numeric comparators. =20
   The Address Test counts the number of recipients in the specified
   fields.  Group names are ignored. =20
   The Envelope Test counts the number of recipients in the specified
   envelope parts.  The envelope "to" will always have only one entry,
   which is the address of the user for whom the sieve script is
   running.  There is no way a sieve script can determine if the =
message
   was actually sent to someone else using this test.  The envelope
   "from" will be 0 if the MAIL FROM is blank, or 1 if MAIL FROM is not
   blank. =20
   The Header Test counts the total number of instances of the =
specified
   fields.  This does not count individual addresses in the "to", "cc",
   and other recipient fields. =20
   In all cases, if more than one field name is specified, the counts
   for all specified fields are added together to obtain the number for
W. Segmuller, B. Leiba    Expires August 2005                  [Page 4]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
   comparison.  Thus, specifying ["to", "cc"] in an address COUNT test,
   comparing the total number of "to" and "cc" addresses; if separate
   counts are desired, they must be done in two comparisons, perhaps
   joined by "allof" or "anyof". =20
4. Example
   Using the message:=20
       received: ...
       received: ...
       subject: example
       to: [email-masked], [email-masked]
       cc: [email-masked]
   The test:=20
       address :count "ge" :comparator "i;ascii-numeric"
                       ["to", "cc"] ["3"]
   would be true and the test=20
       anyof ( address :count "ge" :comparator "i;ascii-numeric"
                       ["to"] ["3"],
               address :count "ge" :comparator "i;ascii-numeric"
                       ["cc"] ["3"] )
   would be false. =20
   To check the number of received fields in the header, the following
   test may be used:=20
       header :count "ge" :comparator "i;ascii-numeric"
                       ["received"] ["3"]
   This would return false.  But
       header :count "ge" :comparator "i;ascii-numeric"
                       ["received", "subject"] ["3"]
   would return true. =20
   The test:=20
       header :count "ge" :comparator "i;ascii-numeric"
                       ["to", "cc"] ["3"]
   will always return false on an RFC 2822 compliant message [RFC2822],
W. Segmuller, B. Leiba    Expires August 2005                  [Page 5]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
   since a message can have at most one "to" field and at most one "cc"
   field.  This test counts the number of fields, not the number of
   addresses. =20
5. Extended Example
   require ["relational", "comparator-i;ascii-numeric"];
   if header :value "lt" :comparator "i;ascii-numeric"
             ["x-priority"] ["3"]
   {
      fileinto "Priority";
   }
   elseif address :count "gt" :comparator "i;ascii-numeric"
              ["to"] ["5"]
   {
      # everything with more than 5 recipients in the "to" field
      # is considered SPAM
      fileinto "SPAM";
   }
   elseif address :value "gt" :all :comparator "i;ascii-casemap"
              ["from"] ["M"]
   {
      fileinto "From N-Z";
   } else {
      fileinto "From A-M";
   }
   if allof ( address :count "eq" :comparator "i;ascii-numeric"
                      ["to", "cc"] ["1"] ,
              address :all :comparator "i;ascii-casemap"
                      ["to", "cc"] ["[email-masked]"]
   {
      fileinto "Only me";
   }
6.  IANA Considerations
   This document requests that the IANA update the entry for the
   "relational" Sieve extension to point to this document.
7. Security Considerations
   Security considerations are discussed in [SIEVE]. =20
W. Segmuller, B. Leiba    Expires August 2005                  [Page 6]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
   An implementation MUST ensure that the test for envelope "to" only
   reflects the delivery to the current user.  It MUST not be possible
   for a user to determine if this message was delivered to someone =
else
   using this test.
8. Normative References
   [SIEVE]; Showalter, T.; "Sieve: A Mail Filtering Language"; RFC =
3028;
   January 2001.
   [Keywords]; Bradner, S.; "Key words for use in RFCs to
   IndicateRequirement Levels"; BCP 14; RFC 2119; March 1997.
   [ABNF]; Crocker, D.; "Augmented BNF for Syntax Specifications: =
ABNF";
   RFC 2234; November 1997. =20
   [RFC2822]; Resnick, P.; "Internet Message Format"; RFC 2822; April
   2001.
9. Non-Normative References
   [ACAP]; Newman, C. and J. G. Myers; "ACAP -- Application
   Configuration Access Protocol"; RFC 2244; November 1997.
10. Authors' Addresses
   Wolfgang Segmuller
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   Phone: 1-914-784-7408
   Email: [email-masked]
   Barry Leiba
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   Phone: 1-914-784-7941
   Email: [email-masked]
W. Segmuller, B. Leiba    Expires August 2005                  [Page 7]
=0C
Internet DRAFT     Sieve Extension: Relational Tests      February 2005
Intellectual Property Statement
   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed =
to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  =
Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.
   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use =
of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository =
at
   http://www.ietf.org/ipr.
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].
Disclaimer of Validity
   This document and the information contained herein are provided on =
an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =
REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.
Acknowledgment
   Funding for the RFC Editor function is currently provided by the
   Internet Society.
W. Segmuller, B. Leiba    Expires August 2005                  [Page 8]

--==========1DBF34C61EEBD0FF3C8D==========--

To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: Sieve base-spec revision I-D 
Date: Tue, 15 Feb 2005 18:42:33 -0800
Sender: [email-masked]

Kjetil Torgrim Homme <[email-masked]> writes:
>On Tue, 2005-02-15 at 16:22 -0800, Philip Guenther wrote:
...
>>  3. Replace "e-mail" with "email"
>
>I think this is the wrong way around, no one pronounces "e-mail" in a
>manner consistent with the spelling "email" ;-).  however, using _both_
>spellings as in 3028 certainly isn't ideal.

<shrug>  Looking again, I see the various IETF webpages aren't
consist on this, some using "email" or "Email", others using "e-mail"
or "E-mail".  I find Donald Knuth's argument for "email", as
reproduced by W. Richard Stevens at:
	http://www.kohala.com/start/papers.others/knuth.email.html

persuasive, but if there's consensus to go the other way I'll change it.

...
>>  7. Start to update grammar to only permit legal UTF-8 (incomplete)
>>     and correct various other errors and typos
>
>too bad RFC 3629 didn't include a syntax class for UTF-8 sans control
>codes, I'm sure this will be needed elsewhere, too.  if you are
>pedantic, 0x80..0x9F are also code points used for control codes.  so,
>don't use UTF8-2, but define your own

While the prose of RFC 3028 at least partially addresses the presence
of NUL, HTAB, CR, and LF in scripts, it doesn't ban any other valid
UTF-8 character.  Can you speak more on why you think control codes
should be banned from strings and comments?

...
>> I have some additional fixes for the grammar already queued up for
>> the -01 rev, so you can probably hold off on picking nits there for
>> now.  The only open issue I need feedback on there is where bare
>> CR and LF characters should be allowed.  In comments?  In strings?
>> In multiline literals?
>
>do we gain anything by supporting bare CR or LF?  I think we should
>disallow control characters altogether (except CRLF and HTAB, of
>course).  is this too big a change?  I note that 3028 only accepts NUL
>inside /**/ comments (gotcha!), so arbitrary binary data isn't supported
>currently.
>
>if we keep control characters, solitary CR or LF should be accepted just
>as any other odd control character.

<editor hat off>

If I want to search for control characters in a message's subject
(or body, using the body extension) or include them in a vacation
reply or notification message, why shouldn't I be able to?

<editor hat on>

>you are aware that quoted-string is hopelessly broken, I'm sure.

Already fixed in my copy.  :-)

>wrt bracket-comment, I don't think you need to complicate it much more:
>
>bracket-comment = "/*" (*(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) / "*")
>"*/"

That, like the version in 3028, permits "*/" in the middle of a
comment.  I know how to write the grammar for C-style comments; I
just need the consensus on what characters are permitted.

...
>a clarification about ":matches" would be useful: the pattern must match
>the entire string.

How about the following for 2.7.1, paragraph 5, first sentence:
	The ":matches" match type specifies a wildcard match using
	the characters "*" and "?"; the entire value must be matched.

Philip Guenther
[email-masked]

Subject: Re: Sieve base-spec revision I-D
From: Kjetil Torgrim Homme <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: [email-masked]
Date: Wed, 16 Feb 2005 02:59:18 +0100
Sender: [email-masked]

On Tue, 2005-02-15 at 16:22 -0800, Philip Guenther wrote:
> 	http://sendmail.org/draft-ietf-sieve-3028bis-00.txt
> 
> Changes from RFC 3028
>  1. Split references into normative and informative
>  2. Update references to current versions of DSN, IMAP, MDN, and UTF-8 RFCs
>  3. Replace "e-mail" with "email"

I think this is the wrong way around, no one pronounces "e-mail" in a
manner consistent with the spelling "email" ;-).  however, using _both_
spellings as in 3028 certainly isn't ideal.

>  4. Incorporate RFC 3028 errata
>  5. The "reject" action cancels the implicit keep
>  6. Replace references to ACAP with references to the i18n-comparator draft.
>     Further work is needed to completely sync with that draft.
>  7. Start to update grammar to only permit legal UTF-8 (incomplete)
>     and correct various other errors and typos

too bad RFC 3629 didn't include a syntax class for UTF-8 sans control
codes, I'm sure this will be needed elsewhere, too.  if you are
pedantic, 0x80..0x9F are also code points used for control codes.  so,
don't use UTF8-2, but define your own

  UTF8-2-NO-CTL = %xC2 %xA0-BF / %C3-DF UTF8-tail  ; excludes U+0080..U
+009F

I think defining

  UTF8-NO-CTL = UTF8-1-NO-CTL / UTF8-2-NO-CTL / UTF8-3 / UTF8-4
  UTF8-1-NO-CTL = %x20-7F

will make the rest of your grammar more readable.

> I have some additional fixes for the grammar already queued up for
> the -01 rev, so you can probably hold off on picking nits there for
> now.  The only open issue I need feedback on there is where bare
> CR and LF characters should be allowed.  In comments?  In strings?
> In multiline literals?

do we gain anything by supporting bare CR or LF?  I think we should
disallow control characters altogether (except CRLF and HTAB, of
course).  is this too big a change?  I note that 3028 only accepts NUL
inside /**/ comments (gotcha!), so arbitrary binary data isn't supported
currently.

if we keep control characters, solitary CR or LF should be accepted just
as any other odd control character.

you are aware that quoted-string is hopelessly broken, I'm sure.

wrt bracket-comment, I don't think you need to complicate it much more:

bracket-comment = "/*" (*(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) / "*")
"*/"

> The other open issues on my list are:
> 
> 1) removal of the "Tests MUST NOT have side effects" restriction.
>    We must permit the behavior of the 'variables' extension; do we
>    still want to discourage side-effects in general or should the
>    last two paragraphs of section 2.5 simply be dropped?
> 
> 2) some other clarifications that Cyrus forwarded to me that I
>    haven't rolled in yet.  (sorry)

a clarification about ":matches" would be useful: the pattern must match
the entire string.

thanks,
-- 
Kjetil T.

To: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Sieve base-spec revision I-D
Date: Tue, 15 Feb 2005 16:22:52 -0800
Sender: [email-masked]

It missed at least one of the deadlines, so the I-D for the revision
of RFC 3028 can be found at:
	http://sendmail.org/draft-ietf-sieve-3028bis-00.txt

Changes from RFC 3028
 1. Split references into normative and informative
 2. Update references to current versions of DSN, IMAP, MDN, and UTF-8 RFCs
 3. Replace "e-mail" with "email"
 4. Incorporate RFC 3028 errata
 5. The "reject" action cancels the implicit keep
 6. Replace references to ACAP with references to the i18n-comparator draft.
    Further work is needed to completely sync with that draft.
 7. Start to update grammar to only permit legal UTF-8 (incomplete)
    and correct various other errors and typos
 8. Update IPR broilerplate

I have some additional fixes for the grammar already queued up for
the -01 rev, so you can probably hold off on picking nits there for
now.  The only open issue I need feedback on there is where bare
CR and LF characters should be allowed.  In comments?  In strings?
In multiline literals?

The other open issues on my list are:

1) removal of the "Tests MUST NOT have side effects" restriction.
   We must permit the behavior of the 'variables' extension; do we
   still want to discourage side-effects in general or should the
   last two paragraphs of section 2.5 simply be dropped?

2) some other clarifications that Cyrus forwarded to me that I
   haven't rolled in yet.  (sorry)

3) are there other changes that should be made to synchronize with
   the i18n-comparator draft?

Respectfully submitted,

Philip Guenther
[email-masked]

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 12 Feb 2005 16:38:21 -0500
To: [email-masked]
Cc: Matthew Elvey <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: spamtestbis
Sender: [email-masked]

On Sat, Feb 12, 2005 at 12:45:42PM -0800, [email-masked] wrote:
> >>FWIW, I personally don't see any need for more levels, but I have seen
> >>some user requests for this and I understand others have seen considerable
> >>demand for it.
> 
> >Any of it compelling?
> 
> The one I find somewhat compelling is the desire to convert to existing uses
> and cutoff values for SpamAssassin to sieve and spamtest. SpamAssassin uses
> real numbered scores and the obvious mapping to a 1-10 scale is a bit too
> grainy. A 1-100 scale, OTOH, is more than sufficient.

I'm kind of on the middle on this one.  In general I like to avoid
hardwiring runtime elements into the language, preferring instead to
give options to the script writers.  You just can't always predict what
people want, so trying not to guess is best.  My ideal would be to say
"the spam test returns a value of this type" where "type" could include
a fundamental data type (e.g. an integer, a string, a floating point
number) as well as a range (e.g. integer between 6 and 10, a string
containing one of a number of keywords, and so forth).  Much of that
doesn't fit here, of course.

But indeed I have heard from people who want far greater ranges than
0 to 10.  To quote one anonymously, specifically about spam scores:

    You can't easily use those results from procmail, as it can't do
    numeric comparisons like 'if ( ( prob >= 99.0 ) && ( prob < 99.9 ) )
    ...' to decide where to file; you need to write them in terms of
    pattern matching which gets messy.

So there's at least one person calling for a range of 0 to 1000!

There are other analyzers out there that return a floating point spam
score, although they tend to have their own ability to emit a summary
header based on a threshold.

Personally I'd try to find a way to say "map the spam test into a range
from m to n" rather than hardwiring one or two ranges in advance.  There
would be no problem in having a default (e.g. m=0, n=10).

Yours,
-mm-

Cc: [email-masked], IETF MTA Filters List <[email-masked]>
Date: Sat, 12 Feb 2005 12:45:42 -0800 (PST)
From: [email-masked]
Subject: Re: spamtestbis
To: Matthew Elvey <[email-masked]>
Sender: [email-masked]

> On 2/4/2005 10:41 AM, [email-masked] sent forth electrons to convey:

> >
> >
> >>>>FYI the draft for the new version of the spamtest extension is now
> >>>>available. The only change between this and the current RFC is the addition
> >>>>of a :percent argument to the spamtest test to allow for a numeric range of
> >>>>0 - 100. The value -1 is used to indicate a message that was not
> >>>>categorised in anyway.
> >>>>
> >>>>
> >
> >
> >
> >>I'm surprised we need a percentage spam score... I would have thought 10
> >>levels was enough.  Indeed in your example you use level 30(%) = 3.
> >>
> >>
> >
> >FWIW, I personally don't see any need for more levels, but I have seen
> >some user requests for this and I understand others have seen considerable
> >demand for it.
> >
> >

> Any of it compelling?

The one I find somewhat compelling is the desire to convert to existing uses
and cutoff values for SpamAssassin to sieve and spamtest. SpamAssassin uses
real numbered scores and the obvious mapping to a 1-10 scale is a bit too
grainy. A 1-100 scale, OTOH, is more than sufficient.

> Sometimes, there's considerable demand for bad
> ideas (e.g. to accept spam from open relays, e.g. from an  EFF founder -
> http://www.toad.com/gnu/).  I thought we discussed this and decided 10
> was enough levels, but I find no mention of it in the archives.

This is a long way from being a bad idea.

				Ned

Date: Sat, 12 Feb 2005 10:42:20 -0800
From: Matthew Elvey <[email-masked]>
To: [email-masked]
Cc: IETF MTA Filters List <[email-masked]>
Subject: Re: spamtestbis
Sender: [email-masked]

On 2/4/2005 10:41 AM, [email-masked] sent forth electrons to convey:

>  
>
>>>>FYI the draft for the new version of the spamtest extension is now
>>>>available. The only change between this and the current RFC is the addition
>>>>of a :percent argument to the spamtest test to allow for a numeric range of
>>>>0 - 100. The value -1 is used to indicate a message that was not
>>>>categorised in anyway.
>>>>        
>>>>
>
>  
>
>>I'm surprised we need a percentage spam score... I would have thought 10
>>levels was enough.  Indeed in your example you use level 30(%) = 3.
>>    
>>
>
>FWIW, I personally don't see any need for more levels, but I have seen
>some user requests for this and I understand others have seen considerable
>demand for it.
>  
>
Any of it compelling?  Sometimes, there's considerable demand for bad 
ideas (e.g. to accept spam from open relays, e.g. from an  EFF founder - 
http://www.toad.com/gnu/).  I thought we discussed this and decided 10 
was enough levels, but I find no mention of it in the archives.

Date: Sat, 12 Feb 2005 07:56:10 -0800
From: Matthew Elvey <[email-masked]>
To: Eric SOHIER <[email-masked]>
Cc: [email-masked]
Subject: Re: Regulate sieve which does not go!
Sender: [email-masked]

On 2/6/2005 12:45 AM, Eric SOHIER sent forth electrons to convey:

>Hello,
>
> 
>
>I'm a new member of the list and I use the service fmailbox which manages
>the rules sieve.
>
> 
>
>I would like to know how to describe a rule which makes it possible to move
>a message which contains a specific address "from"?
>  
>
This kind of question would be more appropriate to ask (or self-answer) 
starting here:
http://wiki.fastmail.fm/index.php/SieveExamples, such as on the fastmail 
forum.

Your sieve has a syntax error (the ":" is in the wrong place).

> 
>
>I tested this:
>
> 
>
>If header: contains ["To"] ["[email-masked]"] {fileinto
>"INBOX.Astronomie.astrocam";}
>
> 
>
>But that does not go on this message:
>
> 
>
>X-Sender: [email-masked]
>
>X-Apparently-To: [email-masked]
>
>Received: (qmail 26728 invoked from network); 21 Jan 2005 13:46:09 -0000
>
>Received: from unknown (66.218.66.218)
>
>  by m17.grp.scd.yahoo.com with QMQP; 21 Jan 2005 13:46:09 -0000
>
>Received: from unknown (HELO hotmail.com) (65.54.185.29)
>
>  by mta3.grp.scd.yahoo.com with SMTP; 21 Jan 2005 13:46:09 -0000
>
>Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
>
>      Fri, 21 Jan 2005 05:42:02 -0800
>
>Message-ID: <[email-masked]>
>
>Received: from 84.195.167.88 by by15fd.bay15.hotmail.msn.com with HTTP;
>
>     Fri, 21 Jan 2005 13:41:05 GMT
>
>X-Originating-Email: [[email-masked]]
>
>X-Sender: [email-masked]
>
>To: [email-masked], [email-masked],
>
>     [email-masked]
>
>X-OriginalArrivalTime: 21 Jan 2005 13:42:02.0351 (UTC)
>FILETIME=[FCCEFFF0:01C4FFBE]
>
>X-eGroups-Remote-IP: 65.54.185.29
>
>From: "patricia david" <[email-masked]>
>
>X-Originating-IP: [84.195.167.88]
>
>X-Yahoo-Profile: astrobourlingueurs
>
>MIME-Version: 1.0
>
>Mailing-List: list [email-masked]; contact
>[email-masked]
>
>Delivered-To: mailing list [email-masked]
>
>Precedence: bulk
>
>List-Unsubscribe: <mailto:[email-masked]>
>
>Date: Fri, 21 Jan 2005 13:41:05 +0000
>
>Subject: [astrocam] Tete de cheval
>
>Content-Type: multipart/mixed;
>
> boundary="----=_NextPart_000_4a7a_535c_14b6"
>
> 
>
>Why ?
>
> 
>
>Thanks by advance.
>
> 
>
>-- Eric SOHIER
>
> 
>
>
>  
>

Date: Fri, 11 Feb 2005 13:56:14 +0000
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Sender: [email-masked]

Kjetil Torgrim Homme wrote:

>On Fri, 2005-02-11 at 00:03 +0000, Alexey Melnikov wrote:
>  
>
>>Kjetil Torgrim Homme wrote:
>>    
>>
>>>>>Does each string in "list-of-flags" contain exactly one flag, or can
>>>>>each string be a list of flags as in other usage?
>>>>>          
>>>>>
>>>>The intention was to have the former. I will try to clarify.
>>>>        
>>>>
>>>if so, '[ "A B" ]' must be handled differently from '"A B"', which seems
>>>to be in conflict with RFC 3028.  see section 2.4.2.1:
>>>      
>>>
>>You assume that a list-of-flags = ["A", "B"] is the same as ["A B"]. I 
>>originally didn't make such assumption, but I might be convinced that 
>>this is the right thing to do.
>>    
>>
>
>I'm not sure I do.  what is clear:  the argument is a list of strings.
>according to 3028, a list containing only one string may omit the
>brackets.  in other words,
>["A B"] MUST be the same as "A B".
>
I've just realized that we are talking about different things. The 
original question was whether "A B" is interpreted as ["A", "B"]. And as 
you pointed out below, the answer I gave to Mark recent was wrong.

And yes, ["A B"] is the same as "A B", even for the hasflag test.

>  whether this is the same as ["A",
>"B"] is a matter open for debate, but your draft currently say that they
>are:
>
>   hasflag :is "MyFlags" "b A"
>   [...] can be also written as
>   hasflag "MyFlags" ["b","A"]
>  
>

Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Fri, 11 Feb 2005 14:44:46 +0100
Sender: [email-masked]

On Fri, 2005-02-11 at 00:03 +0000, Alexey Melnikov wrote:
> Kjetil Torgrim Homme wrote:
> >>>Does each string in "list-of-flags" contain exactly one flag, or can
> >>>each string be a list of flags as in other usage?
> >>
> >>The intention was to have the former. I will try to clarify.
> >
> >if so, '[ "A B" ]' must be handled differently from '"A B"', which seems
> >to be in conflict with RFC 3028.  see section 2.4.2.1:
>
> You assume that a list-of-flags = ["A", "B"] is the same as ["A B"]. I 
> originally didn't make such assumption, but I might be convinced that 
> this is the right thing to do.

I'm not sure I do.  what is clear:  the argument is a list of strings.
according to 3028, a list containing only one string may omit the
brackets.  in other words,
["A B"] MUST be the same as "A B".  whether this is the same as ["A",
"B"] is a matter open for debate, but your draft currently say that they
are:

   hasflag :is "MyFlags" "b A"
   [...] can be also written as
   hasflag "MyFlags" ["b","A"]
-- 
Kjetil T.

Date: Fri, 11 Feb 2005 00:03:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Sender: [email-masked]

Kjetil Torgrim Homme wrote:

>On Wed, 2005-02-09 at 18:55 +0000, Alexey Melnikov wrote:
>  
>
>>Mark E. Mallett wrote:
>>    
>>
>>>4.  Test hasflag
>>>
>>>I'm having a hard time understanding what this test does in other than
>>>simple cases.  
>>>
>>>  > The "hasflag" test evaluates to true if any of the variables matches any
>>>  > flag name.
>>>
>>>Does this mean "contains any of the flags listed in list-of-flags" ?
>>>or "contains all of the flags listed in list-of-flags"?
>>>or "matches (according to match-type) the concatenation of flags
>>>contained in all of the list-of-flags strings, subject to canonical
>>>re-ordering"?
>>>      
>>>
>>"any flag name" means the first choice.
>>    
>>
>
>yes, this is in line with the behaviour of other tests, e.g.
>
>  address :localpart ["To", "Cc"] ["kjetilho", "alexey"]
>  
>
Exactly.

>>>Does each string in "list-of-flags" contain exactly one flag, or can
>>>each string be a list of flags as in other usage?
>>>      
>>>
>>The intention was to have the former. I will try to clarify.
>>    
>>
>
>if so, '[ "A B" ]' must be handled differently from '"A B"', which seems
>to be in conflict with RFC 3028.  see section 2.4.2.1:
>  
>
You assume that a list-of-flags = ["A", "B"] is the same as ["A B"]. I 
originally didn't make such assumption, but I might be convinced that 
this is the right thing to do.

>   Conversely, in any case where a list of strings is appropriate, a
>   single string is allowed without being a member of a list: it is
>   equivalent to a list with a single member.  This means that the test
>   `exists "To"' is equivalent to the test `exists ["To"]'.
>  
>

Date: Thu, 10 Feb 2005 22:57:49 +0000
From: Alexey Melnikov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Sender: [email-masked]

Mark E. Mallett wrote:

>On Wed, Feb 09, 2005 at 06:55:14PM +0000, Alexey Melnikov wrote:
>  
>
>>Mark E. Mallett wrote:
>>    
>>
>>>10. Extended example
>>>
>>> > elsif anyof (not address :all :contains
>>> >                ["To", "Cc"] "[email-masked]",
>>> >              header :matches "subject"
>>> >                ["*make*money*fast*", "*university*dipl*mas*"])
>>> >         {
>>> >         remove "MyFlags" "\\Flagged";
>>> >         # If message header does not contain my address,
>>> >         # it's from a list.
>>> >         fileinto :flags "${MyFlags}" "spam";   # move to "spam" folder
>>> >         }
>>> > else
>>> >         {
>>> >         # Move all other (non-company) mail to "personal"
>>> >         # folder.
>>>
>>>My eyes may be glazing over, but have we really established
>>>"non-company" mail at this point?  One of the ways we get here
>>>is if "to" or "cc" contain "[email-masked]"
>>>      
>>>
>>Everything which is not from the known mailing lists, non-company 
>>related (not sent/addressed by/to people from the company) and addressed 
>>to me goes to "personal".
>>    
>>
>
>The point is that I don't think that's true where that comment says
>it is.  When you get to that point, you can have the "To" or "Cc"
>field containing "[email-masked]" which seems to indicate a
>company-related message.
>  
>
Right, we are actually talking about the same thing :-).
When we get to this branch, it means that a message was sent by somebody 
outside of the company.
I called this "personal" mail.

So yes, the comment should be updated.

>Is my mental interpreter failing?
>  
>
No, I needed to reboot mine :-).

Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Wed, 09 Feb 2005 22:09:36 +0100
Sender: [email-masked]

On Wed, 2005-02-09 at 18:55 +0000, Alexey Melnikov wrote:
> Mark E. Mallett wrote:
> >4.  Test hasflag
> >
> >I'm having a hard time understanding what this test does in other than
> >simple cases.  
> >
> >   > The "hasflag" test evaluates to true if any of the variables matches any
> >   > flag name.
> >
> >Does this mean "contains any of the flags listed in list-of-flags" ?
> >or "contains all of the flags listed in list-of-flags"?
> >or "matches (according to match-type) the concatenation of flags
> >contained in all of the list-of-flags strings, subject to canonical
> >re-ordering"?
>
> "any flag name" means the first choice.

yes, this is in line with the behaviour of other tests, e.g.

  address :localpart ["To", "Cc"] ["kjetilho", "alexey"]

> >Does each string in "list-of-flags" contain exactly one flag, or can
> >each string be a list of flags as in other usage?
>
> The intention was to have the former. I will try to clarify.

if so, '[ "A B" ]' must be handled differently from '"A B"', which seems
to be in conflict with RFC 3028.  see section 2.4.2.1:

   Conversely, in any case where a list of strings is appropriate, a
   single string is allowed without being a member of a list: it is
   equivalent to a list with a single member.  This means that the test
   `exists "To"' is equivalent to the test `exists ["To"]'.

-- 
Kjetil T.

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 9 Feb 2005 14:28:12 -0500
To: Alexey Melnikov <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Sender: [email-masked]

On Wed, Feb 09, 2005 at 06:55:14PM +0000, Alexey Melnikov wrote:
> Mark E. Mallett wrote:

> >10. Extended example
> >
> >  > elsif anyof (not address :all :contains
> >  >                ["To", "Cc"] "[email-masked]",
> >  >              header :matches "subject"
> >  >                ["*make*money*fast*", "*university*dipl*mas*"])
> >  >         {
> >  >         remove "MyFlags" "\\Flagged";
> >  >         # If message header does not contain my address,
> >  >         # it's from a list.
> >  >         fileinto :flags "${MyFlags}" "spam";   # move to "spam" folder
> >  >         }
> >  > else
> >  >         {
> >  >         # Move all other (non-company) mail to "personal"
> >  >         # folder.
> >
> >My eyes may be glazing over, but have we really established
> >"non-company" mail at this point?  One of the ways we get here
> >is if "to" or "cc" contain "[email-masked]"
> > 
> >
> Everything which is not from the known mailing lists, non-company 
> related (not sent/addressed by/to people from the company) and addressed 
> to me goes to "personal".

The point is that I don't think that's true where that comment says
it is.  When you get to that point, you can have the "To" or "Cc"
field containing "[email-masked]" which seems to indicate a
company-related message.

Is my mental interpreter failing?

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 9 Feb 2005 14:16:01 -0500
To: [email-masked]
Cc: Mark E Mallett <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Sender: [email-masked]

On Wed, Feb 09, 2005 at 10:39:32AM -0800, [email-masked] wrote:
> > On Tue, Feb 08, 2005 at 04:28:06PM -0800, [email-masked] wrote:
> > > Without setflag I would expect to see stuff of the form
> > >
> > >     set "foo" "";
> > >     addflag "foo" "bar";
> 
> > Is the first line strictly necessary?  i.e. can you manipulate variables
> > via addflag et al if those variables haven't been instantiated?
> 
> You can but it is beside the point. The issue is that the variable may
> have been previously initialized to have some other value.

Yeah, I would say that it would be poor practice to reference an
uninitialized variable.  The question about being able to reference an
unitialized variable was a tangential wondering.

As to whether you would always see those pairs of statements together:
probably not, at least for me.  In practice I would probably initialize
the variable in some preamble and then adjust it as necessary.
Certainly another "set" to "" could be used if needed.

> > > Whether or not this savings warrants an entire action is a judgement call.
> > > Having implemented it I can say that for me at least supporting setflag only
> > > amounted to about 15 additional lines of code and one additional table entry.
> 
> > I think having extra stuff in the language is more the point than how
> > hard it is to add that extra stuff.  I would also prefer not to have
> > verbs that aren't really needed.
> 
> Implementation difficulty is definitely a factor to consider IMO, as is whether
> or not the verb will actually be used. Stuff that's hard to implement increases
> the liklihood of bugs, as does having stuff that's rarely used (rarely used
> code is often a place where bugs lurk).

OK, but "let's avoid it because it's hard to implement" is quite different
from "let's add it in because it's easy to implement."  My point is
let's consider whether we need it or not, and not just add it because
it's easy.  Syntax clutter is still clutter even if it's easy.

mm

Date: Wed, 09 Feb 2005 18:55:14 +0000
From: Alexey Melnikov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Sender: [email-masked]

Mark E. Mallett wrote:

>Some more random comments.
>
>1. Introduction
>
>   > This extension depends on the presence of "variables" extension
>   > [Variables].
>
>Should you mention that this isn't an automatic dependency?  i.e.
>that the script writer still has to require variables?
>
I've added:
   This means that a script using this extension MUST list both 
"variables" and "imap4flags" in a require statement.

in order to clarify.

>><<Extension name has been changed as revision 03 of this document is widely
>>deployed in CMU Cyrus server>>
>>    
>>
>
>Isn't this problematic in terms of the relationship between drafts
>and implementations?
>  
>
It is surely is, but I don't know a generic solution for the problem.

>2.1. General requirements for flag handling
>
>   >  A string
>   > containing a space separated list of flags ...
>
>nit:  "space-separated"
>(repeat for other occurances in the document)
>  
>
fixed.

>   > If a flag validity check fails the flag should be silently
>   > dropped, but a warning message should be logged by the Sieve interpreter.
>
>nit one:  I would say "ignored" since "dropped" could be read as
>"removed from the message" rather than "not paid attention to in the
>Sieve statement."  (Even though the flag wouldn't be associated with the
>message if it's invalid: but I'm talking English grammar here, not
>logic.)
>  
>
Ok.

>nit two:  I would use a word other than "logged" -- warnings may
>be issued in other ways than logging.
>
>nit three: should "should" be "SHOULD" ?
>  
>
Yes.

>nit four: if the error should be reported, in what way is it silently
>ignored?
>
Maybe the better way of conveying my idea is to say that a failure to 
set a certain flag doesn't stop other flags from being set and doesn't 
cause a runtime error.

>
>
>
>3. Actions
>
>   > The "set" action
>   > defined in [Variables] can be used to replaces an existing set of flags
>   > with a new set as well.
>
>nit: "replace" (instead of "replaces")
>  
>
Thanks.

>3.1. Setflag Action
>
>        > if header :contains "from" "[email-masked]" {
>
>Prohibition on using real domain names in documents?  (i.e.,
>"example.edu")  Repeat for other occurances in the document.
>  
>
Fixed.

>4.  Test hasflag
>
>I'm having a hard time understanding what this test does in other than
>simple cases.  
>
>   > The "hasflag" test evaluates to true if any of the variables matches any
>   > flag name.
>
>Does this mean "contains any of the flags listed in list-of-flags" ?
>or "contains all of the flags listed in list-of-flags"?
>or "matches (according to match-type) the concatenation of flags
>contained in all of the list-of-flags strings, subject to canonical
>re-ordering"?
>
"any flag name" means the first choice.

>
>Does each string in "list-of-flags" contain exactly one flag, or can
>each string be a list of flags as in other usage?
>
The intention was to have the former. I will try to clarify.

>Perhaps more examples would help.
>
Yes.

>
>
>
>6. Implementation Notes
>
>   > "addflag <variable> <flag>" can be implemented as:
>   > 
>   >  if not string :matches :comparator "i;ascii-casemap"
>   >     " ${<variable>} " "* <flag> *" {
>   >      set <variable> "${<variable>} <flag>"
>   >  }
>
>Note that you'll get a superfluous leading space if <variable> starts
>out empty.  Probably doesn't need saying, though, except that the
>following "removeflag" example goes to great pains to remove leading
>and trailing spaces.
>
Ok.

>
>
>   > "removeflag <variable> <flag>" can be implemented as:
>   > 
>   >  if string :matches :comparator "i;ascii-casemap" " ${<variable>} "
>   >     "* <flag> *" {
>   >      set <variable> "${1}${2}";
>   >  }
>
>Should be "${1} ${2}", no?
>
Good catch, thanks.

>
>10. Extended example
>
>   > elsif anyof (not address :all :contains
>   >                ["To", "Cc"] "[email-masked]",
>   >              header :matches "subject"
>   >                ["*make*money*fast*", "*university*dipl*mas*"])
>   >         {
>   >         remove "MyFlags" "\\Flagged";
>   >         # If message header does not contain my address,
>   >         # it's from a list.
>   >         fileinto :flags "${MyFlags}" "spam";   # move to "spam" folder
>   >         }
>   > else
>   >         {
>   >         # Move all other (non-company) mail to "personal"
>   >         # folder.
>
>My eyes may be glazing over, but have we really established
>"non-company" mail at this point?  One of the ways we get here
>is if "to" or "cc" contain "[email-masked]"
>  
>
Everything which is not from the known mailing lists, non-company 
related (not sent/addressed by/to people from the company) and addressed 
to me goes to "personal".

Thank you for the comments!
Alexey

Cc: [email-masked], Kjetil Torgrim Homme <[email-masked]>, [email-masked]
Date: Wed, 09 Feb 2005 10:39:32 -0800 (PST)
From: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
To: Mark E Mallett <[email-masked]>
Sender: [email-masked]

> On Tue, Feb 08, 2005 at 04:28:06PM -0800, [email-masked] wrote:
> > Without setflag I would expect to see stuff of the form
> >
> >     set "foo" "";
> >     addflag "foo" "bar";

> Is the first line strictly necessary?  i.e. can you manipulate variables
> via addflag et al if those variables haven't been instantiated?

You can but it is beside the point. The issue is that the variable may
have been previously initialized to have some other value.

> I would think that you could.

You can, but again, that's beside the point.
 
> > Whether or not this savings warrants an entire action is a judgement call.
> > Having implemented it I can say that for me at least supporting setflag only
> > amounted to about 15 additional lines of code and one additional table entry.

> I think having extra stuff in the language is more the point than how
> hard it is to add that extra stuff.  I would also prefer not to have
> verbs that aren't really needed.

Implementation difficulty is definitely a factor to consider IMO, as is whether
or not the verb will actually be used. Stuff that's hard to implement increases
the liklihood of bugs, as does having stuff that's rarely used (rarely used
code is often a place where bugs lurk).

This, BTW, is why I'm basically opposed to the proposals to add associative
arrays to the language. Implementation of such facilities is going to be
complex and since it will have to be a separate extension the odds of it
being widely used are low. This is a recipe for bugs, and when you consider
that there are other ways to do all of this...

				Ned

Date: Wed, 09 Feb 2005 17:51:25 +0000
From: Alexey Melnikov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Sender: [email-masked]

Mark E. Mallett wrote:

>On Tue, Feb 08, 2005 at 04:28:06PM -0800, [email-masked] wrote:
>  
>
>>Without setflag I would expect to see stuff of the form
>>
>>    set "foo" "";
>>    addflag "foo" "bar";
>>    
>>
>
>Is the first line strictly necessary?  i.e. can you manipulate variables
>via addflag et al if those variables haven't been instantiated?
>I would think that you could.
>  
>
I guess you are right (assuming the script writer is not reusing the 
variable "foo"), but I am not sure I approve this as a good script 
writing technique.

>>Whether or not this savings warrants an entire action is a judgement call.
>>Having implemented it I can say that for me at least supporting setflag only
>>amounted to about 15 additional lines of code and one additional table entry.
>>    
>>
>
>I think having extra stuff in the language is more the point than how
>hard it is to add that extra stuff.  I would also prefer not to have
>verbs that aren't really needed.
>  
>
I prefer to have "setflag" for consistency.

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 9 Feb 2005 12:07:21 -0500
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Sender: [email-masked]

Some more random comments.

1. Introduction

   > This extension depends on the presence of "variables" extension
   > [Variables].

Should you mention that this isn't an automatic dependency?  i.e.
that the script writer still has to require variables?

> <<Extension name has been changed as revision 03 of this document is widely
> deployed in CMU Cyrus server>>

Isn't this problematic in terms of the relationship between drafts
and implementations?

2.1. General requirements for flag handling

   >  A string
   > containing a space separated list of flags ...

nit:  "space-separated"
(repeat for other occurances in the document)

   > If a flag validity check fails the flag should be silently
   > dropped, but a warning message should be logged by the Sieve interpreter.

nit one:  I would say "ignored" since "dropped" could be read as
"removed from the message" rather than "not paid attention to in the
Sieve statement."  (Even though the flag wouldn't be associated with the
message if it's invalid: but I'm talking English grammar here, not
logic.)

nit two:  I would use a word other than "logged" -- warnings may
be issued in other ways than logging.

nit three: should "should" be "SHOULD" ?

nit four: if the error should be reported, in what way is it silently
ignored?

3. Actions

   > The "set" action
   > defined in [Variables] can be used to replaces an existing set of flags
   > with a new set as well.

nit: "replace" (instead of "replaces")

3.1. Setflag Action

        > if header :contains "from" "[email-masked]" {

Prohibition on using real domain names in documents?  (i.e.,
"example.edu")  Repeat for other occurances in the document.

4.  Test hasflag

I'm having a hard time understanding what this test does in other than
simple cases.  

   > The "hasflag" test evaluates to true if any of the variables matches any
   > flag name.

Does this mean "contains any of the flags listed in list-of-flags" ?
or "contains all of the flags listed in list-of-flags"?
or "matches (according to match-type) the concatenation of flags
contained in all of the list-of-flags strings, subject to canonical
re-ordering"?

Does each string in "list-of-flags" contain exactly one flag, or can
each string be a list of flags as in other usage?

Perhaps more examples would help.

6. Implementation Notes

   > "addflag <variable> <flag>" can be implemented as:
   > 
   >  if not string :matches :comparator "i;ascii-casemap"
   >     " ${<variable>} " "* <flag> *" {
   >      set <variable> "${<variable>} <flag>"
   >  }

Note that you'll get a superfluous leading space if <variable> starts
out empty.  Probably doesn't need saying, though, except that the
following "removeflag" example goes to great pains to remove leading
and trailing spaces.

   > "removeflag <variable> <flag>" can be implemented as:
   > 
   >  if string :matches :comparator "i;ascii-casemap" " ${<variable>} "
   >     "* <flag> *" {
   >      set <variable> "${1}${2}";
   >  }

Should be "${1} ${2}", no?

10. Extended example

   > elsif anyof (not address :all :contains
   >                ["To", "Cc"] "[email-masked]",
   >              header :matches "subject"
   >                ["*make*money*fast*", "*university*dipl*mas*"])
   >         {
   >         remove "MyFlags" "\\Flagged";
   >         # If message header does not contain my address,
   >         # it's from a list.
   >         fileinto :flags "${MyFlags}" "spam";   # move to "spam" folder
   >         }
   > else
   >         {
   >         # Move all other (non-company) mail to "personal"
   >         # folder.

My eyes may be glazing over, but have we really established
"non-company" mail at this point?  One of the ways we get here
is if "to" or "cc" contain "[email-masked]"

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 9 Feb 2005 12:00:56 -0500
To: [email-masked]
Cc: Kjetil Torgrim Homme <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Sender: [email-masked]

On Tue, Feb 08, 2005 at 04:28:06PM -0800, [email-masked] wrote:
> Without setflag I would expect to see stuff of the form
> 
>     set "foo" "";
>     addflag "foo" "bar";

Is the first line strictly necessary?  i.e. can you manipulate variables
via addflag et al if those variables haven't been instantiated?
I would think that you could.

> Whether or not this savings warrants an entire action is a judgement call.
> Having implemented it I can say that for me at least supporting setflag only
> amounted to about 15 additional lines of code and one additional table entry.

I think having extra stuff in the language is more the point than how
hard it is to add that extra stuff.  I would also prefer not to have
verbs that aren't really needed.

mm

Date: Wed, 09 Feb 2005 14:03:23 +0000
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Sender: [email-masked]

Kjetil Torgrim Homme wrote:

>On Wed, 2005-02-09 at 11:35 +0000, Alexey Melnikov wrote:
>  
>
>>Kjetil Torgrim Homme wrote:
>>    
>>
>>>the default comparator is always "i;ascii-casemap", so it can be omitted
>>>      
>>>
>>>from the examples.
>>
>>"i;ascii-casemap" is not used in examples, it is used in the
>>Implementation Notes section, where it is required.
>>    
>>
>I don't think so.
>
>RFC 3028, 2.7.3.   Comparators
>   [...]
>   All implementations MUST support the "i;octet" comparator (simply
>   compares octets) and the "i;ascii-casemap" comparator (which treats
>   uppercase and lowercase characters in the ASCII subset of UTF-8 as
>   the same).  If left unspecified, the default is "i;ascii-casemap".
>  
>
Fine :-). I certainly didn't remember this, so I don't think it hurts to 
be explicit.

Alexey

Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Wed, 09 Feb 2005 14:50:00 +0100
Sender: [email-masked]

On Wed, 2005-02-09 at 11:35 +0000, Alexey Melnikov wrote:
> Kjetil Torgrim Homme wrote:
> >the default comparator is always "i;ascii-casemap", so it can be omitted
> >from the examples.
>
> "i;ascii-casemap" is not used in examples, it is used in the
> Implementation Notes section, where it is required.

I don't think so.

RFC 3028, 2.7.3.   Comparators
   [...]
   All implementations MUST support the "i;octet" comparator (simply
   compares octets) and the "i;ascii-casemap" comparator (which treats
   uppercase and lowercase characters in the ASCII subset of UTF-8 as
   the same).  If left unspecified, the default is "i;ascii-casemap".

-- 
Kjetil T.

Date: Wed, 09 Feb 2005 11:35:43 +0000
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Sender: [email-masked]

Kjetil Torgrim Homme wrote:

>a few comments:
>
>the default comparator is always "i;ascii-casemap", so it can be omitted
>from the examples.
>  
>
"i;ascii-casemap" is not used in examples, it is used in the Implementation Notes section, where it is required.

Cc: [email-masked]
Date: Tue, 08 Feb 2005 16:28:06 -0800 (PST)
From: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
To: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

> a few comments:

> the default comparator is always "i;ascii-casemap", so it can be omitted
> from the examples.

> the actions and tests allows a list of flags to be specified as a space
> delimited string.  I assume this is intended to allow variable
> references.  e.g.:

>   set "s" "\\Answered Closed";
>   setflag "f" ["${s}", "\\Deleted"];
>   if hasflag "${f}" "${s}" ...

> do we really need "setflag"?  it is equivalent with "set", except it
> allows some syntax checking of the arguments,

And possibily duplicate elimination and reordering.

> but as you can see above,
> it can't really do much of it statically anyhow.

Yes, but runtime checking is possible.

> I think most users
> will use "addflag" almost exclusively.

Without setflag I would expect to see stuff of the form

    set "foo" "";
    addflag "foo" "bar";

Whether or not this savings warrants an entire action is a judgement call.
Having implemented it I can say that for me at least supporting setflag only
amounted to about 15 additional lines of code and one additional table entry.

				Ned

Subject: Re: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Wed, 09 Feb 2005 00:29:33 +0100
Sender: [email-masked]

a few comments:

the default comparator is always "i;ascii-casemap", so it can be omitted
from the examples.

the actions and tests allows a list of flags to be specified as a space
delimited string.  I assume this is intended to allow variable
references.  e.g.:

  set "s" "\\Answered Closed";
  setflag "f" ["${s}", "\\Deleted"];
  if hasflag "${f}" "${s}" ...

do we really need "setflag"?  it is equivalent with "set", except it
allows some syntax checking of the arguments, but as you can see above,
it can't really do much of it statically anyhow.  I think most users
will use "addflag" almost exclusively.

-- 
Kjetil T.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-rfc3598bis-00.txt
Date: Tue, 08 Feb 2005 15:40:40 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering -- Subaddress Extension
	Author(s)	: K. Murchison
	Filename	: draft-ietf-sieve-rfc3598bis-00.txt
	Pages		: 12
	Date		: 2005-2-8
	
On email systems that allow for "subaddressing" or "detailed
   addressing" (e.g., "[email-masked]"), it is sometimes
   desirable to make comparisons against these sub-parts of addresses.
   This document defines an extension to the Sieve mail filtering
   language that allows users to compare against the user and detail
   parts of an address.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-rfc3598bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-rfc3598bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-rfc3598bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-rfc3598bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-imapflags-00.txt
Date: Tue, 08 Feb 2005 15:40:25 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: IMAP flag Extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sieve-imapflags-00.txt
	Pages		: 0
	Date		: 2005-2-8
	
Recent discussions have shown that it is desirable to set different [IMAP] flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting [IMAP] flags. The extension allows to set both [IMAP] system flags and [IMAP] keywords.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-imapflags-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-imapflags-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-imapflags-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-imapflags-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 8 Feb 2005 15:26:30 -0500
To: Nigel Swinson <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: spamtestbis
Sender: [email-masked]

On Mon, Feb 07, 2005 at 02:19:47PM -0000, Nigel Swinson wrote:
> > BTW I think this is the kind of extension that could be solved with
> > better fundamental language elements and/or better coordination between
> > language extensions.
> > 
> > For example, one could build on the proposed "variables" extension by
> > imagining a new set of read-only variables within specific namespaces
> > (per the old namespace idea, a la dates and timezones).  Imagine:
> > 
> >    require "variables";
> >    require [ "relational", "comparator-i;ascii-numeric" ];
> > 
> >    set "spamval" "${spamtest::value}"
> >    set "spampct" "${spamtest::pctvalue}"
> >    set "spamtext" "${spamtest::text}"
> > 
> >    if string :value "ge"
> >              :comparator "i;ascii-numeric"
> >      "${spamval}" "3" { ... }
> >    if string :value "ge"
> >              :comparator "i;ascii-numeric"
> >              "${spamtest::pctvalue}" "30" { ... }
> > 
> > Time travel might be required though.
> 
> Or better still why not just refer to the variables direct in the string test?
> 
>     if string :value "ge"
>               :comparator "i;ascii-numeric"
>               "${spamtest.value}" "3" { ... }

My second example quoted above had that (but with improper namespace
syntax-- somehow I thought that namespaces had been removed and
completely glossed over them in the latest variables draft).

> One problem here is that it costs resources to obtain the spam score
> and virus score, and part of the reason you might be using sieve would
> be to refine which messages would result in those resources being used
> up.  So you might still want to somehow specify or recommend that the
> implementation make the variables in the namespace available in a lazy
> fashion.

Indeed, that's what I had in mind as well in that particular example.

mm

Cc: [email-masked], Kjetil Torgrim Homme <[email-masked]>, [email-masked]
Date: Tue, 08 Feb 2005 09:35:18 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve-Notify and potential associative arrays.
To: Nigel Swinson <[email-masked]>
Sender: [email-masked]

> > > I don't think it is meaningful to add a general function.  consider
> > > SETDATE, which had an optional parameter for the timezone.

> > I agree. The need for extension-specific parameters makes a general
> > function infeasible.

> <snip>

> > I agree here as well. The cost of doing what's necessary to bind a fair
> > number of different variables to a set of values is the only thing that
> > makes this whole idea somewhat attractive. But the code of binding
> > one or two variables, which is what you'd have in the case of spamtest
> > or virustest, is so short that I just don't see the need for a separate
> > variable binding action.

> Great, well as you can guess I'd much rather these variables were just made
> available, and we didn't need a setvariables, so where are we now?

My position is that none of this is really needed, but if we have to have it
needs to take the form of a separate extension or set of extensions to define 
the needed actions to set the variables. Additionally, the only case I've seen
where I view the marginal utility as being being sufficient to bother is the
that of setheadervariables (or whatever you want to call it).

> Are we
> saying that spamtest should be revised to specify that it defines certain
> variables in a spamtest namespace, and we have a new extension that if
> requested makes a list of message attributes available as variables, and we
> don't need any special action to ask that they be initialised?

Absolutely not. IMO none of this has any business being added to spamtest.
Let's please remember that spamtest is defined in a standards-track RFC, and
any enhancements to it have to be done as a separate extension. It could
be incorporated into a revised RFC as a separate extension, but again,
I don't think the benefits in the case of spamtest are really there.

> Instead
> sensible implementations will only evaluate costly variables in a lazy
> fashion so as to avoid resource overhead?

> So my SMS string has become:
>  set "Message" "[To: {$header.to} From: ${header.from}] ${header.subject}"
> And my "magic string" has become:
>  addheader "X-Spam-Score" "${spamscore.score}";

I don't see any variable setting actions here, so this is IMO incomplete.

				Ned

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>, "Kjetil Torgrim Homme" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Tue, 8 Feb 2005 17:11:53 -0000
Sender: [email-masked]

>> I don't think it is meaningful to add a general function.  consider
>> SETDATE, which had an optional parameter for the timezone.
>
> I agree. The need for extension-specific parameters makes a general 
> function
> infeasible.
<snip>
> I agree here as well. The cost of doing what's necessary to bind a fair
> number of different variables to a set of values is the only thing that
> makes this whole idea somewhat attractive. But the code of binding
> one or two variables, which is what you'd have in the case of spamtest
> or virustest, is so short that I just don't see the need for a separate
> variable binding action.

Great, well as you can guess I'd much rather these variables were just made 
available, and we didn't need a setvariables, so where are we now?  Are we 
saying that spamtest should be revised to specify that it defines certain 
variables in a spamtest namespace, and we have a new extension that if 
requested makes a list of message attributes available as variables, and we 
don't need any special action to ask that they be initialised?  Instead 
sensible implementations will only evaluate costly variables in a lazy 
fashion so as to avoid resource overhead?

So my SMS string has become:
 set "Message" "[To: {$header.to} From: ${header.from}] ${header.subject}"
And my "magic string" has become:
 addheader "X-Spam-Score" "${spamscore.score}";

?

Nigel 

Cc: Nigel Swinson <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 08 Feb 2005 08:45:58 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve-Notify and potential associative arrays.
To: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

> On Tue, 2005-02-08 at 11:02 +0000, Nigel Swinson wrote:
> > Ok, so what if we have an action which requests certain variables
> > associated with an extension to be made available in it's namespace.
> >
> >    setvariables <extension-name: string> [<list-of-variables: string-list>]
> >
> > If you don't supply a list of variables that you want access to, it
> > will activate all variables the extension defines, else it will only
> > activate the list of variables that you were interested in.  This
> > might help with the issue of only wanting to use processing resources
> > (av/as?) for some messages.

> the analysis of the script to find the variables actually used is so
> trivial I don't think it is worthwhile to burden the script writer with
> replicating it.

> I don't think it is meaningful to add a general function.  consider
> SETDATE, which had an optional parameter for the timezone.

I agree. The need for extension-specific parameters makes a general function
infeasible.

> for many extensions, I don't think an explicit action is needed, and in
> my view that includes the spamscore extension.  there is one advantage
> to doing it, though.  if you require only "spamscore", and not
> "variables", strings like "${spamscore.value}" will still be legal, they
> will just not be interpreted.  a separate extension name which makes a
> setter function available may make such errors less likely.

I agree here as well. The cost of doing what's necessary to bind a fair
number of different variables to a set of values is the only thing that
makes this whole idea somewhat attractive. But the code of binding
one or two variables, which is what you'd have in the case of spamtest
or virustest, is so short that I just don't see the need for a separate
variable binding action.

				Ned

Subject: Re: Sieve-Notify and potential associative arrays.
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Tue, 08 Feb 2005 16:18:13 +0100
Sender: [email-masked]

On Tue, 2005-02-08 at 11:02 +0000, Nigel Swinson wrote:
> Ok, so what if we have an action which requests certain variables
> associated with an extension to be made available in it's namespace.
> 
>    setvariables <extension-name: string> [<list-of-variables: string-list>]
> 
> If you don't supply a list of variables that you want access to, it
> will activate all variables the extension defines, else it will only
> activate the list of variables that you were interested in.  This
> might help with the issue of only wanting to use processing resources
> (av/as?) for some messages.

the analysis of the script to find the variables actually used is so
trivial I don't think it is worthwhile to burden the script writer with
replicating it.

I don't think it is meaningful to add a general function.  consider
SETDATE, which had an optional parameter for the timezone.

for many extensions, I don't think an explicit action is needed, and in
my view that includes the spamscore extension.  there is one advantage
to doing it, though.  if you require only "spamscore", and not
"variables", strings like "${spamscore.value}" will still be legal, they
will just not be interpreted.  a separate extension name which makes a
setter function available may make such errors less likely.
-- 
Kjetil T.

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Tue, 8 Feb 2005 11:02:53 -0000
Sender: [email-masked]

> > Slightly better, but still a bit ugly...  Perhaps instead define some new
> > action who's sole purpose is to populate the spamscore or header namespace.
> 
> That's a much better idea, actually. I could live with this approach.
> Something like:
> 
>    headervariables list-of-header-fields
> 
> We could even make the "header." prefix settable.

Ok, so what if we have an action which requests certain variables associated with an extension to be made available in it's namespace.

   setvariables <extension-name: string> [<list-of-variables: string-list>]

If you don't supply a list of variables that you want access to, it will activate all variables the extension defines, else it will only activate the list of variables that you were interested in.  This might help with the issue of only wanting to use processing resources (av/as?) for some messages.

If we were all happy with this approach, it would seem to me to be a good addition to the variables spec?

Nigel

Cc: [email-masked], [email-masked]
Date: Mon, 07 Feb 2005 15:25:28 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve-Notify and potential associative arrays.
To: Nigel Swinson <[email-masked]>
Sender: [email-masked]

> >> Actually I think what I'm proposing will make it easier for a gui, not
> >> harder.
> >
> > Perhaps in this specific case, but in general, no. The problem with  the
> > idea
> > of having "special" variables show up is that it won't be limited to
> > accessing
> > the header. You yourself used the notion of extending it to spamtest. This
> > sort of thing requires fairly deep knowledge of each extension in the GUI.

> I can see it's a nice goal to have a generic gui for building any old sieve
> script, but I don't think we can really get away from having to do some
> development work for each extension to make it available more neatly to the
> user.

For seamless integration, sure, but it would really be nice if basic
integration didn't require such in-depth knowledge.

> > I'd much rather have the binding from various information sources to
> > variables be explicit. It may not be possible to present this sort of
> > thing in a very pretty way, but at least it should be possible to
> > accmodate
> > extensions more easily.

> Could we instead say that the spamscore namespace is populated after the
> first instance of using the spamtest test?

This makes some things better, others worse. Better in the sense that
at least the variables aren't quite as magic. Worse in the sense that 
it creates a magic side effect.

> That would make my magic string:

> if spamtest :matches "*" {}
> addheader "X-Spam-Score" "${spamscore.score}";

> Slightly better, but still a bit ugly...  Perhaps instead define some new
> action who's sole purpose is to populate the spamscore or header namespace.

That's a much better idea, actually. I could live with this approach.
Something like:

   headervariables list-of-header-fields

We could even make the "header." prefix settable.

> Something like the getdate (?) action from a much earlier revision of the
> variables spec?

I believe it was setdate, but yes, I found the setdate thing to be fairly
reasonable.

> >> I've had to solve this in the past by having large "magic strings" like
> >> this:
> >
> >>  if spamtest :matches :comparator "i;ascii-numeric" "*" {set "spamscore"
> >> "${1}";}
> >>  addheader "X-Spam-Score" "${spamscore}";
> >
> > Which I think is fine.
> >
> >> Where the presence or absence of the entire two lines is controlled by a
> >> checkbox.  It would have been much easier if I had a ${spamscore.score}
> >> or a
> >> ${MESSAGE['SpamScore']} available to me.
> >
> > Yeech. This is exactly the sort of thing I think we need to avoid at all
> > costs.

> If you like my existing magic string, then you could rephrase my request to
> say that I'd like to change my magic string to just:

>   addheader "X-Spam-Score" "${spamscore.score}";

> What's Yeech about that?  It's less than half the syntax and the intent is
> much clearer.

The issue was more the array notation and the creep into multiple extensions.

				Ned

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-variables-01.txt
Date: Mon, 07 Feb 2005 15:46:59 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Mail Filtering Language: Variables Extension
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-01.txt
	Pages		: 14
	Date		: 2005-2-4
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-variables-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-variables-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-variables-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-variables-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-editheader-00.txt
Date: Mon, 07 Feb 2005 15:46:48 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Mail Filtering Language: Editheader Extension
	Author(s)	: J. Degener, P. Guenther
	Filename	: draft-ietf-sieve-editheader-00.txt
	Pages		: 0
	Date		: 2005-2-7
	
This document defines two new actions for the "sieve"
   language that add and delete email header fields.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-editheader-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-editheader-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-editheader-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-editheader-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-body-00.txt
Date: Mon, 07 Feb 2005 15:46:14 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Mail Filtering Language: Body Extension
	Author(s)	: J. Degener, P. Guenther
	Filename	: draft-ietf-sieve-body-00.txt
	Pages		: 0
	Date		: 2005-2-7
	
This document defines a new primitive for the "Sieve" email filtering
   language that tests for the occurrence of one or more strings in the
   body of an email message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-body-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-body-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-body-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-body-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Mon, 7 Feb 2005 18:33:05 -0000
Sender: [email-masked]

>> Actually I think what I'm proposing will make it easier for a gui, not
>> harder.
>
> Perhaps in this specific case, but in general, no. The problem with  the 
> idea
> of having "special" variables show up is that it won't be limited to 
> accessing
> the header. You yourself used the notion of extending it to spamtest. This
> sort of thing requires fairly deep knowledge of each extension in the GUI.

I can see it's a nice goal to have a generic gui for building any old sieve 
script, but I don't think we can really get away from having to do some 
development work for each extension to make it available more neatly to the 
user.

> I'd much rather have the binding from various information sources to
> variables be explicit. It may not be possible to present this sort of
> thing in a very pretty way, but at least it should be possible to 
> accmodate
> extensions more easily.

Could we instead say that the spamscore namespace is populated after the 
first instance of using the spamtest test?  That would make my magic string:

if spamtest :matches "*" {}
addheader "X-Spam-Score" "${spamscore.score}";

Slightly better, but still a bit ugly...  Perhaps instead define some new 
action who's sole purpose is to populate the spamscore or header namespace. 
Something like the getdate (?) action from a much earlier revision of the 
variables spec?

>> I've had to solve this in the past by having large "magic strings" like 
>> this:
>
>>  if spamtest :matches :comparator "i;ascii-numeric" "*" {set "spamscore" 
>> "${1}";}
>>  addheader "X-Spam-Score" "${spamscore}";
>
> Which I think is fine.
>
>> Where the presence or absence of the entire two lines is controlled by a
>> checkbox.  It would have been much easier if I had a ${spamscore.score} 
>> or a
>> ${MESSAGE['SpamScore']} available to me.
>
> Yeech. This is exactly the sort of thing I think we need to avoid at all
> costs.

If you like my existing magic string, then you could rephrase my request to 
say that I'd like to change my magic string to just:

  addheader "X-Spam-Score" "${spamscore.score}";

What's Yeech about that?  It's less than half the syntax and the intent is 
much clearer.

Nigel 

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Mon, 7 Feb 2005 18:33:02 -0000
Sender: [email-masked]

> I think we agreed previously that 3028bis should be more explicit about
> the meaning of wildcards in the argument to :matches. I think it is
> non-controversial, though, nobody would expect "abc" to match "b*".

That's a good example, thanks :o)

> I would prefer the list of supported header names was explicit, though,
> so that the extension could do the relevant decoding for the user.
> notice that I omitted the number suffix for header.date, since RFC 2822
> explicitly says there should be 1 and only 1 "Date" header.

But all headers are subject to RFC2047 and unwrapping aren't they?  If we 
explicitly list all headers available in the header scope, then that means 
when somebody decides to use a new X- header or something like that, then 
they would need to write their own Sieve extension to make it available in 
the/another namespace.  This sounds overburdensome to me.  While I recognise 
that the standard says that there are limits on certain headers like the 
Data header, I think I'd much rather have the header "namespace" or array or 
whatever generically hold all 2822 headers.

If there is some extra parsing or meaning to a particular header, then I 
could see we could define a new namespace to access the headers in the more 
specific way with access to the more specific parsing.  Perhaps:

headers.content-type = "TEXT/PLAIN; charset=Windows-1252"
mimeheaders.content-type.type = "TEXT"
mimeheaders.content-type.subtype = "PLAIN"
mimeheaders.content-type.charset = "Windows-1252"

> > I think it preferable to allow array syntax instead of variables
> > starting with numbers.
>
> I'm afraid I don't see that happening, the variables draft is too close
> publication for such a change to the syntax.

So you are saying you'd prefer us to publish variables, then later realise 
we needed this and have to have another standard or revision to allow us to 
use array notation?  I guess this is heading in the direction of Mark's 
comments, now it seems we are talking about "stringvariables" not really 
generic variables which will meet all the languages needs.

I suppose I was hoping to hear some technical reasons for why we wouldn't 
want [] and rather have a completely non standard way of providing access to 
what is really an array.

> > If we were to do this then where would such a mechanism be specified?
> > 3028bis, variables, new draft? I'd love it to be available in the
> > variables spec...
>
> the namespace feature of the variables draft was specifically added to
> allow independent extensions to add "magic" variables.

Perhaps if we groups several generic namespaces together which apply to all 
messages then we'd have enough for another spec.  Perhaps headers, envelope, 
message, server?  It seems to be an excellent addition to the variables 
extension if you ask me, but I recognize that this would all take a while to 
hammer out.  I just hope we don't go with a variables spec which limits our 
choices when we get there :o(

Nigel 

Cc: [email-masked], [email-masked]
Date: Mon, 07 Feb 2005 08:31:14 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve-Notify and potential associative arrays.
To: Nigel Swinson <[email-masked]>
Sender: [email-masked]

> > This begs the question of whether or not complex header transformations are
> > something we should be doing with sieve. I happen to think the answer to this
> > particular question is "no".

> I agree.

> > Copying a subject and perhaps a couple of other
> > fields into a new message is about as far as I think sieve needs to go.

> I agree.  So the question is restated as should the set of "other fields" be
> predefined and fixed, or generic and able to cope with all current and future
> needs?  The existing $subject" strategy seems to make a very limited and fixed
> set of message attributes available, and I'm concerned that this isn't going to
> meet our future needs and barely meets our current needs.

Oops, I missed the fact that you were talking about the specific (and overly
limited) approach taken in the long-expired notification draft. I have been
assuming that the existing $subject strategy would vanish now that we have
variables. I regard it as much clear to do a

   if header :matches "subject" "*" {set "subject" "${0}"}
   else {set "subject" ""}

sort of thing than to have a couple of magic variables, or associative arrays
of headers for that matter.

> > Of course there are all sorts of more complex things people will want to do.
> > But this is a seriously slippery slope, because lurking not far away are
> > things like content summaries, keyword extraction, translation services,
> > content shaping, and so on. This stuff has "research problem" written all
> > over it, and IMO sieve needs to stay away from this space.

> Content summaries sound quite useful :o)

Yes, well, it seemed useful when I first heard a presentation on this general
area by Minski back in 1977. However, at the time I wasn't at all impressed by
the approaches being taken, and here it is, almost 30 years later, and look at
all the progress we've made. Personally, I'm not holding my breath...

> I suppose were they to stabalize then I'd like them to be made available
> through other Sieve extensions which would make new variables available to the
> script author for testing or use in creating new messages.

Again, I'm not holding my breath...

> > > Do you/we favour the $subject$ approach?
> >
> > I think it is just sufficient to get the jobs appropriate for sieve done.

> If we are to keep it then I hope we at least change it to ${subject} or
> ${headers.subject}

I'd rather get rid of it entirely and use variables instead.

> > > I guess I would accept some implementation complexity
> > > if it means the language is easier to use....
> >
> > Ease of use is a two-edged sword. One of the things sieve is used for is
> > as an output format for GUI filter builder utilities. Variables are already
> > pretty hard to handle in such tools, things like associative arrays
> > are really over the top.

> Actually I think what I'm proposing will make it easier for a gui, not
> harder.

Perhaps in this specific case, but in general, no. The problem with  the idea
of having "special" variables show up is that it won't be limited to accessing
the header. You yourself used the notion of extending it to spamtest. This
sort of thing requires fairly deep knowledge of each extension in the GUI.
I'd much rather have the binding from various information sources to
variables be explicit. It may not be possible to present this sort of
thing in a very pretty way, but at least it should be possible to accmodate
extensions more easily.

> I've had to solve this in the past by having large "magic strings" like this:

>  if spamtest :matches :comparator "i;ascii-numeric" "*" {set "spamscore" "${1}";}
>  addheader "X-Spam-Score" "${spamscore}";

Which I think is fine.

> Where the presence or absence of the entire two lines is controlled by a
> checkbox.  It would have been much easier if I had a ${spamscore.score} or a
> ${MESSAGE['SpamScore']} available to me.

Yeech. This is exactly the sort of thing I think we need to avoid at all
costs.

				Ned

Subject: Re: Sieve-Notify and potential associative arrays.
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: [email-masked]
Date: Mon, 07 Feb 2005 16:06:13 +0100
Sender: [email-masked]

On Mon, 2005-02-07 at 14:19 +0000, Nigel Swinson wrote:
> > > Each phone number must begin with a + and
> > > include the country code to ensure that the script will work
> > > regardless of location of server/script.
> > 
> > is it important to trap this at compile-time?
> 
> I think it's similair to the desire to catch invalid variable names at
> compile time.  So yes, I think so.

I agree it is desirable, and if we have mechanism specific keywords,
arguments should be syntax checked as much as possible.

> > > if header :matches "*" "To" {
> >
> > (you'll have to switch the arguments, it's header COMPARATOR header-name
> > pattern)

sorry, this should say "header MATCH-TYPE header-name pattern"

> Ug I never did find the order intuative...

it is intuitive if you use the default match-type ":is".  the
non-intuitive bit is the placement of the match-type, but it is a basis
for the syntax that all tagged arguments appear before positional
arguments.

> > greediness doesn't come into play here, as :matches "*" == :regex
> > "^(.*)$"
> 
> I'm happy that that is the case but is that obvious to everyone?  It
> wasn't obvious to me, and I don't recall reading that it was ever
> specified.  I think we have another thread on this topic though...

I think we agreed previously that 3028bis should be more explicit about
the meaning of wildcards in the argument to :matches.  I think it is
non-controversial, though, nobody would expect "abc" to match "b*".

> > > $HEADERS[‘Received’][0] = "from p01m168.mxlogic.net [bla bla] "
> > > $HEADERS[‘Received’][1] = "from unknown [208.184.76.39] [bla bla] "
> > > $HEADERS[‘Date’][0] = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"
> > 
> > this is just a different syntax for:
> > 
> > ${header.received.n1} = "from p01m168.mxlogic.net [bla bla] "
> > ${header.received.n2} = from unknown [208.184.76.39] [bla bla] "
> > ${header.date} = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"
> 
> Yes, I would have suggested that instead, but I suppose I wondered if
> such a mechanism would mean we'd have to predefine all header names
> we'd ever use.  I thought perhaps the use of the associative array
> made it clearer that the header might not actually exist in the email,
> and therefore cope with all future header names.

that's really for the extension to decide.  the variables draft doesn't
rule out having variables spring to life when referenced -- it only
specifies the syntax of the names.   how the variables inside a
namespace work is left for the extension to define.

I would prefer the list of supported header names was explicit, though,
so that the extension could do the relevant decoding for the user.
notice that I omitted the number suffix for header.date, since RFC 2822
explicitly says there should be 1 and only 1 "Date" header.

> > (the variables draft doesn't allow the last component of the variable
> > name to be a number.  I think that is an aspect we can change if we want
> > to, but it must be done now.)
> 
> I think it preferable to allow array syntax instead of variables
> starting with numbers.

I'm afraid I don't see that happening, the variables draft is too close
publication for such a change to the syntax.

> > anyhow, doing it via a namespace makes it more natural to present the
> > information in a parsed manner. e.g., you could have an
> > header.date.year == "2005" in addition.
> 
> Indeed, that might work neatly!
> 
> If we were to do this then where would such a mechanism be specified?
> 3028bis, variables, new draft?  I'd love it to be available in the
> variables spec...

the namespace feature of the variables draft was specifically added to
allow independent extensions to add "magic" variables.
-- 
Kjetil T.

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Mon, 7 Feb 2005 14:19:50 -0000
Sender: [email-masked]

> as a general point, I think it's not worthwhile to standardise
> specifically on SMS. it's not _that_ universal, and it's also being
> phased out by MMS, which is just good old MIME documents (transported by
> HTTP for the last hops, but SMTP for routing).

I don't yet know enough about MMS sadly to make comment :o(

> a limit on message length is a good option to add, but it shouldn't be
> based on SMS chunk size.

Why are they setting a limit though?  Partly due to how much text they want to scroll through, but more todo with how much it's going to cost them.  Isn't it the standardised SMS chunk size the root of the cost for SMS just now? If we make the limit based on message length, then we require that our users have some knowledge of how long a message they can have for one SMS chunk and therefore keep their costs down.

> > Each phone number must begin with a + and
> > include the country code to ensure that the script will work
> > regardless of location of server/script.
> 
> is it important to trap this at compile-time?

I think it's similair to the desire to catch invalid variable names at compile time.  So yes, I think so.

> > if header :matches "*" "To" {
> > set "Recipient" "${1}"
> > }
> > if header :matches "*" "From" {
> > set "Sender" "${1}"
> > }
> > if header :matches "*" "Subject" {
> > set "Subject" "${1}"
> > }
> > set "Message" "[To: {$Recipient} From: {$Sender}] {$Subject}"
> 
> (you'll have to switch the arguments, it's header COMPARATOR header-name
> pattern)

Ug I never did find the order intuative...

> > (I note that my intuative use of * won't work cos * in matches
> > according to variables is non-greedy, yet * with regex is greedy, but
> > I thought I'd do that deliberately to make you think...)
> 
> greediness doesn't come into play here, as :matches "*" == :regex
> "^(.*)$"

I'm happy that that is the case but is that obvious to everyone?  It wasn't obvious to me, and I don't recall reading that it was ever specified.  I think we have another thread on this topic though...
 
> > $HEADERS[‘Received’][0] = "from p01m168.mxlogic.net [bla bla] "
> > $HEADERS[‘Received’][1] = "from unknown [208.184.76.39] [bla bla] "
> > $HEADERS[‘Date’][0] = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"
> 
> this is just a different syntax for:
> 
> ${header.received.n1} = "from p01m168.mxlogic.net [bla bla] "
> ${header.received.n2} = from unknown [208.184.76.39] [bla bla] "
> ${header.date} = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"

Yes, I would have suggested that instead, but I suppose I wondered if such a mechanism would mean we'd have to predefine all header names we'd ever use.  I thought perhaps the use of the associative array made it clearer that the header might not actually exist in the email, and therefore cope with all future header names.

> (the variables draft doesn't allow the last component of the variable
> name to be a number.  I think that is an aspect we can change if we want
> to, but it must be done now.)

I think it preferable to allow array syntax instead of variables starting with numbers.

> anyhow, doing it via a namespace makes it more natural to present the
> information in a parsed manner. e.g., you could have an
> header.date.year == "2005" in addition.

Indeed, that might work neatly!

If we were to do this then where would such a mechanism be specified?  3028bis, variables, new draft?  I'd love it to be available in the variables spec...

Nigel

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Mon, 7 Feb 2005 14:19:48 -0000
Sender: [email-masked]

> This begs the question of whether or not complex header transformations are
> something we should be doing with sieve. I happen to think the answer to this
> particular question is "no". 

I agree.

> Copying a subject and perhaps a couple of other
> fields into a new message is about as far as I think sieve needs to go.

I agree.  So the question is restated as should the set of "other fields" be predefined and fixed, or generic and able to cope with all current and future needs?  The existing $subject" strategy seems to make a very limited and fixed set of message attributes available, and I'm concerned that this isn't going to meet our future needs and barely meets our current needs.

> Of course there are all sorts of more complex things people will want to do.
> But this is a seriously slippery slope, because lurking not far away are
> things like content summaries, keyword extraction, translation services,
> content shaping, and so on. This stuff has "research problem" written all
> over it, and IMO sieve needs to stay away from this space.

Content summaries sound quite useful :o)  I suppose were they to stabalize then I'd like them to be made available through other Sieve extensions which would make new variables available to the script author for testing or use in creating new messages.

> > Do you/we favour the $subject$ approach?
> 
> I think it is just sufficient to get the jobs appropriate for sieve done.

If we are to keep it then I hope we at least change it to ${subject} or ${headers.subject}

> > I guess I would accept some implementation complexity
> > if it means the language is easier to use....
> 
> Ease of use is a two-edged sword. One of the things sieve is used for is
> as an output format for GUI filter builder utilities. Variables are already
> pretty hard to handle in such tools, things like associative arrays
> are really over the top.

Actually I think what I'm proposing will make it easier for a gui, not harder.  I'm imagining a gui with checkboxes along these lines:

Send an SMS to your phone including the following attributes:
- Sender
- Subject
- Message Body
- Spam Score
- Priority

Then depending on which checkboxes were ticked would change what message string we authored, where the checkbox would either add or remove a $HEADERS['Subject'] from the message string.  Without this kind of mechanism, we have to not only add the string to the message, but also use a header test before hand to make sure we have that variable available to us to use in this message.  

I've had to solve this in the past by having large "magic strings" like this:

 if spamtest :matches :comparator "i;ascii-numeric" "*" {set "spamscore" "${1}";}
 addheader "X-Spam-Score" "${spamscore}";

Where the presence or absence of the entire two lines is controlled by a checkbox.  It would have been much easier if I had a ${spamscore.score} or a ${MESSAGE['SpamScore']} available to me.

I would doubt that any gui builder out there can handle every corner case of every part of Sieve, but rather makes the most useful subset available to the user and surrenders to a text editor if the nesting/syntax goes beyond the scope of what can be easily communicated through form controls.

Nigel

From: "Nigel Swinson" <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: "IETF MTA Filters List" <[email-masked]>
Subject: Re: spamtestbis
Date: Mon, 7 Feb 2005 14:19:47 -0000
Sender: [email-masked]

> BTW I think this is the kind of extension that could be solved with
> better fundamental language elements and/or better coordination between
> language extensions.
> 
> For example, one could build on the proposed "variables" extension by
> imagining a new set of read-only variables within specific namespaces
> (per the old namespace idea, a la dates and timezones).  Imagine:
> 
>    require "variables";
>    require [ "relational", "comparator-i;ascii-numeric" ];
> 
>    set "spamval" "${spamtest::value}"
>    set "spampct" "${spamtest::pctvalue}"
>    set "spamtext" "${spamtest::text}"
> 
>    if string :value "ge"
>              :comparator "i;ascii-numeric"
>      "${spamval}" "3" { ... }
>    if string :value "ge"
>              :comparator "i;ascii-numeric"
>              "${spamtest::pctvalue}" "30" { ... }
> 
> Time travel might be required though.

Or better still why not just refer to the variables direct in the string test?

    if string :value "ge"
              :comparator "i;ascii-numeric"
              "${spamtest.value}" "3" { ... }
    if string :value "ge"
              :comparator "i;ascii-numeric"
              "${spamtest.pctvalue}" "30" { ... }

This is certainly on a similar tack to my post relating to associative arrays and sms notification, so unsurprisingly I would really like to see something along these lines, but I'm not sure how we get there.  Indeed  I think it's this kind of thing that gives the variables extension a large amount of it's value.  The variables spec does make reference to:

   Namespaces are meant for future extensions which make internal state
   available through variables.  These variables SHOULD be put in a
   namespace with the same name as its capability string.  Notice that
   the user can not specify a namespace when setting variables with SET.

I wondered if we would therefore say things like if you require "spamtest", then a namespace called spamtest would be defined containing variables called value and text which contain etc.  It then seems to make sense to specify in the spamtest spec what variables it would define.  Do we have time to add such a section to spamtestbis?

One problem here is that it costs resources to obtain the spam score and virus score, and part of the reason you might be using sieve would be to refine which messages would result in those resources being used up.  So you might still want to somehow specify or recommend that the implementation make the variables in the namespace available in a lazy fashion.

Nigel

Subject: Re: Sieve-Notify and potential associative arrays.
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: [email-masked]
Date: Mon, 07 Feb 2005 01:10:53 +0100
Sender: [email-masked]

On Wed, 2005-02-02 at 02:21 +0000, Nigel Swinson wrote:
> It seems to me that the notify extension is trying to do too much in
> supporting notification by email, SMS or indeed any arbitrary
> notification mechanism.  It was pointed out quickly how many complex
> internationalization issues you have to deal with when composing
> emails, but you have completely different concerns when dealing with
> SMS messages, so I'm not sure it makes sense to bundle them.  I think
> we should therefore have something more along these lines:
> 
> Syntax:   sms [":recipient" <recipient-numbers: string-list>] [:limit <number>] <message: string>

as a general point, I think it's not worthwhile to standardise
specifically on SMS.  it's not _that_ universal, and it's also being
phased out by MMS, which is just good old MIME documents (transported by
HTTP for the last hops, but SMTP for routing).

a limit on message length is a good option to add, but it shouldn't be
based on SMS chunk size.

> The :recipient tag specifies the target phone numbers to send this SMS
> to.  If not present, the implementation should try to send the SMS to
> the owner of the script where the number is held by the sieve
> implementation, ie a mailbox property.  If present, specifies the
> target number, and it can also be a list of numbers if more than one
> recipient is desired.  Each phone number must begin with a + and
> include the country code to ensure that the script will work
> regardless of location of server/script.

is it important to trap this at compile-time?

> The proposal in draft-ietf-sieve-notify-02.txt is this:
>  
>     Syntax:   notify [":method" string]
>                [":id" string]
>                [":options" 1*(string-list / number)]
>                [<":low" / ":normal" / ":high">]
>                ["message:" string]
> 
> I'm thinking it's got too many things in it which are trying to be
> super-generic to cover all uses (:method/:id/:options), but in actual
> fact we'll quickly regret this and prefer specific extensions for
> notifying through different channels with well defined and well
> documented arguments.

you may be right.  separate extension names for each notify method may
be the way to go.  how many methods are we talking about?  we've been
loosely discussing a Jabber notification method where I work.  (SMS/MMS
costs money :)

> Which brings me on to variables.  Each of these different notification
> types, and also the vacation extension to a certain degree, has the
> need to author messages, and likely include sections of the triggering
> message.  So suppose I want to author what I think is a fairly
> reasonable SMS which looks like this:
>            [To:<recipient-addresss>From:<sender-address>] <Subject>\r\n<body>
> 
> One way to get his is using the proposed $name$ variables which seem
> pretty ugly next to what we've worked so hard on with the variables
> extension, and also is pretty inflexible.  If we use the variables
> extension as is, then we could do this:
> 
> if header :matches “*” “To” {
>   set “Recipient” “${1}”
> }
> if header :matches “*” “From” {
>   set “Sender” “${1}”
> }
> if header :matches “*” “Subject” {
>   set “Subject” “${1}”
> }
> set “Message” “[To: {$Recipient} From: {$Sender}] {$Subject}”

(you'll have to switch the arguments, it's header COMPARATOR header-name
pattern)

> (I note that my intuative use of * won't work cos * in matches
> according to variables is non-greedy, yet * with regex is greedy, but
> I thought I'd do that deliberately to make you think...)

greediness doesn't come into play here, as :matches "*" == :regex
"^(.*)$"

> This seems like a lot of work to do something pretty "standard".

agreed.

> I wonder if it would make sense for us to add associative arrays
> containing entries of specific interest to the sieve script author.
> [...]
> Then I would end up with an array like this:
> 
> This would produce an array with these entries:
> $HEADERS[‘Received’][0] = “from p01m168.mxlogic.net [bla bla] ”
> $HEADERS[‘Received’][1] = “from unknown [208.184.76.39] [bla bla] ”
> $HEADERS[‘Date’][0] = “Thu, 27 Jan 2005 09:56:56 -0800 (PST)”
> $HEADERS[‘To’][0] = “[email-masked]”
> $HEADERS[‘From’][0] = “[email-masked]”
> $HEADERS[‘Subject’][0] = “Welcome to ietf-mta-filters”

this is just a different syntax for:

  ${header.received.n1} = “from p01m168.mxlogic.net [bla bla] ”
  ${header.received.n2} = from unknown [208.184.76.39] [bla bla] ”
  ${header.date} = “Thu, 27 Jan 2005 09:56:56 -0800 (PST)”

(the variables draft doesn't allow the last component of the variable
name to be a number.  I think that is an aspect we can change if we want
to, but it must be done now.)

anyhow, doing it via a namespace makes it more natural to present the
information in a parsed manner.  e.g., you could have an
header.date.year == "2005" in addition.

(the variables draft allows header.date and header.date.year to
co-exist, as the namespace is defined as the bit before the last full
stop.)

-- 

Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked]
Date: Mon, 07 Feb 2005 00:41:26 +0100
Sender: [email-masked]

On Sat, 2005-02-05 at 17:01 -0500, Mark E. Mallett wrote:
> I would like to include by reference, without going on about it further
> here, my earlier remarks about choices of keywords that might be likely
> to collide with future language enhancements.  Those issues are still
> important, if only to me.

please put forward suitable wording for use in the document?

> Also I have a few new niggling comments, as follows.
> 
> 3.
>    > "When a string is evaluated ..."
> 
> I'm not sure that the concept of evaluating a string has been
> introduced, so the "when a string is evaluated" is not strictly clear
> (even if everybody probably knows what it means).  So perhaps lay the
> groundwork of saying that this extension enables interpretation of
> strings at the moment they are used during runtime , and then say "when
> a string is interpreted..."   or just change the word to "interpreted" :-)

I agree, "interpreted" is better.

> 3.2.  Numbered variables
> 
>    > For ":matches"...
>    > The wildcards match as little as possible (non-greedy matching).
> 
> Even though I am in favor of this: this is a refinement of RFC3028
> (which is silent on the greediness issue).  Does this need to be
> explicitly stated?  I would think this should be an item for 3028bis or
> whatever the next SIEVE base draft is, as well.  (Being able to specify
> the :matches greediness would be a plus.)

I think it is essential that greediness behaviour is defined.  it cannot
be observed by the mechanisms in 3028 (or 3028bis) since it doesn't
change _what_ matches, only _how_ it matches, so it is natural that the
facility which makes observation possible also defines what should be
observed.

>    > 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 as a decimal number.
> 
> Hmm, I glossed over this before.  There are other environments
> (including typical regex implementations) where it's common to have
> submatch 0 represent the entire matched string.  Access to the number of
> strings is useful, but so is access to the entire match (probably more
> so than the number of matches, since that's predictable from the pattern
> used).  Since it's nice to be consistent with what people might already
> be used to, I'd recommend having index 0 be the entire match, and something
> else be the count of the matches.  Maybe a special ${#} for the number
> of matches.

I think too little is gained by this change to incorporate it at this
stage.

> Or keep ${0} as the count, and add something else (e.g. ${*}) as the
> complete match string.

explicit is better than implicit -- users can just add an extra pair of
parentheses.  (this only applies to :regex.  for :matches, the match
string is always equal to the source string.)

> 4.  Action set
> 
>    > An illegal name MUST cause a syntax error.
> 
> "MUST be detected as a syntax error" ?  (at compile time?  runtime?)

from RFC 3028, 2.10.6:

   In any programming language, there are compile-time and run-time
   errors.

   Compile-time errors are ones in syntax that are detectable if a
   syntax check is done.

so compile-time.

> 4.1.  Modifiers
> 
>    > More than one modifier can be specified, in which case
>    > they are applied according to this precedence list, highest value
>    > first:
> 
> I think this has been addressed before, but "highest value" is still
> ambiguous because "highness" isn't really an attribute of a number, and
> the word "precedence" implies doing things in numeric order, 1, 2, 3.
> So some people, if not most people, will think of the "highest
> precedence value" as having the smallest numeric value.  Maybe:
> 
>    More than one modifier can be specified, in which case they are
>    applied in reverse order of precedence value, i.e. from largest to
>    smallest, according to this table:
> 
> I would personally make it smallest value first, but either way as long
> as it's clear.

I can do s/highest/largest/ if you think that's better.  introducing
some "order of precedence value" will surely only muddle the issue.

> 5.  Test string
> 
> I agree with another commenter's earlier remark that :count is silly.
> Unless the intent is to count the number of matches, rather than the
> number of strings?  It doesn't say that, though-- and I don't really
> know why that would be useful, either.

leaving it out will introduce an area of undefined behaviour, which IMO
would be bad and unnecessary.
-- 
Kjetil T.

From: "Eric SOHIER" <[email-masked]>
To: <[email-masked]>
Subject: Regulate sieve which does not go!
Date: Sun, 6 Feb 2005 09:45:02 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C50C30.890BE9B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

I'm a new member of the list and I use the service fmailbox which manages
the rules sieve.

I would like to know how to describe a rule which makes it possible to move
a message which contains a specific address "from"?

I tested this:

If header: contains ["To"] ["[email-masked]"] {fileinto
"INBOX.Astronomie.astrocam";}

But that does not go on this message:

X-Sender: [email-masked]

X-Apparently-To: [email-masked]

Received: (qmail 26728 invoked from network); 21 Jan 2005 13:46:09 -0000

Received: from unknown (66.218.66.218)

  by m17.grp.scd.yahoo.com with QMQP; 21 Jan 2005 13:46:09 -0000

Received: from unknown (HELO hotmail.com) (65.54.185.29)

  by mta3.grp.scd.yahoo.com with SMTP; 21 Jan 2005 13:46:09 -0000

Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;

      Fri, 21 Jan 2005 05:42:02 -0800

Message-ID: <[email-masked]>

Received: from 84.195.167.88 by by15fd.bay15.hotmail.msn.com with HTTP;

     Fri, 21 Jan 2005 13:41:05 GMT

X-Originating-Email: [[email-masked]]

X-Sender: [email-masked]

To: [email-masked], [email-masked],

     [email-masked]

X-OriginalArrivalTime: 21 Jan 2005 13:42:02.0351 (UTC)
FILETIME=[FCCEFFF0:01C4FFBE]

X-eGroups-Remote-IP: 65.54.185.29

From: "patricia david" <[email-masked]>

X-Originating-IP: [84.195.167.88]

X-Yahoo-Profile: astrobourlingueurs

MIME-Version: 1.0

Mailing-List: list [email-masked]; contact
[email-masked]

Delivered-To: mailing list [email-masked]

Precedence: bulk

List-Unsubscribe: <mailto:[email-masked]>

Date: Fri, 21 Jan 2005 13:41:05 +0000

Subject: [astrocam] Tete de cheval

Content-Type: multipart/mixed;

 boundary="----=_NextPart_000_4a7a_535c_14b6"

Why ?

Thanks by advance.

-- Eric SOHIER

------=_NextPart_000_0010_01C50C30.890BE9B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.StyleCourrierlectronique17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Hello,</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I&#8217;m a new member of the list and I use =
the
service fmailbox which manages the rules sieve.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I would like to know how to describe a rule =
which
makes it possible to move a message which contains a specific address
&#8220;from&#8221;?</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I tested this:</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>If header: contains =
[&#8220;To&#8221;]
[&#8220;[email-masked]&#8221;] {fileinto =
&#8220;INBOX.Astronomie.astrocam&#8221;;}</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>But that does not =
go on this
message:</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span lang=3DDE
style=3D'font-size:12.0pt;font-family:"Courier New"'>X-Sender:
[email-masked]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span lang=3DDE
style=3D'font-size:12.0pt;font-family:"Courier New"'>X-Apparently-To: =
[email-masked]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Received: (qmail =
26728
invoked from network); </span></font><font face=3D"Courier New"><span =
lang=3DEN-GB
 style=3D'font-family:"Courier New"'>21 Jan 2005</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> </span></font><font face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-family:"Courier New"'>13:46:09</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> -0000</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Received: from =
unknown
(66.218.66.218)</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>&nbsp; by
m17.grp.scd.yahoo.com with QMQP; </span></font><font
 face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'>21 Jan
 2005</span></font><font face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-family:
"Courier New"'> </span></font><font face=3D"Courier New"><span =
lang=3DEN-GB
 style=3D'font-family:"Courier New"'>13:46:09</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> -0000</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Received: from =
unknown (HELO
hotmail.com) (65.54.185.29)</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>&nbsp; by =
mta3.grp.scd.yahoo.com
with SMTP; </span></font><font face=3D"Courier New"><span lang=3DEN-GB
 style=3D'font-family:"Courier New"'>21 Jan 2005</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> </span></font><font face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-family:"Courier New"'>13:46:09</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> -0000</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Received: from mail =
pickup
service by hotmail.com with Microsoft SMTPSVC;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;</span></font><font face=3D"Courier =
New"><span lang=3DEN-GB style=3D'font-family:"Courier New"'>Fri, 21 Jan
 2005</span></font><font face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-family:
"Courier New"'> </span></font><font face=3D"Courier New"><span =
lang=3DEN-GB
 style=3D'font-family:"Courier New"'>05:42:02</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'> -0800</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Message-ID:
&lt;[email-masked]&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Received: from =
84.195.167.88
by by15fd.bay15.hotmail.msn.com with HTTP;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font face=3D"Courier =
New"><span lang=3DEN-GB style=3D'font-family:"Courier New"'>Fri, 21 Jan
 2005</span></font><font face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-family:
"Courier New"'> </span></font><font face=3D"Courier New"><span =
lang=3DEN-GB
 style=3D'font-family:"Courier New"'>13:41:05 GMT</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>X-Originating-Email:
[[email-masked]]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>X-Sender:
[email-masked]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>To:
[email-masked], [email-masked],</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>X-OriginalArrivalTime: </span></font><font face=3D"Courier =
New"><span lang=3DEN-GB style=3D'font-family:"Courier New"'>21 Jan =
2005</span></font><font
face=3D"Courier New"><span lang=3DEN-GB style=3D'font-family:"Courier =
New"'>
13:42:02.0351 (UTC) FILETIME=3D[FCCEFFF0:01C4FFBE]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>X-eGroups-Remote-IP:
65.54.185.29</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>From: =
&quot;patricia david&quot;
&lt;[email-masked]&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>X-Originating-IP:
[84.195.167.88]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>X-Yahoo-Profile: =
astrobourlingueurs</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>MIME-Version: =
1.0</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Mailing-List: list
[email-masked]; contact =
[email-masked]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Delivered-To: =
mailing list
[email-masked]</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>Precedence: =
bulk</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Courier New"'>List-Unsubscribe:
&lt;mailto:[email-masked]&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'>Date: Fri, 21 Jan 2005 13:41:05 =
+0000</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'>Subject: [astrocam] Tete de =
cheval</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'>Content-Type: =
multipart/mixed;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'>&nbsp;</span></font><font face=3D"Courier =
New"><span
lang=3DEN-GB style=3D'font-family:"Courier =
New"'>boundary=3D&quot;----=3D_NextPart_000_4a7a_535c_14b6&quot;</span></=
font></p>

<p class=3DMsoNormal><font size=3D3 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Arial'>Why ?</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Arial'>Thanks by advance.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>-- Eric SOHIER</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0010_01C50C30.890BE9B0--

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 5 Feb 2005 23:52:56 -0500
To: Cyrus Daboo <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Subject: Re: spamtestbis
Sender: [email-masked]

On Thu, Feb 03, 2005 at 04:14:34PM -0500, Cyrus Daboo wrote:
> FYI the draft for the new version of the spamtest extension is now 
> available.

Picky comments from mem..

I have a hard time reading this document, mainly because of phrases
that include "returning strings" and overloading of some words to
mean different things.  Perhaps it's just the way my brain works,
or doesn't work.  Specifically:

1.  Introduction and Overview

   > The purpose of this document is to introduce two SIEVE tests that can
   > be used to implement 'generic' tests for spam and viruses in messages
   > processed via SIEVE scripts.  These tests return a string containing
   > a range of numeric values that indicate the severity of spam or
   > viruses in a message, or a string that indicates the message has not
   > passed through any spam or virus checking tools.

When you talk about SIEVE tests, it reads as though you are talking
about SIEVE language elements.  Those elements won't really do those
things, it's the underlying filter implementation that would interpret
the result of spam or virus analysis and produce, conceptually, a string
(or strings) that can be used by those SIEVE language elements.  (The
next sentence says as much.)  Also, that conceptual string probably
contains "a number that lies within a range of numeric values" -- the
string would not contain "a range of numeric values."

3.1  General Considerations

   > The "spamtest" and "virustest" tests described below both return a
   > string that starts with a numeric value, followed by an optional
   > space (%x20) character and optional arbitrary text.

Here's where the trouble really lies.  This pretty clearly is talking
about SIEVE language statements -- and if it isn't, then the use of
those words is even more of a problem.  Those statements do not return a
string; they act upon the string that was returned by the underlying
tests.  (Or, rather, they act as if they did that: no string really has
to be present.)

   > The additional text can be used to carry implementation
   > specific details about the tests performed and descriptive comments
   > about the result.  Tests can be done using standard string
   > comparators against this text if it helps to refine behaviour,

Does "this text" refer to "The additional text" or to the entire string?
The English grammar implies the former, but text in the introduction
implies the latter.  For example, given a underlying spam test result
of:

   "4 too many recipients"

how does:

    if spamtest :is "too many recipients"  { ... }

evaluate?  IMHO testing against the "additional text" would be the most
useable.

   > The "spamtest" test evaluates to true if the spamtest result matches
   > the value.  The type of match is specified by the optional match

Another example where the word "spamtest" means two different things:
the SIEVE statement and the underlying test that produces a string for
use by that statement.  I'd recommend finding different ways to
refer to the SIEVE statement and the underlying analysis of spam and
virus results.

[ Imagine similar comments about similar sections ... ]

BTW I think this is the kind of extension that could be solved with
better fundamental language elements and/or better coordination between
language extensions.

For example, one could build on the proposed "variables" extension by
imagining a new set of read-only variables within specific namespaces
(per the old namespace idea, a la dates and timezones).  Imagine:

   require "variables";
   require [ "relational", "comparator-i;ascii-numeric" ];

   set "spamval" "${spamtest::value}"
   set "spampct" "${spamtest::pctvalue}"
   set "spamtext" "${spamtest::text}"

   if string :value "ge"
             :comparator "i;ascii-numeric"
	     "${spamval}" "3" { ... }
   if string :value "ge"
             :comparator "i;ascii-numeric"
             "${spamtest::pctvalue}" "30" { ... }

Time travel might be required though.

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 5 Feb 2005 17:01:51 -0500
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked], "Mark E. Mallett" <[email-masked]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Sender: [email-masked]

On Fri, Feb 04, 2005 at 12:42:45PM +0100, Kjetil Torgrim Homme wrote:
> 
> I've updated the document and made quite a few changes, although they
> are all editorial.
> 
> Document: draft-ietf-sieve-variables-01.txt           University of Oslo

Hi-

I would like to include by reference, without going on about it further
here, my earlier remarks about choices of keywords that might be likely
to collide with future language enhancements.  Those issues are still
important, if only to me.

Also I have a few new niggling comments, as follows.

3.

   > "When a string is evaluated ..."

I'm not sure that the concept of evaluating a string has been
introduced, so the "when a string is evaluated" is not strictly clear
(even if everybody probably knows what it means).  So perhaps lay the
groundwork of saying that this extension enables interpretation of
strings at the moment they are used during runtime , and then say "when
a string is interpreted..."   or just change the word to "interpreted" :-)

3.2.  Numbered variables

   > For ":matches"...
   > The wildcards match as little as possible (non-greedy matching).

Even though I am in favor of this: this is a refinement of RFC3028
(which is silent on the greediness issue).  Does this need to be
explicitly stated?  I would think this should be an item for 3028bis or
whatever the next SIEVE base draft is, as well.  (Being able to specify
the :matches greediness would be a plus.)

   > 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 as a decimal number.

Hmm, I glossed over this before.  There are other environments
(including typical regex implementations) where it's common to have
submatch 0 represent the entire matched string.  Access to the number of
strings is useful, but so is access to the entire match (probably more
so than the number of matches, since that's predictable from the pattern
used).  Since it's nice to be consistent with what people might already
be used to, I'd recommend having index 0 be the entire match, and something
else be the count of the matches.  Maybe a special ${#} for the number
of matches.

Or keep ${0} as the count, and add something else (e.g. ${*}) as the
complete match string.

4.  Action set

   > An illegal name MUST cause a syntax error.

"MUST be detected as a syntax error" ?  (at compile time?  runtime?)

4.1.  Modifiers

   > More than one modifier can be specified, in which case
   > they are applied according to this precedence list, highest value
   > first:

I think this has been addressed before, but "highest value" is still
ambiguous because "highness" isn't really an attribute of a number, and
the word "precedence" implies doing things in numeric order, 1, 2, 3.
So some people, if not most people, will think of the "highest
precedence value" as having the smallest numeric value.  Maybe:

   More than one modifier can be specified, in which case they are
   applied in reverse order of precedence value, i.e. from largest to
   smallest, according to this table:

I would personally make it smallest value first, but either way as long
as it's clear.

5.  Test string

I agree with another commenter's earlier remark that :count is silly.
Unless the intent is to count the number of matches, rather than the
number of strings?  It doesn't say that, though-- and I don't really
know why that would be useful, either.

Yours,
-mm-

Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Date: Fri, 04 Feb 2005 14:14:57 -0800 (PST)
From: [email-masked]
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
To: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

> I've updated the document and made quite a few changes, although they
> are all editorial.

> ...

> I haven't submitted this, because I'm not sure if it should be done by
> me or the chair?

The chair only has to deal with -00 submissions of WG drafts. After
the -00 version you should be able to do it yourself.

				Ned

Cc: [email-masked], IETF MTA Filters List <[email-masked]>
Date: Fri, 04 Feb 2005 11:19:16 -0800 (PST)
From: [email-masked]
Subject: Re: spamtestbis
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

> Hi [email-masked],

> --On February 3, 2005 2:08:56 PM -0800 [email-masked] wrote:

> >> FYI the draft for the new version of the spamtest extension is now
> >> available. The only change between this and the current RFC is the
> >> addition of a :percent argument to the spamtest test to allow for a
> >> numeric range of 0 - 100. The value -1 is used to indicate a message
> >> that was not categorised in anyway.
> >
> > First, I don't think the -1 is a good idea because of how it interacts
> > with numeric comparators. I'd much rather retain 0 as the value
> > indicating no test was done.

> So we would have:

>     spamtest    interpretation
>     value

>    		 0          message was not tested for spam
>    		 1          message was tested and is clear of spam
>    	2 - 99     message was tested and has a varying likelihood of
>    		            containing spam in increasing order
>    		 100        message was tested and definitely contains spam

Yes, I think this is what we want.

> > The only other issue I see with the draft is the business of making
> > require "spamtest" and require "spamtestpercent" mutually exclusive. I
> > certainly agree that we want require "spamtestpercent" to subsume require
> > "spamtest" - - require lists in sieve can be really long - but I wonder
> > if making them mutually exclusive goes too far.

> I can change the 'MUST NOT' to a 'SHOULD NOT' for that requirement.

> > Additionally, one thing that isn't entirely clear with the current text
> > is that the following is legal:
> >
> >    require "spamtest"; if spamtest :contains "foo" ...
> >
> > That is, spamtest without a :percent is allowed when require
> > "spamtestpercent" is used. I think this should be clarified.
> >
> >

> Here is some alternative text for this:

> Old:

>    SIEVE implementations that implement the "spamtest" test have an
>    identifier of "spamtest" for use with the capability mechanism.  If
>    the ":percent" argument is used with any spamtest test, then the
>    capability idenitifier "spamtestpercent" MUST be present, and the
>    "spamtest" capability MUST NOT be present.

> New:

>    SIEVE implementations that implement the "spamtest" test use an
>    identifier of either "spamtest" or "spamtestpercent" for use with
>    the capability mechanism.

>    If the ":percent" argument is not used with any spamtest test, then
>    one of either the "spamtest" or "spamtestpercent" capability
>    identifiers MUST be present, though both SHOULD NOT be present together.

>    If the ":percent" argument is used with any spamtest test, then
>    the "spamtestpercent" capability identifier MUST be present, and
>    the "spamtest" capability identitifer SHOULD NOT be present.

Much better. I'm happy with this.

				Ned

Date: Fri, 04 Feb 2005 14:06:56 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
cc: IETF MTA Filters List <[email-masked]>
Subject: Re: spamtestbis
Sender: [email-masked]

Hi [email-masked],

--On February 3, 2005 2:08:56 PM -0800 [email-masked] wrote:

>> FYI the draft for the new version of the spamtest extension is now
>> available. The only change between this and the current RFC is the
>> addition of a :percent argument to the spamtest test to allow for a
>> numeric range of 0 - 100. The value -1 is used to indicate a message
>> that was not categorised in anyway.
>
> First, I don't think the -1 is a good idea because of how it interacts
> with numeric comparators. I'd much rather retain 0 as the value
> indicating no test was done.

So we would have:

    spamtest    interpretation
    value

   		 0          message was not tested for spam
   		 1          message was tested and is clear of spam
   	2 - 99     message was tested and has a varying likelihood of
   		            containing spam in increasing order
   		 100        message was tested and definitely contains spam

Perhaps those that requested the percent range could state whether this is 
acceptable.

> The only other issue I see with the draft is the business of making
> require "spamtest" and require "spamtestpercent" mutually exclusive. I
> certainly agree that we want require "spamtestpercent" to subsume require
> "spamtest" - - require lists in sieve can be really long - but I wonder
> if making them mutually exclusive goes too far.

I can change the 'MUST NOT' to a 'SHOULD NOT' for that requirement.

> Additionally, one thing that isn't entirely clear with the current text
> is that the following is legal:
>
>    require "spamtest"; if spamtest :contains "foo" ...
>
> That is, spamtest without a :percent is allowed when require
> "spamtestpercent" is used. I think this should be clarified.
>
>

Here is some alternative text for this:

Old:

   SIEVE implementations that implement the "spamtest" test have an
   identifier of "spamtest" for use with the capability mechanism.  If
   the ":percent" argument is used with any spamtest test, then the
   capability idenitifier "spamtestpercent" MUST be present, and the
   "spamtest" capability MUST NOT be present.

New:

   SIEVE implementations that implement the "spamtest" test use an
   identifier of either "spamtest" or "spamtestpercent" for use with
   the capability mechanism.

   If the ":percent" argument is not used with any spamtest test, then
   one of either the "spamtest" or "spamtestpercent" capability
   identifiers MUST be present, though both SHOULD NOT be present together.

   If the ":percent" argument is used with any spamtest test, then
   the "spamtestpercent" capability identifier MUST be present, and
   the "spamtest" capability identitifer SHOULD NOT be present.

-- 
Cyrus Daboo

Cc: Cyrus Daboo <[email-masked]>, IETF MTA Filters List <[email-masked]>
Date: Fri, 04 Feb 2005 10:41:03 -0800 (PST)
From: [email-masked]
Subject: Re: spamtestbis
To: Nigel Swinson <[email-masked]>
Sender: [email-masked]

> > > FYI the draft for the new version of the spamtest extension is now
> > > available. The only change between this and the current RFC is the addition
> > > of a :percent argument to the spamtest test to allow for a numeric range of
> > > 0 - 100. The value -1 is used to indicate a message that was not
> > > categorised in anyway.

> I'm surprised we need a percentage spam score... I would have thought 10
> levels was enough.  Indeed in your example you use level 30(%) = 3.

FWIW, I personally don't see any need for more levels, but I have seen
some user requests for this and I understand others have seen considerable
demand for it.
 
> > First, I don't think the -1 is a good idea because of how it interacts with
> > numeric comparators. I'd much rather retain 0 as the value indicating no test
> > was done.

> I agree.  I think many existing scripts will test for 0 as a way of finding
> out if the message was scanned, so why risk breaking them?  Personally I don't
> mind if "message is clear of spam" = 1%.  It's not really an exact science
> anyway...

Yeah, "the exact science of spam identification" is indeed an oxymoron. Its
the reason why 10 levels is enough for me at least.

				Ned

Cc: [email-masked], [email-masked]
Date: Fri, 04 Feb 2005 10:00:19 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve-Notify and potential associative arrays.
To: Nigel Swinson <[email-masked]>
Sender: [email-masked]

> > I'm a fan of associative arrays, having first used them in the Sail quite some
> > time ago. (Anyone else remember Sail?) However, I have to say I think
> > associative arrays would be serious overkill for sieve. Yes, I realize they're
> > powerful, but they introduce significant language and implementation
> > complexity.

> It's really only read only associative arrays I was proposing, so that
> eliminates a large amount of complexity.  If read-only associative arrays
> are overkill for Sieve then how best can we support authoring of simple
> messages based on the content of the inbound mail?

This begs the question of whether or not complex header transformations are
something we should be doing with sieve. I happen to think the answer to this
particular question is "no". Copying a subject and perhaps a couple of other
fields into a new message is about as far as I think sieve needs to go.

Of course there are all sorts of more complex things people will want to do.
But this is a seriously slippery slope, because lurking not far away are
things like content summaries, keyword extraction, translation services,
content shaping, and so on. This stuff has "research problem" written all
over it, and IMO sieve needs to stay away from this space.

> Do you/we favour the $subject$ approach?

I think it is just sufficient to get the jobs appropriate for sieve done.

> I guess I would accept some implementation complexity
> if it means the language is easier to use....

Ease of use is a two-edged sword. One of the things sieve is used for is
as an output format for GUI filter builder utilities. Variables are already
pretty hard to handle in such tools, things like associative arrays
are really over the top.

				Ned

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Date: Fri, 4 Feb 2005 15:50:45 -0000
Sender: [email-masked]

> a)   added example for string test

In the rest of your examples, the # comment inside the {} is only indented 
once, but here it's indented several times?  Looks a little odd....

> c)   added Syntax line for MODIFIER.

Aren't you missing an indent on syntax line for Modifiers?

> d)   added comment to an example showing that the non-greedy "*" still
>     matches everything due to implicit anchors.

I think this is an important enough concept to make more explicit.  Without 
this concept, I don't believe it's possible to get the entirity of a mail 
header into a Sieve Variable without using the regex extension, and I think 
this is something people will want to do.  Perhaps amend this paragraph:

   For ":matches", the list will contain one string for each wildcard
   ("?" and "*") in the match pattern.  Each string holds what the
   corresponding wildcard expands to, possibly the empty string.  The
   wildcards match as little as possible (non-greedy matching).

Not sure how it should be modified, I'd probably change it to say it does 
greedy matching ;o)

Nigel 

Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Fri, 04 Feb 2005 12:42:45 +0100
Sender: [email-masked]

--=-Ze05xgmdDdl5uJ7MBCLh
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Tue, 2005-02-01 at 17:21 +0000, Alexey Melnikov wrote:
> The WGLC is over and I haven't seen any comments on the document. This 
> means that it is either perfect, or that people didn't have time to 
> review it.
> 
> Ned and myself have reviewed the document. Anybody else?
> Can I ask people who have reviewed the document to email me directly and 
> state that they found no problems with the document. I would appreciate 
> any feedback by February 7th (next Monday). Thanks!

I've updated the document and made quite a few changes, although they
are all editorial.

0.2.6.  Changes since -00 (WG series)

a)   added example for string test

b)   moved introductory text for MODIFIER from 5.1 into 5.0

c)   added Syntax line for MODIFIER.

d)   added comment to an example showing that the non-greedy "*" still
     matches everything due to implicit anchors.

e)   added example of expansion of string with unbalanced braces.

I haven't submitted this, because I'm not sure if it should be done by
me or the chair?
-- 
Kjetil T.

--=-Ze05xgmdDdl5uJ7MBCLh
Content-Disposition: attachment; filename=draft-ietf-sieve-variables-01.txt
Content-Type: text/plain; name=draft-ietf-sieve-variables-01.txt; charset=ISO-8859-1
Content-Transfer-Encoding: base64

--=-Ze05xgmdDdl5uJ7MBCLh--

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve-Notify and potential associative arrays.
Date: Fri, 4 Feb 2005 13:45:00 -0000
Sender: [email-masked]

> I'm a fan of associative arrays, having first used them in the Sail quite 
> some
> time ago. (Anyone else remember Sail?) However, I have to say I think
> associative arrays would be serious overkill for sieve. Yes, I realize 
> they're
> powerful, but they introduce significant language and implementation
> complexity.

It's really only read only associative arrays I was proposing, so that 
eliminates a large amount of complexity.  If read-only associative arrays 
are overkill for Sieve then how best can we support authoring of simple 
messages based on the content of the inbound mail?  Do you/we favour the 
$subject$ approach?  I guess I would accept some implementation complexity 
if it means the language is easier to use....

Nigel 

From: "Nigel Swinson" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>
Cc: "IETF MTA Filters List" <[email-masked]>
Subject: Re: spamtestbis
Date: Fri, 4 Feb 2005 13:01:38 -0000
Sender: [email-masked]

> > FYI the draft for the new version of the spamtest extension is now
> > available. The only change between this and the current RFC is the addition
> > of a :percent argument to the spamtest test to allow for a numeric range of
> > 0 - 100. The value -1 is used to indicate a message that was not
> > categorised in anyway.

I'm surprised we need a percentage spam score... I would have thought 10 levels was enough.  Indeed in your example you use level 30(%) = 3.
 
> First, I don't think the -1 is a good idea because of how it interacts with
> numeric comparators. I'd much rather retain 0 as the value indicating no test
> was done. 

I agree.  I think many existing scripts will test for 0 as a way of finding out if the message was scanned, so why risk breaking them?  Personally I don't mind if "message is clear of spam" = 1%.  It's not really an exact science anyway...

Nigel

Cc: IETF MTA Filters List <[email-masked]>
Date: Thu, 03 Feb 2005 14:08:56 -0800 (PST)
From: [email-masked]
Subject: Re: spamtestbis
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

> FYI the draft for the new version of the spamtest extension is now
> available. The only change between this and the current RFC is the addition
> of a :percent argument to the spamtest test to allow for a numeric range of
> 0 - 100. The value -1 is used to indicate a message that was not
> categorised in anyway.

First, I don't think the -1 is a good idea because of how it interacts with
numeric comparators. I'd much rather retain 0 as the value indicating no test
was done. 

The only other issue I see with the draft is the business of making require
"spamtest" and require "spamtestpercent" mutually exclusive. I certainly
agree that we want require "spamtestpercent" to subsume require "spamtest" -
- require lists in sieve can be really long - but I wonder if making
them mutually exclusive goes too far.

Additionally, one thing that isn't entirely clear with the current text is that
the following is legal:

   require "spamtest"; if spamtest :contains "foo" ...

That is, spamtest without a :percent is allowed when require "spamtestpercent"
is used. I think this should be clarified.

				Ned 

Date: Thu, 03 Feb 2005 16:14:34 -0500
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: spamtestbis
Sender: [email-masked]

FYI the draft for the new version of the spamtest extension is now 
available. The only change between this and the current RFC is the addition 
of a :percent argument to the spamtest test to allow for a numeric range of 
0 - 100. The value -1 is used to indicate a message that was not 
categorised in anyway.

-- 
Cyrus Daboo

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-spamtestbis-00.txt
Date: Thu, 03 Feb 2005 15:57:48 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: SIEVE Email Filtering: Spamtest and Virustest Extensions
	Author(s)	: C. Daboo
	Filename	: draft-ietf-sieve-spamtestbis-00.txt
	Pages		: 10
	Date		: 2005-2-3
	
The SIEVE email filtering language "spamtest", "spamtestpercent" and
   "virustest" extensions permit users to use simple, portable commands
   for spam and virus tests on email messages.  Each extension provides
   a new test using matches against numeric 'scores'.  It is the
   responsibility of the underlying SIEVE implementation to do the
   actual checks that result in values returned by the tests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-spamtestbis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-spamtestbis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-spamtestbis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-spamtestbis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-spamtestbis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Cc: [email-masked]
Date: Wed, 02 Feb 2005 14:42:32 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve-Notify and potential associative arrays.
To: Nigel Swinson <[email-masked]>
Sender: [email-masked]

> I wonder if it would make sense for us to add associative arrays containing
> entries of specific interest to the sieve script author.  So for example a
> $HEADERS array which contained all the header values.  So suppose my headers
> were:

I'm a fan of associative arrays, having first used them in the Sail quite some
time ago. (Anyone else remember Sail?) However, I have to say I think
associative arrays would be serious overkill for sieve. Yes, I realize they're
powerful, but they introduce significant language and implementation
complexity.

				Ned

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Subject: Sieve-Notify and potential associative arrays.
Date: Wed, 2 Feb 2005 02:21:49 -0000
Sender: [email-masked]

Looking at the long since expired Sieve Notify extension, it seems somewhat ugly adjacent to the much newer variables extension, and I would suggest needs a lot of work.  I've had a number of thoughts on the subject, some of which may have an impact on the variables extension, although they are possibly sufficiently separate that they would make an extension on their own.

It seems to me that the notify extension is trying to do too much in supporting notification by email, SMS or indeed any arbitrary notification mechanism.  It was pointed out quickly how many complex internationalization issues you have to deal with when composing emails, but you have completely different concerns when dealing with SMS messages, so I'm not sure it makes sense to bundle them.  I think we should therefore have something more along these lines:

Syntax:   sms [":recipient" <recipient-numbers: string-list>] [:limit <number>] <message: string>

The :recipient tag specifies the target phone numbers to send this SMS to.  If not present, the implementation should try to send the SMS to the owner of the script where the number is held by the sieve implementation, ie a mailbox property.  If present, specifies the target number, and it can also be a list of numbers if more than one recipient is desired.  Each phone number must begin with a + and include the country code to ensure that the script will work regardless of location of server/script.

The message is a string, whereby variable expansion is also permitted. The limit is the maximum number of SMS messages that the server can send.  Given that each message typically has a cost associated with it, the limit by default will be whatever produces the least cost which in today’s terms is 1 message (140 bytes) but may change in the future.  They can use this optional tagged argument to override this such that they will receive a multipart SMS containing more content.  Although to be honest I'm not sure how multipart SMS messages work, but I did find a reference detailing that the standard is 140 bytes http://en.wikipedia.org/wiki/Short_message_service#Technical_details.

Messages are of course therefore in UTF8 and again I'm not sure how you do internationalization in SMS but it does appear to be possible.  If we have our UTF8 message and our limit of the number of SMS messages we need to send, then that hopefully should be enough to do a transformation into the SMS gateway with the right encoding/character set.

The proposal in draft-ietf-sieve-notify-02.txt is this:
 
    Syntax:   notify [":method" string]
               [":id" string]
               [":options" 1*(string-list / number)]
               [<":low" / ":normal" / ":high">]
               ["message:" string]

I'm thinking it's got too many things in it which are trying to be super-generic to cover all uses (:method/:id/:options), but in actual fact we'll quickly regret this and prefer specific extensions for notifying through different channels with well defined and well documented arguments.

Which brings me on to variables.  Each of these different notification types, and also the vacation extension to a certain degree, has the need to author messages, and likely include sections of the triggering message.  So suppose I want to author what I think is a fairly reasonable SMS which looks like this:
           [To:<recipient-addresss>From:<sender-address>] <Subject>\r\n<body>

One way to get his is using the proposed $name$ variables which seem pretty ugly next to what we've worked so hard on with the variables extension, and also is pretty inflexible.  If we use the variables extension as is, then we could do this:

if header :matches “*” “To” {
  set “Recipient” “${1}”
}
if header :matches “*” “From” {
  set “Sender” “${1}”
}
if header :matches “*” “Subject” {
  set “Subject” “${1}”
}
set “Message” “[To: {$Recipient} From: {$Sender}] {$Subject}”

(I note that my intuative use of * won't work cos * in matches according to variables is non-greedy, yet * with regex is greedy, but I thought I'd do that deliberately to make you think...)

This seems like a lot of work to do something pretty "standard".

I wonder if it would make sense for us to add associative arrays containing entries of specific interest to the sieve script author.  So for example a $HEADERS array which contained all the header values.  So suppose my headers were:

Date: Thu, 27 Jan 2005 09:56:56 -0800 (PST)
To: [email-masked]
From: [email-masked]
Subject: Welcome to ietf-mta-filters

Then I would end up with an array like this:

This would produce an array with these entries:
$HEADERS[‘Received’][0] = “from p01m168.mxlogic.net [bla bla] ”
$HEADERS[‘Received’][1] = “from unknown [208.184.76.39] [bla bla] ”
$HEADERS[‘Received’][2] = “from above.proper.com  [bla bla] ”
$HEADERS[‘Received’][3] = “(from majordom@localhost) ”
        .”by above.proper.com (8.12.11/8.12.9/Submit) id j0RHuuq8038984;”
        .“Thu, 27 Jan 2005 09:56:56 -0800 (PST)”
$HEADERS[‘Date’][0] = “Thu, 27 Jan 2005 09:56:56 -0800 (PST)”
$HEADERS[‘To’][0] = “[email-masked]”
$HEADERS[‘From’][0] = “[email-masked]”
$HEADERS[‘Subject’][0] = “Welcome to ietf-mta-filters”

The entries in the array would have RFC2047 encoding removed, stored in UTF8, and header wrapping would be removed such that the headers would have no new lines in them.  The \r\n at the end would be removed also.  (Note the “.” String concatenation operator is not available in Sieve, but used above to demonstrate the removal of header wrapping).  The implementation would be able to evaluate the entries of the associative array in a lazy manner to avoid proceesing.

When doing string expansion, if an array is used the entries in an array would be appended together, which would of course not include the \r\n that was in the original headers, and not do the header wrapping, which means it would be entirely unsuitable for use as email headers. If in future if we need a way of turning an array into a set of headers, then we can offer a parameter to the action that would take the array and the implementation would turn these into a valid header set.

With the above strategy, we now have this:
set “Message” “[To: ${HEADERS[‘To’]} From: ${HEADERS[‘From’]}] ${HEADERS[‘Subject’]}”

I then wonder if we should have other arrays like $ENV or $MESSAGE or $ENVELOPE and could hold information like the name of the mail server, the name of the mailbox, the domain, the time zone, the spam score, or virus score.  It could be the way that extensions provide their variables to us rather than what is suggested in the variables draft:
  
4.  Interpretation of strings
   Namespaces are meant for future extensions which make internal state
   available through variables.  These variables SHOULD be put in a
   namespace with the same name as its capability string.  Notice that
   the user can not specify a namespace when setting variables with SET.

This does mean that we could do header tests by using the string test, and the $HEADERS array, and I guess that's not a bad thing, but I'm not sure if it's a good thing either...

Ah, it feels better to get all that down on paper :o)

Nigel

Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Date: Tue, 01 Feb 2005 18:05:42 -0800 (PST)
From: [email-masked]
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
To: Nigel Swinson <[email-masked]>
Sender: [email-masked]

> > Ned and myself have reviewed the document. Anybody else?
> > Can I ask people who have reviewed the document to email me directly and
> > state that they found no problems with the document. I would appreciate
> > any feedback by February 7th (next Monday). Thanks!

> Just noticed this:
>       # Imagine the header
>       # Subject: [acme-users] [fwd] version 1.0 is out
>       if header :regex "Subject" "^[(.*)] (.*)$" {
>           # ${1} will hold "acme-users] fwd"
>       }

> Shouldn't the comment be:
>           # ${1} will hold "acme-users] [fwd"

Sure looks like it to me. Nice catch.

				Ned

From: "Nigel Swinson" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Date: Wed, 2 Feb 2005 01:31:17 -0000
Sender: [email-masked]

> Ned and myself have reviewed the document. Anybody else?
> Can I ask people who have reviewed the document to email me directly and 
> state that they found no problems with the document. I would appreciate 
> any feedback by February 7th (next Monday). Thanks!

Just noticed this: 
      # Imagine the header
      # Subject: [acme-users] [fwd] version 1.0 is out
      if header :regex "Subject" "^[(.*)] (.*)$" {
          # ${1} will hold "acme-users] fwd"
      }

Shouldn't the comment be:
          # ${1} will hold "acme-users] [fwd"

Cheers,

Nigel

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Subject: Uncontroversial bits and pieces about a number of drafts.
Date: Wed, 2 Feb 2005 01:30:05 -0000
Sender: [email-masked]

http://www.ietf.org/internet-drafts/draft-showalter-sieve-vacation-06.txt
4.3. In-Reply-To and References
-     be generated, and References need not bne changed.
+     be generated, and References need not be changed.

http://www.imc.org/ietf-mta-filters/mail-archive/msg01900.html
(draft-degener-sieve-body-03.txt)
I thought body was not included in the base spec more out of concerns on the execution cost of a body test, not on the "implementation" costs as such.

http://www.imc.org/ietf-mta-filters/mail-archive/msg01901.html
(draft-degener-sieve-editheader-03.txt)
While some do call me Niggle, my official name has only one 'g' :o)
 -   Randall Schwartz, Nigegl Swinson, Kjetil Torgrim Homme, and
+   Randall Schwartz, Nigel Swinson, Kjetil Torgrim Homme, and

Cheers

Nigel

(Sorry, mysteriously got dropped from this list, so have only just finished catching up with a few months of posts...)

Cc: [email-masked]
Date: Tue, 01 Feb 2005 09:59:30 -0800 (PST)
From: [email-masked]
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

> Alexey Melnikov wrote:

> > I would like to solicit your attention to the following draft:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-00.txt
> >
> > I've sent few editorial suggestions to the author, but I don't think
> > they should delay the WGLC any further.
> > The WGLC starts today. Due to winter holiday season it would last for
> > 4 weeks, i.e. till January 18th.
> > And I hope that Tim can submit 3028bis before that, so that the WG has
> > time to check if there are any interactions between the two documents.
> >
> Hi group,
> The WGLC is over and I haven't seen any comments on the document. This
> means that it is either perfect, or that people didn't have time to
> review it.

> Ned and myself have reviewed the document. Anybody else?

FWIW, I looked it over again and I think it is ready to go. The only
glitch I found was that the [SPAMTEST] reference should be changed
to refer to RFC 3685.

				Ned

Date: Tue, 01 Feb 2005 17:21:06 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Sender: [email-masked]

Alexey Melnikov wrote:

> I would like to solicit your attention to the following draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-00.txt
>
> I've sent few editorial suggestions to the author, but I don't think 
> they should delay the WGLC any further.
> The WGLC starts today. Due to winter holiday season it would last for 
> 4 weeks, i.e. till January 18th.
> And I hope that Tim can submit 3028bis before that, so that the WG has 
> time to check if there are any interactions between the two documents.
>
Hi group,
The WGLC is over and I haven't seen any comments on the document. This 
means that it is either perfect, or that people didn't have time to 
review it.

Ned and myself have reviewed the document. Anybody else?
Can I ask people who have reviewed the document to email me directly and 
state that they found no problems with the document. I would appreciate 
any feedback by February 7th (next Monday). Thanks!

Alexey