Subject: notify and valid_notify_method

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 7 Apr 2009 15:34:45 +0200

Supposed to return true if all exist and are valid and supported and 
generally polished, and false if at least one has some imperfection.

But what if the list is empty? Sounds like a degenerate true, agreed?

Arnt

---

From: Michael Haardt <[email-masked]>
Date: Mon, 27 Apr 2009 13:12:44 +0200

> But what if the list is empty? Sounds like a degenerate true, agreed?

A string list can't be empty.

Michael

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 27 Apr 2009 13:39:42 +0200

> A string list can't be empty.

OK. I thought variables changed that, though... wasn't there a draft to 
read varables from sources outside sieve? Called something lie server 
or metadata or something? Can't find it now.

Arnt

Date: Mon, 27 Apr 2009 13:39:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: notify and valid_notify_method
Sender: [email-masked]

> A string list can't be empty.

OK. I thought variables changed that, though... wasn't there a draft to 
read varables from sources outside sieve? Called something lie server 
or metadata or something? Can't find it now.

Arnt

Date: Mon, 27 Apr 2009 13:12:44 +0200
To: [email-masked], [email-masked]
Subject: Re: notify and valid_notify_method
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

Michael

Date: Wed, 15 Apr 2009 15:49:02 -0700
Subject: Re: [sieve-in-xml] Example Scripts For Integration Testing
From: Lisa Dusseault <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

Some WGs have actually done this as RFCs:   e.g.
http://www.ietf.org/rfc/rfc3665.txt

In some cases, it's no problem doing this (even if out-of-scope) as an
ad-hoc activity on the WG mailing list, though that's up to the chairs
and they could always suggest the activity move elsewhere.  I suppose
if there's effectively a code-base rather than an Internet-Draft, it
might be nicer to use a open-source collaboration site with SVN as
well as forums instead of this mailing list anyway -- so it depends
also on participation and activity level as well as how the corpus is
structured.

Lisa

On Thu, Apr 9, 2009 at 1:16 AM, Robert Burrell Donkin
<[email-masked]> wrote:
>
> i'm much happier with the current sieve-in-xml draft. we hope to ship
> JSieve soon with experimental preview partial support with the hope
> that usage by developers may help to understand whether any issues
> have been missed, with a complete implementation would be targetted
> for the next release.
>
> however, to confidently ship a library claiming full support, a
> reasonably large and fully debugged corpus of integration tests is
> needed: basically, example sieve scripts together with corresponding
> sieve-in-xml documents. IMO this is the sort of data which is usually
> best developed and debugged collectively.
>
> from the sieve working group charter:
>
> <blockquote cite='http://www.ietf.org/html.charters/sieve-charter.html'>
> (5) Produce one or more informational RFCs containing a set of test
> scripts and test email messages that are to be filtered by the scripts,
> and the expected results of that filtering. This will serve as the basis
> of a interoperability test suite to help determine the suitability of
> moving the base specification and selected extensions to Draft status.
> </blockquote>
>
> as i read this, a collection of example sieve scripts and sieve-in-xml
> documents is out of scope for this group (hopefully people will jump
> in if my reading is incorrect)
>
> so, i was wondering whether there is any interest from members of the
> group in collaborating offshore (http://code.google.com, say) on
> creating and debugging such a corpus as an open source project under a
> very permissive license (MIT, say), or whether there are any other
> good ways that such a corpus could be created and made freely
> available
>
> - robert
>
>

Date: Tue, 14 Apr 2009 15:36:20 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Questions and remarks on draft-ietf-sieve-include-01.txt
Cc: Aaron Stone <[email-masked]>, Stephan Bosch <[email-masked]>
Sender: [email-masked]

Aaron Stone answers Stephan Bosch:
>>  - Where the ManageSieve protocol specifies what characters are 
>>  allowed for a script name, the include extension for the Sieve 
>>  language does not. Would it be useful to adopt the same 
>>  limitations? Especially things like '/' can cause problems.
>
> Good suggestion. I think this makes sense to give a consistent opinion 
> on what script names should look like, but on the other hand, perhaps 
> it's possible that someone isn't using ManageSieve but IS using 
> include and might need to get at weird names? Do we care in that 
> case?

If so, then they probably will use managesieve at some point anyway.

>>  - The global command is required to follow 'require' or another 
>>  global command. I am worried what happens when other extensions 
>>  have commands with similar requirements. Shouldn't we account for 
>>  this eventuality?
>
> I don't like this restriction anyways. Any objection to lifting it?

(I don't feel qualified to have an opinion on this issue.)

>>  - The scope of the :once modifier could be a bit confusing. I am  
>>  assuming it holds for the whole Sieve execution and not only for 
>>  the identical include commands within the current script.
>
> Correct. Could you suggest how I might clarify that it's the whole 
> execution? I feel like I'm missing the right word for being inside 
> one file vs. being inside one delivery/execution instance.

I think that's enough of an issue that it's worth a whole sentence or two.

I like precise words. But sometimes you can be as precise as you want, 
and someone will read the text after being up half the night with the 
crying baby and won't get it.

Or zero words perhaps. Why is :once justified? is "mandatory :once" or 
":once not supported" good enough?

Arnt

Date: Sat, 11 Apr 2009 10:02:11 +0200
From: Stephan Bosch <[email-masked]>
To: Aaron Stone <[email-masked]>
CC: SIEVE <[email-masked]>
Subject: Re: Questions and remarks on draft-ietf-sieve-include-01.txt
Sender: [email-masked]

Hi Aaron,

Aaron Stone wrote:
> Thanks for your comments. I'd been preparing to send an email to the list
> announcing the changes and requesting feedback. You've touched on all the
> good points. So let's run with this thread!
> 
> On Sat, 11 Apr 2009 01:39:58 +0200, Stephan Bosch <[email-masked]>
> wrote:
>> First of all, I am very glad that the work on the specification is being 
>> continued now. This week I quickly updated my implementation to match 
>> the new specification. Merging import and export into a single global 
>> command is a good choice. The use of a global variable namespace is also 
>> a good idea (but I did not implement that yet).
> 
> I actually wonder if we should drop the global keyword and rely on
> namespaces entirely.
The global namespace has one disadvantage: it makes all global variable 
names longer ('global.*'). Especially when a variable is used often in a 
script, this may become tedious. Using the global command, it is 
possible to pull global variables into the script namespace, which is 
convenient in such situations. I guess it would be best to support both 
methods of accessing global variables (and to even allow mixing these 
freely).

>> - Where the ManageSieve protocol specifies what characters are allowed 
>> for a script name, the include extension for the Sieve language does 
>> not. Would it be useful to adopt the same limitations? Especially things 
>> like '/' can cause problems.
> 
> Good suggestion. I think this makes sense to give a consistent opinion on
> what script names should look like, but on the other hand, perhaps it's
> possible that someone isn't using ManageSieve but IS using include and
> might need to get at weird names? Do we care in that case?
You can also make it a recommendation. As long as implementers know that 
there is some consensus about what a script name is supposed to be and 
that script names should not be mapped directly to files for security 
reasons.

>> - The global command is required to follow 'require' or another global 
>> command. I am worried what happens when other extensions have commands 
>> with similar requirements. Shouldn't we account for this eventuality? 
> I don't like this restriction anyways. Any objection to lifting it?
Hmm, interesting suggestion. The main implication of this is that the 
inclusion of global variables into the script namespace can become 
conditional, i.e. when it is placed into an if statement. I don't know 
whether this is desirable.

You could also state that the global command needs to be placed after 
require commands or any command that also needs to be placed directly 
below the require commands (choose better wording though). This implies 
no ordering between the commands that follow the require section, 
avoiding problems with future commands with similar needs.

>> - Are there any special security implications for using variables in the 
>> value argument in the include command, i.e. to include a script 
>> specified by a variable? Is that even (intended to be) allowed?
> 
> Oh, that's a good question. That'd be an easy vector for contamination of
> email contents into a filesystem request. Can we reasonably place such a
> restriction, though? I'd hate to force implementations to special-case
> their string expansions.
Other extensions already have such limitations (e.g. notify) and the 
variables extension explicitly states that future commands may choose 
not to allow variables in some of their arguments (the so-called 
constant string). However, I agree that we should not limit the 
flexibility of the command more than necessary. Perhaps an explicit 
mention in the Security Considerations section would suffice to cover 
our bases.

On the other hand, one may argue how useful it is to use variables in 
the include argument in the first place: there are a (known) limited 
amount of scripts in the Sieve storage and making choices can be done 
using if commands surrounding multiple alternative include commands.

People using variables could even make their scripts highly unreliable, 
since include commands kill Sieve execution when the indicated script 
does not exist. Perhaps in combination with an ':optional' modifier, 
variables could be used to change the behavior of a script without 
actually modifying it. For instance, when a script is added to the Sieve 
store with a name that matches the sender address, it is included 
automatically when a message from that person comes in. That sounds a 
bit freaky though :)

>> - The scope of the :once modifier could be a bit confusing. I am 
>> assuming it holds for the whole Sieve execution and not only for the 
>> identical include commands within the current script.
> 
> Correct. Could you suggest how I might clarify that it's the whole
> execution? I feel like I'm missing the right word for being inside one file
> vs. being inside one delivery/execution instance.
I am still not sure what to do here. I guess it is also important to 
mention that the scope of the :once modifier does not extend into the 
other scripts of a multiscript sequence (and any scripts included by 
those).. or does it? For this distinction it matters whether you call it 
the 'whole Sieve execution', as this would include truly everything.

Regards,

-- 
Stephan Bosch
[email-masked]

Date: Fri, 10 Apr 2009 17:37:39 -0700
From: Aaron Stone <[email-masked]>
To: Stephan Bosch <[email-masked]>
Cc: SIEVE <[email-masked]>
Subject: Re: Questions and remarks on draft-ietf-sieve-include-01.txt
Sender: [email-masked]

Thanks for your comments. I'd been preparing to send an email to the list
announcing the changes and requesting feedback. You've touched on all the
good points. So let's run with this thread!

On Sat, 11 Apr 2009 01:39:58 +0200, Stephan Bosch <[email-masked]>
wrote:
> Hi,
> 
> First of all, I am very glad that the work on the specification is being 
> continued now. This week I quickly updated my implementation to match 
> the new specification. Merging import and export into a single global 
> command is a good choice. The use of a global variable namespace is also 
> a good idea (but I did not implement that yet).

I actually wonder if we should drop the global keyword and rely on
namespaces entirely.

> During implementation I collected some remarks and questions:
> 
> - Where the ManageSieve protocol specifies what characters are allowed 
> for a script name, the include extension for the Sieve language does 
> not. Would it be useful to adopt the same limitations? Especially things 
> like '/' can cause problems.

Good suggestion. I think this makes sense to give a consistent opinion on
what script names should look like, but on the other hand, perhaps it's
possible that someone isn't using ManageSieve but IS using include and
might need to get at weird names? Do we care in that case?

> - For the global command I would expect text stating that the variables 
> extension is required when it is used.

Will add.

> - The global command is required to follow 'require' or another global 
> command. I am worried what happens when other extensions have commands 
> with similar requirements. Shouldn't we account for this eventuality?

I don't like this restriction anyways. Any objection to lifting it?

> - Are there any special security implications for using variables in the 
> value argument in the include command, i.e. to include a script 
> specified by a variable? Is that even (intended to be) allowed?

Oh, that's a good question. That'd be an easy vector for contamination of
email contents into a filesystem request. Can we reasonably place such a
restriction, though? I'd hate to force implementations to special-case
their string expansions.

> - The scope of the :once modifier could be a bit confusing. I am 
> assuming it holds for the whole Sieve execution and not only for the 
> identical include commands within the current script.

Correct. Could you suggest how I might clarify that it's the whole
execution? I feel like I'm missing the right word for being inside one file
vs. being inside one delivery/execution instance.

> - Take a good look at the examples: they have small typos and syntax 
> problems:
>    * page 6; spam_tests: reject command has mandatory message argument
>    * page 7; spam_tests: reject command has mandatory message argument
>    * page 8; active script: test-mailbox is not a valid variable name
>    * page 8; active script: missing require for relational extension
>    * page 9; active scropt: :count match type needs an argument, e.g.
>      "eq"
>    * page 9; active script: "spam-${test}; <- missing "

Will correct these.

> Please let me know what you think.

Thanks!
Aaron

Date: Sat, 11 Apr 2009 01:39:58 +0200
From: Stephan Bosch <[email-masked]>
To: SIEVE <[email-masked]>
Subject: Questions and remarks on draft-ietf-sieve-include-01.txt
Sender: [email-masked]

Hi,

First of all, I am very glad that the work on the specification is being 
continued now. This week I quickly updated my implementation to match 
the new specification. Merging import and export into a single global 
command is a good choice. The use of a global variable namespace is also 
a good idea (but I did not implement that yet).

During implementation I collected some remarks and questions:

- Where the ManageSieve protocol specifies what characters are allowed 
for a script name, the include extension for the Sieve language does 
not. Would it be useful to adopt the same limitations? Especially things 
like '/' can cause problems.

- For the global command I would expect text stating that the variables 
extension is required when it is used.

- The global command is required to follow 'require' or another global 
command. I am worried what happens when other extensions have commands 
with similar requirements. Shouldn't we account for this eventuality?

- Are there any special security implications for using variables in the 
value argument in the include command, i.e. to include a script 
specified by a variable? Is that even (intended to be) allowed?

- The scope of the :once modifier could be a bit confusing. I am 
assuming it holds for the whole Sieve execution and not only for the 
identical include commands within the current script.

- Take a good look at the examples: they have small typos and syntax 
problems:
   * page 6; spam_tests: reject command has mandatory message argument
   * page 7; spam_tests: reject command has mandatory message argument
   * page 8; active script: test-mailbox is not a valid variable name
   * page 8; active script: missing require for relational extension
   * page 9; active scropt: :count match type needs an argument, e.g.
     "eq"
   * page 9; active script: "spam-${test}; <- missing "

Please let me know what you think.

Regards,

-- 
Stephan Bosch
[email-masked]

Date: Thu, 9 Apr 2009 09:16:43 +0100
Subject: [sieve-in-xml] Example Scripts For Integration Testing
From: Robert Burrell Donkin <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

i'm much happier with the current sieve-in-xml draft. we hope to ship
JSieve soon with experimental preview partial support with the hope
that usage by developers may help to understand whether any issues
have been missed, with a complete implementation would be targetted
for the next release.

however, to confidently ship a library claiming full support, a
reasonably large and fully debugged corpus of integration tests is
needed: basically, example sieve scripts together with corresponding
sieve-in-xml documents. IMO this is the sort of data which is usually
best developed and debugged collectively.

from the sieve working group charter:

<blockquote cite='http://www.ietf.org/html.charters/sieve-charter.html'>
(5) Produce one or more informational RFCs containing a set of test
scripts and test email messages that are to be filtered by the scripts,
and the expected results of that filtering. This will serve as the basis
of a interoperability test suite to help determine the suitability of
moving the base specification and selected extensions to Draft status.
</blockquote>

as i read this, a collection of example sieve scripts and sieve-in-xml
documents is out of scope for this group (hopefully people will jump
in if my reading is incorrect)

so, i was wondering whether there is any interest from members of the
group in collaborating offshore (http://code.google.com, say) on
creating and debugging such a corpus as an open source project under a
very permissive license (MIT, say), or whether there are any other
good ways that such a corpus could be created and made freely
available

- robert

Date: Tue, 7 Apr 2009 15:34:45 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: notify and valid_notify_method
Sender: [email-masked]

Arnt