ietf-mta-filters
[Top] [All Lists]

Re: WGLC on draft-freed-sieve-ihave-02.txt

2008-09-14 17:37:48

I have one final remark/concern on this solution
however. Consider the following script:

require "ihave";
require "fileinto";

if ihave "frop" {
   friep "This is a nifty feature.";
}

if header "X-Important" "yes" {
   filinto "Important";
}

Now assume that this script is uploaded through ManageSieve. As you
know, ManageSieve compiles the script during upload to prevent the user
from installing a broken script.

Yes, it is supposed to do a validity check. The exact requirement currently
is:

 The server MUST check the submitted script for syntactic validity, which
 includes checking that all Sieve extensions mentioned in Sieve script "require"
 statement(s) are supported by the Sieve interpreter.

From what I understand from your
explanation, the obvious typo 'filinto' will not be noticed during
compile (because it may be part of the obscure "frop" extension that
could be enabled by ihave throughout the rest of the script) and the
ManageSieve upload will succeed.

Yes, that's indeed the case.

During runtime however, the script will
intermittently fail when the header test is true. Is there a way to get
around this issue?

Not that I know of. I wish there were, but the problem is the only way I see to
"fix" this is to go back to making ihave only activate extensions for the
duration of the enclosed block. I actually have a way to implement that, but
it's due in large part to our having a separate compilation step. I fear that
reimposing that requirement will make ihave difficult or even impossible to
support ihave in a more straightforward implementation. I also think that while
having ihave track block structure may be more obvious to veteran programmers,
it isn't nearly so clear to people with less programming experience, and while
absolute newbies aren't the target audience for handcoded sieves, people
with only limited programming experience are.

I do note that this doesn't violate the managesieve requirement, since only a
syntax and require check are called for there. Of course nothing prevents a
managesieve implementation from doing more checks (our plan for our managesieve
implementation is to simply call our compiler and see what it thinks).

Anyways, I think I should first give implementing this extension a try
before posting more concerns. I may be a bit biased towards finding more
difficulties if I have never actually tried to implement it. I'll keep
you posted when I do.

Thanks will be interesting, thanks.

                                Ned

P.S. One unfortunate tendency I've seen is for automatically generated Sieves
to unconditionally include a require clause listing every extension the
generator knows about, regardless of whether the current Sieve actually uses
it. Of course this is bad for all sorts of reasons, including unecessarily
limiting script portability and increased overhead (e.g., saving match results
and scanning for substitutions if variables are enabled, per-recipient
evaluation if envelope is used, etc.). Unnecesary use of ihave will add "limits
the ability to perform validity checks" to that list.