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

[Aaron Stone <aaron@xxxxxxxxxxxxxx>]

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

On Sat, 11 Apr 2009 10:02:11 +0200, Stephan Bosch <stephan@xxxxxxxxxxxx>
wrote:
> 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 <stephan@xxxxxxxxxxxx>
>> 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,