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.
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.
I'm afraid this still doesn't make sense to me.
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.
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?
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
Again, this just isn't how I think of these things. But I don't think it really
matters.
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.
That's exactly what I was talking about.
I also cannot think of anything simplier than a counter and test in the
Sieve
evaluator.
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
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