Re: sieve/managesieve/time and ACL

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Sat, 13 May 2006 19:46 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4DJkhQk041802; Sat, 13 May 2006 12:46:43 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4DJkhCI041801; Sat, 13 May 2006 12:46:43 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4DJkfhg041787 for <ietf-mta-filters@imc.org>; Sat, 13 May 2006 12:46:42 -0700 (MST) (envelope-from arnt@gulbrandsen.priv.no)
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 9547C4AC32; Sat, 13 May 2006 21:46:37 +0200 (CEST)
Message-Id: <9WUouwjK/FVeWLIiHdo+IA.md5@libertango.oryx.com>
Date: Sat, 13 May 2006 21:50:31 +0200
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: ietf-mta-filters@imc.org
Subject: Re: sieve/managesieve/time and ACL
Cc: Ned Freed <ned.freed@mrochek.com>
References: <8lojjOJ0LiRYfWrumr19dw.md5@libertango.oryx.com> <01M2D5WCJXCQ0008CX@mauve.mrochek.com>
In-Reply-To: <01M2D5WCJXCQ0008CX@mauve.mrochek.com>
Content-Type: text/plain; format="flowed"
MIME-Version: 1.0
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>

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

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.

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

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