Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
OK, but the problem is that the text above isn't correct. The language
*does* have loops,
Really? That's news to me. The loop construct that has been proposed for
sieve
isn't a loop in the usual programming language sense - rather, it allows for
fixed iteration over the MIME structure of the message. AFAIK there's no
way to
create an infinite loop or even a loop where the number of iterates is set
by
the script. And this is in any case an extension, not something in the core
language.
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.
Discussion of message loops is a huge and involved topic that has almost
nothing to do with sieve - and sieve doesn't add or subtract anything from the
existing landscape in this area.
Second, sieve redirect is neither necessary nor sufficient to create such
loops. Pretty much any forwarding mechanism in existance can be used to create
them. But as a direct consequence of the ease with which such loops can be
created, messaging standards have for decades required that compliant systems
check for and prevent such loops from occuring. (As I hope you're aware, common
mechanisms for dealing with the simpler forms of loops involve counting
Received: fields, adding your own tag somewhere, and so on.)
Indeed, it's not clear to me that the langague isn't Turing complete at
this
point.
Then please provide a script that loops indefinitely. I don't know how to
construct one myself.
Well, I'm no mail expert, but it looks to me that if you write a
redirect rule that goes to an unknown address, it may be possible
to create a loop. The key question is what the envelope sender
address is, which sieve leaves open (S 4.2).
The envelope sender address on the outgoing message is chosen by the
sieve implementation. It MAY be copied from the original message.
If you your own address, this creates a loop, right?
Not with any reasonably implemented messaging system, no. Given the existance
of forwarding mechanisms that change envelope addrresses (as you say, redirect
may do this in some implementations, but there are plenty of other
autoforwarders out there that this a lot more often than sieve interpreters
do), one of the checks you need to make is to see whether or not you're dealing
with a deeply nested DSN, and if you are, refuse to transfer the thing.
A more interesting case arises in the sieve notify extension (currently in
draft). Since this for the creation of an entirely new message that can be sent
right back to same sieve script, it is possible to construct loops where each
time around you're dealing with a completely different message with nothing in
common with its predecessors. This case definitely needs to be looked at before
notify is standardized.
Ned