Subject: Re: sieve/managesieve/time and ACL

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 12 May 2006 19:59:59 +0200

Ned Freed writes:
> The implication here is that you might want to check fileinto validity 
> in managesieve.

Right, with emphasis on the might. I'm all in favour if picking 
low-hanging fruit.

>  I'm very dubious about this being a good idea - in addition to ACLs 
> changing after the fact, there's also the issue of uploading the 
> sieve referring to the mailbox before the mailbox is created.

I believe that managesieve, as well as pretty much every other piece of 
software, should perform all the sanity checks it easily can. If 
putscript can easily check more than just syntax, it should.

> I also suspect that in many architectures it would be quite difficult 
> to perform such a check. It certainly is next to impossible to do a 
> meaningful check of this sort in ours.

Then don't do it ;)

>> What should happen when a message arrives and the script wants to
>> fileinto? I can't find any mention at all of access control in 3028bis,
>> far less of access control which changes after the sieve is blessed by
>> managesieve.
>
> We handle this case essentially by converting the fileinto into a 
> keep. I don't thinking requiring such behavior is a good idea, 
> however, we might want to point out the issue and suggest this as one 
> way to deal with it.

Yes (in a more general form, ideally).

Arnt

---

From: Ned Freed <[email-masked]>
Date: Sat, 13 May 2006 07:27:10 -0700 (PDT)

> putscript can easily check more than just syntax, it should.

Again, this check seems like it forces an unnecessary ordering on how users
set things up. I don't think that's a good idea.

> Then don't do it ;)

I wouldn't even if it was easy to do.

> Yes (in a more general form, ideally).

In any case, some discussion of how to handle error conditions that creep
in between sieve evaluation and execution of the resulting actions would
be fine.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 13 May 2006 21:50:31 +0200

Ned Freed writes, answering me:
>> I believe that managesieve, as well as pretty much every other piece 
>> of software, should perform all the sanity checks it easily can. If 
> Again, this check seems like it forces an unnecessary ordering on how 
> users set things up. I don't think that's a good idea.

I agree with you in general, or so I think, but this is a fairly extreme 
case. If you're uploading a sieve script that runs fileinto on someone 
else's mailbox, I don't think it's unreasonable to make that someone 
grant permission first.

A more regular case, such as fileinto a nonexistent mailbox in the 
user's own mailbox subtree, is different IMO. It's conveivable that the 
MUA issues PUTSCRIPT first, then uses IMAP to CREATE the necessary 
mailbox(es) if PUTSCRIPT goes through. It's also reasonable that the 
mailbox is created on delivery.

But the extreme case is different: It's difficult to conceive of an MUA 
that does PUTSCRIPT, then logs in via IMAP as a different user and does 
SETACL to grant permission.

I think that this applies to all circumstances which ensure that the 
sieve cannot work as specified if made active now and which cannot be 
corrected by the user within the system. Possible candiates (many of 
which are hard to test):
1. redirect to a nonexistent domain
2. redirect to a nonexistent local address
3. fileinto a mailbox with a name that the local software does not support
4. fileinto a mailbox to which the user does not have the insert right 
and to which the user cannot himself grant the insert right
5. fileinto a mailbox which does not exist and which cannot be created 
by the user

If the managesieve draft ends up mentioning checks on anything other 
than pure syntax, then I think no. 3 above is a good example.

> In any case, some discussion of how to handle error conditions that 
> creep in between sieve evaluation and execution of the resulting 
> actions would be fine.

Do you mean evaluation by managesieve during putscript, or evaluation by 
the sieve processor when a message is received? I agree in either case.

Arnt