[Top] [All Lists]

Re: Questions and remarks on draft-ietf-sieve-include-01.txt

2009-05-04 17:38:18

I'm posting draft-ietf-managesieve-02 that addresses these comments. Thank

On Sat, 11 Apr 2009 10:02:11 +0200, Stephan Bosch 
Hi Aaron,

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

On Sat, 11 Apr 2009 01:39:58 +0200, Stephan Bosch 
First of all, I am very glad that the work on the specification is

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

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 

- 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

like '/' can cause problems.

Good suggestion. I think this makes sense to give a consistent opinion
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 

- 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

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