On Sat, Sep 13, 2008 at 8:59 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
On Sat, Sep 13, 2008 at 5:27 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
I've recently added an option to my Sieve implementation to limit the
number of Sieve redirects in a script.
We have a similar option.
any particular reason for adding this restriction?
You mean aside from the fact that RFC 5228 flatly requires it?
from RFC5228:
10. Security Considerations
...
(2) MUST provide the means for administrators to limit the ability of
users to abuse redirect. In particular, it MUST be possible to
limit the number of redirects a script can perform.
Additionally, if no use cases exist for using redirect to
multiple destinations, this limit SHOULD be set to 1. Additional
limits, such as the ability to restrict redirect to local users,
MAY also be implemented.
"flatly" seems to be a little of an overstatement.
OK...
the RFC seems to be
agnostic about the way this effect should be achieved. there is a
reasonable argument that this requirement may be better implemented by
a system assembler than in a script interpretor.
I have no idea what a "system assembler" is or how it relates to this. If
you're talking about implementing the limit exclusively in the script editor or
managesieve interface, the problem with that is it leeaves a hole should any
user be able to install a script through any other means. Email systems can be
very complicated with lots of different ways of doing things, making it very
hard to guarantee the effectiveness of anything other than a hard evaluation
time limit.
I also cannot think of anything simplier than a counter and test in the Sieve
evaluator.
How about it keeps malicious users from using Sieves to construct enormous
mailbombs?
just wanted to be clear that this is a security restriction
Perhaps I wasn't clear. This is not a new option we just implemented. It has
been part of our implementation from the beginning. While I continue to
think
that the IESG concerns with redirect issues during the process that led up
to
RFC 5228 were overblown,
i agree. i think there are much easier ways to achieve similar
effects. IMHO a more likely scenario would be a bug in a sieve
interpretor or editor.
I don't think such an interpreter bug is all that likely, especially since it
would have to produce a finite number of bogus redirects and then terminate.
Where's the loop that could go wonkly and have that effect? An editor problem
would be much more likely, but pretty much any sort of limit will prevent bad
behavior in such cases.
...
BTW do any sophisticated editors actually exist yet?
I've seen editors that allow the construction of fairly complex rules. But I
don't think this makes them "sophisticated". "Sophisticated" in my book means
an editor that operatoes on the actual Sieve code rather than depending on some
kind rule metadata (usually embedde in script comments) to figure out what's
going on. A really sophisticsted one would handle nested conditionals and other
more complex coding structures.
And the answer is no, I haven't seen any editors I would regard as truly
sophisticated. I'd like to try and write one myself, but it's a really big
project and I simply do not have the time.
Ned