Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Eric did security related review. Here are some comments/suggestions from
him, slightly reworded by me. Eric will correct me if I misrepresented
anything:
1) In section 1:
Eric felt that claims in the following paragraph are overstrong:
The language is powerful enough to be useful but limited in order to
allow for a safe server-side filtering system. The intention is to
make it impossible for users to do anything more complex (and
dangerous) than write simple mail filters, along with facilitating
the use of GUIs for filter creation and manipulation. The language
is not Turing-complete: it provides no way to write a loop or a
function and variables are not provided.
He suggested the following replacement:
The language is intentionally simple in order to make implementing
secure implementations easier. However, several Sieve features do
allow Sieve scripts to consume significant resources and thus
implementors and administrators must take care to appropriately
limit the amount of resources consumed by individual users.
I don't think this is an appropriate change. In particular, I think it is
important to keep the language about sieve not being TUring complete. I
have no
objection to toning down the claims (although I do think it is unnecessary),
but it is critical that we document the underlying language design
philosophy.
OK, but the problem is that the text above isn't correct. The language
*does* have loops,
Really? That's news to me. The loop construct that has been proposed for sieve
isn't a loop in the usual programming language sense - rather, it allows for
fixed iteration over the MIME structure of the message. AFAIK there's no way to
create an infinite loop or even a loop where the number of iterates is set by
the script. And this is in any case an extension, not something in the core
language.
and draft-ietf-sieve-variables-08 defines variables.
Again, this is an extension, not a component of the core specification. It was
done this way for a reason - it is well known that variables introduce resource
consumption issues (as does body part iteration). Regardless, as I said, I
would have no problem losing this claim.
Indeed, it's not clear to me that the langague isn't Turing complete at this
point.
Then please provide a script that loops indefinitely. I don't know how to
construct one myself.
Ned