Subject: Advertising per-server limit on number of redirects in ManageSieve

From: Alexey Melnikov <[email-masked]>
Date: Sat, 13 Sep 2008 16:26:04 +0100

I've recently added an option to my Sieve implementation to limit the 
number of Sieve redirects in a script.
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?

---

From: Ned Freed <[email-masked]>
Date: Sat, 13 Sep 2008 09:27:05 -0700 (PDT)

> number of Sieve redirects in a script.

We have a similar option.

> 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.

				Ned

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sat, 13 Sep 2008 19:36:38 +0100

> We have a similar option.

any particular reason for adding this restriction?

> 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?

- robert

---

From: Ned Freed <[email-masked]>
Date: Sat, 13 Sep 2008 12:59:33 -0700 (PDT)

> 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.

> 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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sun, 14 Sep 2008 09:17:36 +0100

On Sat, Sep 13, 2008 at 8:59 PM, Ned Freed <[email-masked]> wrote:
> 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. 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.

> How about it keeps malicious users from using Sieves to construct enormous mailbombs?

just wanted to be clear that this is a security restriction

> 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 have to say I regard not having such a limit as irresponsible.

from a systematic perspective, i agree. less sure about imposing
inefficient division of labour between library and system, though.

> more than that many redirects in a single block.

ok - so it's about allowing a simple check for a clear use case
(rather than anything more comprehensive). makes sense.

> would definitely benefit.

+1

BTW do any sophisticated editors actually exist yet?

- robert

---

From: Ned Freed <[email-masked]>
Date: Sun, 14 Sep 2008 04:02:48 -0700 (PDT)

> "flatly" seems to be a little of an overstatement.

OK...

> the RFC seems to be

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.

> effects. IMHO a more likely scenario would be a bug in a sieve

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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sun, 14 Sep 2008 13:58:13 +0100

On Sun, Sep 14, 2008 at 12:02 PM, Ned Freed <[email-masked]> wrote:
> I have no idea what a "system assembler" is or how it relates to this.

it's a role. if you're doing COP then an application is composed by
assembling various components together. the system assembler is one
name given to individual responsible for assembly.

> If  you're talking about implementing the limit exclusively in the script editor or
> user be able to install a script through any other means.

no: that's not what i'm taking about

> Email systems can be
> very complicated with lots of different ways of doing things,

true

which means that responsibility for checking this should probably fall
to the application creator (if you prefer that term) rather than a
component creator

> making it very hard to guarantee the effectiveness of anything other than a hard evaluation
> time limit.

depends on what you mean by evalution time. i agree if you mean action
execution time.

> I also cannot think of anything simplier than a counter and test in the Sieve

the downside of this separation of concerns is that the script
interpretor may not really know what actions an application is
actually going to perform upon redirect

<snip>

> project and I simply do not have the time.

it might be possible to use the eclipse to generate an editor from the
xml version of sieve but sieve is not expressive enough ATM for my
mail filtering (i generate my scripts from higher level meta-data) so
creating a basic editor is of no interest to me

- robert

---

From: Ned Freed <[email-masked]>
Date: Sun, 14 Sep 2008 09:15:35 -0700 (PDT)

> name given to individual responsible for assembly.

I'm afraid this still doesn't make sense to me.

> no: that's not what i'm taking about

OK, I guess then what you're talking about is how this limit is consumed
by things that create scripts. Right?

> to the application creator (if you prefer that term) rather than a

Again, this just isn't how I think of these things. But I don't think it really
matters.

> depends on what you mean by evalution time. i agree if you mean action

That's exactly what I was talking about.

> actually going to perform upon redirect

I don't think it's that variable. Unlike fileinto, which allows for a fairly
wide range of implementation strategies and associated costs, redirect's
requirements limit implementation options pretty dramatically. In particular,
the fact that it takes an arbitrary email address as an argument and requires
that the message sent to that address be modified from the original (with, at a
minimum, the addition of a Received: line), there are always going to be cases
that have to be handled by resubmission. And since email in general operates
with limited, local knowledge, there's no way to know how many recipients will
eventually receive the resubmitted message. So it's impossible to try and
impose a limit on that - the necessary  infrastructure just isn't there.

So unless you're in a very specialized environment that isolated from the
Internet and has this kind of information available, the limit pretty much has
to be on the number of redirects a script perform. If you want to get really
fancy you could make that process use  a more complex limit that allowed, say,
an arbitrary number of local addresses or something like that, but I really
question whether this is a good idea - how are you going to present this limit
to your users?

				Ned