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? How about it
keeps malicious users from using Sieves to construct enormous mailbombs?
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 have to say I regard not having such a limit as
irresponsible.
I thought it might be useful to be able to advertise such limit in
ManageSieve, so that clever UI editors can do clever things. Thoughts?
Seems very reasonable to me. Just make sure it's clearly a limit on the
number
of redirect actions a script can perform during a single evaluation. There
should be no limit on the number of redirects a script can contain.
if it's a limit on the number of redirect actions a script can perform
during a single evaluation (and not a limit on the number of redirects
a script can contain), then what clever things would you expect a
clever editor to be able to do?
Simple: A clever editor wouldn't let a user construct a Sieve that performs
more than that many redirects in a single block.
Whether or not such a case can arise depends on how the editor works, of
course. A limited editor that only allows construction of Sieves of the general
form
if single-test1 {single-action1;}
if single-test2 {single-action2;}
gets little if any benefit from this, but a more sophisticated editor that
allows the construction of things like:
if test {action1; action2; action3;}
would definitely benefit.
Ned