Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
As I observed in my original review, I believe you may be able to
construct a loop using the redirect construct. It's not a loop internal
only to the sieve-processing MTA, but that doesn't mean it's not a loop.
First of all, a message forwarding loop is a totally different sort of
beast,
one that has no bearing on the computational complexity and difficulty of
processing a single sieve script, which is all we're talking about here.
Well, I think this is a reasonable point, but not one with which I
entirely agree. The larger security question is what the impact of
allowing partly-untrusted users from putting sieve scripts on
one's server is, and this kind of message forwarding loop is relevant
for that.
Given that many clients have the ability to autoforward without any server-side
involvment at all or with any sieve support, I'm having a hard seeing this as a
problem sieve brings to the table and therefore deserves lots of attention in
the sieve context. Even so, I have no objection to adding some language
discussing mail loops specifically to the security considerations section. The
real question is how far should this go? Simply saying that sieve redirect is
another autoforwarding mechanism that can be complicit in mail loops might
alert someone to the issue (although anyone who deals with email implementation
is likely to be well aware of it already), but doesn't explain the bag of
tricks needed to deal with the issue. An entire document can (and arguably
should) be written about this stuff, but this WG really isn't the right place
to do all that.
The more complex issues that some sieve extension raise definitely need to be
dealt with in the documents describing those extensions. In the case of notify
specifically I think it is really important that a standard loop detection
mechanism be defined, because if we leave it up to each implementation to come
up with a way to do it two or more party loops involving systems using
different detection mechanisms are still possible.
Ned