Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7U0ANgc018886 for ; Fri, 29 Aug 2003 17:10:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7U0ANwe018885 for ietf-imapext-bks; Fri, 29 Aug 2003 17:10:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7U0ALgc018878 for ; Fri, 29 Aug 2003 17:10:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-a-83.buf.adelphia.net [24.51.28.83]) (authenticated bits=0) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7U0AIX0003671 for ; Fri, 29 Aug 2003 20:10:19 -0400 (EDT) Message-ID: <3F4FEB67.3050100@oceana.com> Date: Fri, 29 Aug 2003 20:10:15 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > > On Friday, Aug 29, 2003, at 20:52 Europe/Helsinki, Mark Crispin wrote: > >> I agree with this concern. CHILDREN information should not be included >> unless the client does something to request it. I thought that we had >> agreed to do this. > > > LIST () "" % should not return it, but for backwards compatibility I > think the old style LIST should return it when it can. I agree. LIST () "" % returns no children info, but LIST "" % does return info in the presence of the (obsolete?) CHILDREN extension. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TNongc018310 for ; Fri, 29 Aug 2003 16:50:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TNontm018309 for ietf-imapext-bks; Fri, 29 Aug 2003 16:50:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TNokgc018296 for ; Fri, 29 Aug 2003 16:50:47 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id B86F923A60; Sat, 30 Aug 2003 02:50:38 +0300 (EEST) Received: from iki.fi (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id A09A7238C9; Sat, 30 Aug 2003 02:50:36 +0300 (EEST) Date: Sat, 30 Aug 2003 02:50:54 +0300 Subject: Re: Last Calling the LISTEXT draft? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Pete Maclean , IMAP extensions Mailing List To: Mark Crispin From: Timo Sirainen In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, Aug 29, 2003, at 20:52 Europe/Helsinki, Mark Crispin wrote: > I agree with this concern. CHILDREN information should not be included > unless the client does something to request it. I thought that we had > agreed to do this. LIST () "" % should not return it, but for backwards compatibility I think the old style LIST should return it when it can. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7THqngc097008 for ; Fri, 29 Aug 2003 10:52:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7THqnCd097006 for ietf-imapext-bks; Fri, 29 Aug 2003 10:52:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7THqlgc096990 for ; Fri, 29 Aug 2003 10:52:47 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.08) with ESMTP id h7THqcHE002474; Fri, 29 Aug 2003 10:52:43 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7THqcb5007754; Fri, 29 Aug 2003 10:52:38 -0700 Date: Fri, 29 Aug 2003 10:52:38 -0700 (PDT) From: Mark Crispin To: Pete Maclean cc: IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? In-Reply-To: <5.1.1.6.2.20030829133242.049f0458@pop.webcom.com> Message-ID: References: <3F420A9B.40406@isode.com> <5.1.1.6.2.20030829133242.049f0458@pop.webcom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 29 Aug 2003, Pete Maclean wrote: > As I understand it, this means that a client that wants to take advantage > of LISTEXT has to put up with a server's sending \HasChildren or > \HasNoChildren for every single mailbox LISTed, should the server choose to > do that, even if the client does not value that information and does > nothing with it. This adds an average of about 14 characters to every > listing. That is not going to add up to much in the typical case but, in a > time when we are seeing the BINARY extension introduced to reduce the > amount of data sent over slow wireless connections, is this the direction > we want to go in? I agree with this concern. CHILDREN information should not be included unless the client does something to request it. I thought that we had agreed to do this. Besides adding chatter which may be unnecessary, CHILDREN information may be expensive to obtain. There's no reason to put the server to the work if the client doesn't care. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7THiNgc096670 for ; Fri, 29 Aug 2003 10:44:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7THiNsn096669 for ietf-imapext-bks; Fri, 29 Aug 2003 10:44:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from curly.webcom.com (curly.webcom.com [192.220.116.140]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7THiNgc096664 for ; Fri, 29 Aug 2003 10:44:23 -0700 (PDT) (envelope-from aaddict@maclean.com) Received: from kigal (kigal.webcom.com [192.220.116.57]) by curly.webcom.com (8.11.6/8.9.3) with SMTP id h7THgmS30763 for ; Fri, 29 Aug 2003 10:42:59 -0700 Received: from [216.207.178.10] by banana (WebCom SMTP 2.0) with SMTP id 190082244; Fri Aug 29 10:44 PDT 2003 Message-Id: <5.1.1.6.2.20030829133242.049f0458@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 29 Aug 2003 13:44:47 -0400 To: "IMAP extensions Mailing List" From: Pete Maclean Subject: Re: Last Calling the LISTEXT draft? In-Reply-To: <004701c3668b$9200d040$40280209@watson.ibm.com> References: <3F420A9B.40406@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mimeheaders-Plugin-Info: v2.03.00 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is anyone concerned about the opportunity for the possibly undesired verbosity allowed by LISTEXT? I am specifically thinking about the statement that, "While these attributes [\HasChildren and \HasNoChildren] MAY be returned in response to any LIST command..." As I understand it, this means that a client that wants to take advantage of LISTEXT has to put up with a server's sending \HasChildren or \HasNoChildren for every single mailbox LISTed, should the server choose to do that, even if the client does not value that information and does nothing with it. This adds an average of about 14 characters to every listing. That is not going to add up to much in the typical case but, in a time when we are seeing the BINARY extension introduced to reduce the amount of data sent over slow wireless connections, is this the direction we want to go in? Pete Maclean Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P0d7qt067206 for ; Sun, 24 Aug 2003 17:39:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P0d7Nr067205 for ietf-imapext-bks; Sun, 24 Aug 2003 17:39:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P0d6qt067200 for ; Sun, 24 Aug 2003 17:39:06 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7P0d7tD040583; Sun, 24 Aug 2003 18:39:07 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Sun, 24 Aug 2003 18:39:07 -0600 From: Lyndon Nerenberg To: Paul Smith , imap@u.washington.edu cc: ietf-imapext@imc.org Subject: Designing secure protocols (or: how not to open the barn door) Message-ID: <2147483647.1061750347@[192.168.42.6]> In-Reply-To: <5.2.1.1.2.20030825001327.057c88d8@lmail.pscs.co.uk> References: <5.2.1.1.2.20030823230108.04909370@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> <5.2.1.1.2.20030823230108.04909370@lmail.pscs.co.uk> <5.2.1.1.2.20030825001327.057c88d8@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [This thread is getting far afield from imapext's charter. Let's move it to the IMAP protocol list. PLEASE remove ietf-imapext@imc.org from any replies.] [[Cyrus: why won't Mulberry let me set a Reply-To header?!?]] On Monday, August 25, 2003 12:14 AM +0100 Paul Smith wrote: >> Does LDAP permit an unauthenticated client to obtain a list of >> usernames with which it potentially could authenticate? > > Sometimes, (in a slightly roundabout way) yes - by giving a list of > email addresses which, probably 99% of the time, are directly related > to user names. Thus the requirement for friendly identifiers divorced from authentication identifiers. > Would an IMAP extension? > No - it would only give it to AUTHENTICATED users, obviously. I hope that doesn't include those authenticated as anonymous. It's still a bad idea. If I can guess one password, I can authenticate and then retrieve the list of valid authentication identifiers for my next round of attacks. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P0aOqt067135 for ; Sun, 24 Aug 2003 17:36:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P0aNH2067134 for ietf-imapext-bks; Sun, 24 Aug 2003 17:36:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P0aMqt067126 for ; Sun, 24 Aug 2003 17:36:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-a-83.buf.adelphia.net [24.51.28.83]) (authenticated bits=0) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7P0aBri007835; Sun, 24 Aug 2003 20:36:12 -0400 (EDT) Message-ID: <3F4959F9.2050202@oceana.com> Date: Sun, 24 Aug 2003 20:36:09 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Timo Sirainen CC: ietf-imapext@imc.org, cyrus-bugs@andrew.cmu.edu Subject: Re: acl-08: questions References: <86984702-D687-11D7-9D97-000393CC2E90@iki.fi> In-Reply-To: <86984702-D687-11D7-9D97-000393CC2E90@iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > Hmm. This brings to my mind, Cyrus people might want to look at their > Sieve implementation (lmtpd part I think) a bit more, it looked like > there's still some potential buffer overflows.. Burying this statement in the middle of a totally unrelated thread on a IETF WG mailing list isn't the ideal place for it. If you think you've found something, you should report it to cyrus-bugs. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Fqt066346 for ; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P00FoI066344 for ietf-imapext-bks; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Bqt066330 for ; Sun, 24 Aug 2003 17:00:11 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 32881235C7C for ; Mon, 25 Aug 2003 01:00:10 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Mon, 25 Aug 2003 00:59:32 +0100 Message-Id: <5.2.1.1.2.20030825002338.054ba6f8@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 25 Aug 2003 00:44:24 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030823232646.04d4be70@lmail.pscs.co.uk> <5.2.1.1.2.20030823010843.055d99b8@lmail.pscs.co.uk> <5.2.1.1.2.20030823232646.04d4be70@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:34 24/08/2003 -0700, you wrote: >On Sat, 23 Aug 2003, Paul Smith wrote: > > I think the problem has changed from 'RFC 2086 is not implementable on > > Unix' (which was the original statement) to 'yes, it's implementable, but > > we don't want to because a few people (including the IMAP server > > developers) like some features that we might lose if we do it that way'. > >You have made a completely false statement. I don't think so - you essentially said the same yourself 30 minutes later.. "I am perfectly capable of implementing RFC 2086 in an IMAP server which owns all the mail data." My (and others) 'argument' is that, given that that is the case, is lots of added complexity worth it? This is what should be considered, rather than 'we MUST do it this way because that's the only way it'll work on Unix' >Just because you can create a strawman mockery of another individual's >position does not make that strawman true. I'm sorry, I'm not trying to make a mockery of anything - I just think it ought to be clear that that is the case. There ARE Unix servers which implement RFC 2086. You (and others) don't want to do it that way because you believe you will lose other features which you see as important. This thread of the discussion started because there were statements saying things along the lines of 'we have to have tied rights because it won't work on Unix otherwise' (eg "IMAP ACL has stood out as something that is unimplementable in such environments"), and I responded 'there are ways of making it work on Unix without tied rights' (which you have confirmed). Now, there may be reasons why those ways aren't ideal in some situations, and I've learnt that people in 'Unix world' want to do things to their mailboxes that I'd never have anticipated - but it's still a valid counter-argument to say 'is the extra complexity (in the ACL standard) worth it?' In fact, if you have read my other messages, you'll have seen that I've been contributing to discussions on *HOW* IMAP ACL2 could be improved to allow more flexibility in it's tied rights (without being Unix specific), and considering client issues. I don't see this as trying to 'sabotage' ACL2 as you've been intimating... Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Fqt066347 for ; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P00FRB066343 for ietf-imapext-bks; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Bqt066327 for ; Sun, 24 Aug 2003 17:00:11 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id E58BA2359BB for ; Mon, 25 Aug 2003 01:00:08 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Mon, 25 Aug 2003 00:58:51 +0100 Message-Id: <5.2.1.1.2.20030825001546.0486be30@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 25 Aug 2003 00:17:49 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: LISTRIGHTS command (was Re: acl-08: questions) In-Reply-To: <3F48EB02.7010409@isode.com> References: <5.2.1.1.2.20030822235324.06329188@lmail.pscs.co.uk> <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> <5.2.1.1.2.20030822235324.06329188@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 17:42 24/08/2003 +0100, Alexey Melnikov wrote: >At one point ACL2 had LISTRIGHTS command that allowed the client to query >this information. >In March I've removed it, assuming that most clients will just try to set >a particular right and will do some action based on RIGHTS-INFO response. >Nobody objected. > >Do I see a consensus to add it back (possibly as a new LIST item)? Well, I'd vote to add it back (as either a LIST item or a LISTRIGHTS command). For a nice friendly client UI, it really would be best if it could find out what it could do first. Otherwise the user will get annoyed if he/she tries to do something and it fails. The client wouldn't have to use it if it didn't want, it could just try and change it, if that's what it preferred (eg if it was an automated change) Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Fqt066348 for ; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P00FUJ066345 for ietf-imapext-bks; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Bqt066328 for ; Sun, 24 Aug 2003 17:00:11 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id C2B9D235A02 for ; Mon, 25 Aug 2003 01:00:09 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Mon, 25 Aug 2003 00:58:48 +0100 Message-Id: <5.2.1.1.2.20030825001327.057c88d8@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 25 Aug 2003 00:14:44 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030823230108.04909370@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> <5.2.1.1.2.20030823230108.04909370@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:22 24/08/2003 +0200, you wrote: >Paul Smith writes: >>At 11:06 23/08/2003 -0600, Lyndon Nerenberg wrote: >>>The security implications are by far the most important consideration >>>here. The most valuable tool for performing a dictionary attack is a >>>list of authentication identifiers. Any protocol that serves up such a >>>list on demand doesn't stand a chance of getting past the IESG. >> >>Hmm, so LDAP won't get through either... > >Does LDAP permit an unauthenticated client to obtain a list of usernames >with which it potentially could authenticate? Sometimes, (in a slightly roundabout way) yes - by giving a list of email addresses which, probably 99% of the time, are directly related to user names. Would an IMAP extension? No - it would only give it to AUTHENTICATED users, obviously. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ON62qt065065 for ; Sun, 24 Aug 2003 16:06:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ON62pF065064 for ietf-imapext-bks; Sun, 24 Aug 2003 16:06:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ON5xqt065055 for ; Sun, 24 Aug 2003 16:06:00 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 76274238D4; Mon, 25 Aug 2003 02:05:51 +0300 (EEST) Received: from iki.fi (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 9035F238C5; Mon, 25 Aug 2003 02:05:49 +0300 (EEST) Date: Mon, 25 Aug 2003 02:05:59 +0300 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Paul Smith , ietf-imapext@imc.org To: Mark Crispin From: Timo Sirainen In-Reply-To: Message-Id: <86984702-D687-11D7-9D97-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sunday, Aug 24, 2003, at 19:02 Europe/Helsinki, Mark Crispin wrote: > The former goal, although technically possible, creates the worst of > both > worlds: > 1) If the server is not the owner of the file, it is technically > limited by what UNIX can do with group access rights Then it also means that the user doesn't have +a access to the mailbox. Not really a problem. > 2) Sharing via group access from the shell end is not possible, since > a > file can only be in one group Which is why I said server should try to use real UNIX groups whenever only one group is given access. If user wants to share the mails outside IMAP server, he just wouldn't give ACLs which can't be expressed with UNIX rights. > 3) The server has access to all mail; there is no intrinsic firewall > created by being logged in as a user. A single buffer overflow bug > gives a hacker access to all mail in the system No, server would have access to some, maybe most, shared mailboxes. That's still bad, but not nearly as bad. > (the Cyrus server > has had this security bug; as have numerous UNIX mail programs that > use setgid mail). Hmm. This brings to my mind, Cyrus people might want to look at their Sieve implementation (lmtpd part I think) a bit more, it looked like there's still some potential buffer overflows.. > A good IMAP ACL specification exports the existing ACLs of those mail > stores. I agree it would be nice. I'm just not sure how useful it would be. You're basically allowed to give rights to one group or everyone. I think it's a bit unlikely that you belong to some group which contains only the people who you want to share the mailbox with. Maybe it's manageable if you allow users to create their own new groups in some way. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OGgtqt047050 for ; Sun, 24 Aug 2003 09:42:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7OGgtqX047049 for ietf-imapext-bks; Sun, 24 Aug 2003 09:42:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OGgpqt047044 for ; Sun, 24 Aug 2003 09:42:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Sun, 24 Aug 2003 17:42:45 +0100 Message-ID: <3F48EB02.7010409@isode.com> Date: Sun, 24 Aug 2003 17:42:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Smith CC: ietf-imapext@imc.org Subject: LISTRIGHTS command (was Re: acl-08: questions) References: <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> <5.2.1.1.2.20030822235324.06329188@lmail.pscs.co.uk> In-Reply-To: <5.2.1.1.2.20030822235324.06329188@lmail.pscs.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Smith wrote: > At 18:27 22/08/2003 +0100, Alexey Melnikov wrote: > You could have > >>> ACL "FreeAndEasy" s w i t e l r p c x a g u >>> which supports anything or >>> ACL "VeryLimited" switecxa lr p u1 >>> which has a 'read' and a 'write' mode only and only supports a >>> single user and no groups >>> >>> For the Posix case, even if the client didn't understand that case >>> specifically it could tie the 'swite' checkboxes (or whatever) >>> together, and could only allow the selection of a single user, and >>> multiple groups as the identifier. >> >> >> I think I mostly like this. >> Also note, that currently RIGHTS-INFO response returns "switecxa lr >> p" part of the >> ACL "VeryLimited" switecxa lr p u1 > > > Yes, I know (that's why I chose that syntax), but (IMHO) it's too late > by then - RIGHTS-INFO only comes when an ACL-STORE command fails. It'd > be better (from the client viewpoint) to be able to ask for it without > having to come up with a failing ACL-STORE command and then undo it. At one point ACL2 had LISTRIGHTS command that allowed the client to query this information. In March I've removed it, assuming that most clients will just try to set a particular right and will do some action based on RIGHTS-INFO response. Nobody objected. Do I see a consensus to add it back (possibly as a new LIST item)? Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OGRtqt046621 for ; Sun, 24 Aug 2003 09:27:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7OGRtVf046620 for ietf-imapext-bks; Sun, 24 Aug 2003 09:27:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OGRsqt046613 for ; Sun, 24 Aug 2003 09:27:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Sun, 24 Aug 2003 17:27:38 +0100 Message-ID: <3F48E778.4030702@isode.com> Date: Sun, 24 Aug 2003 17:27:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timo Sirainen CC: ietf-imapext@imc.org Subject: Re: ACL2 negative rights References: <1061683801.19012.190.camel@hurina> In-Reply-To: <1061683801.19012.190.camel@hurina> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: >Is there a reason why user identifier is the one that's set negative, >rather than the rights themselves? Are duplicate identifiers even >allowed? > No, but a "negative rights" identifier is not the same identifier as the "normal one". >ACL SET (mailbox) user=foo lr-i group=bar i > >makes more sense to me than: > >ACL SET (mailbox) user=foo lr -user=foo i group=bar i > Probably, but to backward compatibility I would just leave this as is. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OG2wqt043196 for ; Sun, 24 Aug 2003 09:02:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7OG2w7q043195 for ietf-imapext-bks; Sun, 24 Aug 2003 09:02:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OG2uqt043176 for ; Sun, 24 Aug 2003 09:02:57 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7OG2dCK006574; Sun, 24 Aug 2003 09:02:40 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7OG2duj001571; Sun, 24 Aug 2003 09:02:39 -0700 Date: Sun, 24 Aug 2003 09:02:39 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 23 Aug 2003, Timo Sirainen wrote: > > Wouldn't > > chgrp imapgrp > > (where the imap server is in imapgrp) > > chmod 660 > > work? > Yes, assuming you can give IMAP process access to such group. This presumes that the goal is to implement ACL via UNIX security, as opposed to being able to express and manage existing mail store security (including UNIX file/directory protections as an example) with ACL. These two are completely different goals. The former goal, although technically possible, creates the worst of both worlds: 1) If the server is not the owner of the file, it is technically limited by what UNIX can do with group access rights 2) Sharing via group access from the shell end is not possible, since a file can only be in one group 3) The server has access to all mail; there is no intrinsic firewall created by being logged in as a user. A single buffer overflow bug gives a hacker access to all mail in the system (the Cyrus server has had this security bug; as have numerous UNIX mail programs that use setgid mail). 4) Most security has to be done in software in the IMAP server, thus creating two independent points (kernel and IMAP server) in which security is imposed. At least for me, the former goal is pointless. It may be of interest to other individuals, although I question its architectual soundness from a security perspective. My goal is the latter goal. First and foremost, there is no impact on existing shell users; IMAP is just another MUA in a heterogenuous world. The existing security web is maintained for shell users and IMAP users; a false pointer reference in an IMAP server won't give access to anything that a malicious user-written program run at the shell will have. I am perfectly capable of implementing RFC 2086 in an IMAP server which owns all the mail data. Some people seem to think that such IMAP servers are (or should be) the only type of IMAP servers. They aren't the only type of IMAP server. Some IMAP servers export existing mail stores which have their own rules. A good IMAP ACL specification exports the existing ACLs of those mail stores. RFC 2086 was an attempt at a good IMAP ACL specification, but it had certain design faults which -- in spite of the best efforts of its author -- caused it to fall short of that goal. It would be a shame if ACL2 fails to do a better job. It would be an even worse shame if ACL2 fails to do so out of a conscious decision not to do a better job. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OFZ0qt040768 for ; Sun, 24 Aug 2003 08:35:00 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7OFZ0Cd040767 for ietf-imapext-bks; Sun, 24 Aug 2003 08:35:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OFYxqt040751 for ; Sun, 24 Aug 2003 08:34:59 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7OFYmgG011737; Sun, 24 Aug 2003 08:34:53 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7OFYmZX001058; Sun, 24 Aug 2003 08:34:48 -0700 Date: Sun, 24 Aug 2003 08:34:48 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030823232646.04d4be70@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030823010843.055d99b8@lmail.pscs.co.uk> <5.2.1.1.2.20030823232646.04d4be70@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 23 Aug 2003, Paul Smith wrote: > I think the problem has changed from 'RFC 2086 is not implementable on > Unix' (which was the original statement) to 'yes, it's implementable, but > we don't want to because a few people (including the IMAP server > developers) like some features that we might lose if we do it that way'. You have made a completely false statement. Just because you can create a strawman mockery of another individual's position does not make that strawman true. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O0A1qt064992 for ; Sat, 23 Aug 2003 17:10:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7O0A15L064991 for ietf-imapext-bks; Sat, 23 Aug 2003 17:10:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O09xqt064983 for ; Sat, 23 Aug 2003 17:09:59 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 89F425C65485 for ; Sun, 24 Aug 2003 03:10:01 +0300 (EEST) Subject: ACL2 negative rights From: Timo Sirainen To: ietf-imapext@imc.org Content-Type: text/plain Message-Id: <1061683801.19012.190.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 24 Aug 2003 03:10:01 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there a reason why user identifier is the one that's set negative, rather than the rights themselves? Are duplicate identifiers even allowed? ACL SET (mailbox) user=foo lr-i group=bar i makes more sense to me than: ACL SET (mailbox) user=foo lr -user=foo i group=bar i Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O02Kqt064901 for ; Sat, 23 Aug 2003 17:02:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7O02KnM064900 for ietf-imapext-bks; Sat, 23 Aug 2003 17:02:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O02Iqt064894 for ; Sat, 23 Aug 2003 17:02:18 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 6E4715C65485; Sun, 24 Aug 2003 03:02:20 +0300 (EEST) Subject: Re: Maildir ACLs From: Timo Sirainen To: Cyrus Daboo Cc: ietf-imapext@imc.org In-Reply-To: <2147483647.1061667794@[10.0.1.10]> References: <890A53B4-D5C0-11D7-B6EB-000393CC2E90@iki.fi> <2147483647.1061667794@[10.0.1.10]> Content-Type: text/plain Message-Id: <1061683340.19011.181.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 24 Aug 2003 03:02:20 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 2003-08-24 at 02:43, Cyrus Daboo wrote: > | Courier-like shared maildirs use sticky bit in the mail directory, so > | mails are owned by the user who stored it there. That means each user has > | expunge and write access to their own mails, but not for others. > > I don't think this is an issue because its not about whether expunge will > actually do anything but rather whether the EXPUNGE command is even allowed > for a user. Thus if user A can write messages into a maildir mailbox, but > currently there are only deleted messages for user B there, EXPUNGE is > still valid for user A - of course it just does nothing. If user A did not > have the 'x' ACL, then EXPUNGE would have returned NO. The problem is that it still looks like you can give write access to the mailbox, but it actually doesn't work at least the way ACL spec says it would. You might as well say that you have write access to all mailboxes, it's just that STORE and EXPUNGE do nothing in them. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNoDqt064650 for ; Sat, 23 Aug 2003 16:50:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NNoDxT064649 for ietf-imapext-bks; Sat, 23 Aug 2003 16:50:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNoBqt064644 for ; Sat, 23 Aug 2003 16:50:12 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 95C0B5C65485; Sun, 24 Aug 2003 02:50:13 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: Cyrus Daboo Cc: Paul Smith , ietf-imapext@imc.org In-Reply-To: <2147483647.1061667346@[10.0.1.10]> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs. co.uk> <2147483647.1061667346@[10.0.1.10]> Content-Type: text/plain Message-Id: <1061682613.19009.170.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 24 Aug 2003 02:50:13 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 2003-08-24 at 02:35, Cyrus Daboo wrote: > However it would be nice (not ACL2 but something after perhaps) > if it were possible to construct a LIST command that only returned those > with the matching ACL, e.g.: > > a LIST (ACL=user=fred) "" "INBOX.*" I think this is very much related to ANNOTATEMORE. Add searching support for it and export ACLs as annotations. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNhJqt064545 for ; Sat, 23 Aug 2003 16:43:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NNhJrI064544 for ietf-imapext-bks; Sat, 23 Aug 2003 16:43:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNhIqt064539 for ; Sat, 23 Aug 2003 16:43:18 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.10] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id TAA01926; Sat, 23 Aug 2003 19:39:22 -0400 (EDT) Date: Sat, 23 Aug 2003 19:43:14 -0400 From: Cyrus Daboo To: Timo Sirainen , ietf-imapext@imc.org Subject: Re: Maildir ACLs Message-ID: <2147483647.1061667794@[10.0.1.10]> In-Reply-To: <890A53B4-D5C0-11D7-B6EB-000393CC2E90@iki.fi> References: <890A53B4-D5C0-11D7-B6EB-000393CC2E90@iki.fi> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Timo, --On Sunday, August 24, 2003 2:21 +0300 Timo Sirainen wrote: | Courier-like shared maildirs use sticky bit in the mail directory, so | mails are owned by the user who stored it there. That means each user has | expunge and write access to their own mails, but not for others. | | ACL2 doesn't really support that. Should it? Or how would I describe ACLs | for such mailboxes? Maybe add a new sticky rights attribute? I don't think this is an issue because its not about whether expunge will actually do anything but rather whether the EXPUNGE command is even allowed for a user. Thus if user A can write messages into a maildir mailbox, but currently there are only deleted messages for user B there, EXPUNGE is still valid for user A - of course it just does nothing. If user A did not have the 'x' ACL, then EXPUNGE would have returned NO. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNZtqt064407 for ; Sat, 23 Aug 2003 16:35:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NNZtHT064406 for ietf-imapext-bks; Sat, 23 Aug 2003 16:35:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNZsqt064401 for ; Sat, 23 Aug 2003 16:35:54 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.10] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id TAA01796; Sat, 23 Aug 2003 19:31:54 -0400 (EDT) Date: Sat, 23 Aug 2003 19:35:46 -0400 From: Cyrus Daboo To: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061667346@[10.0.1.10]> In-Reply-To: <5.2.1.1.2.20030823233048.05cb65e0@lmail.pscs.co.uk> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs. co.uk> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Paul, --On Saturday, August 23, 2003 23:35 +0100 Paul Smith wrote: | | In most cases, isn't the client just going to use the 'LIST (ACL)' | command when a user wants to edit the ACL for a group - so the user | presses 'Edit ACL', the client sends LIST (ACL) to the server for that | group, gets back the response and displays the relevant data for editing. | | In this case, is an extra 20 bytes going to make that much difference? | It'll be a relatively rare event. | | If you're going to set the ACL for an entire hierarchy at once, why not | just say that you only return the rights model if it's different from the | previous one returned, so the first mailbox always returns the model, and | subsequent ones only return it if it's different from the first one. This | would cut down on the extra round trip, would (ISTM) be simpler from the | client point of view, and not must harder from the server POV. One operation that is useful is 'tell me which of my mailboxes is being shared to user=fred'. Currently (ACL) the only way to do that is a GETACL command for every mailbox in the personal hierarchy - ughh! With ACL2 a single LIST will do the trick. However it would be nice (not ACL2 but something after perhaps) if it were possible to construct a LIST command that only returned those with the matching ACL, e.g.: a LIST (ACL=user=fred) "" "INBOX.*" * LIST "." INBOX.public (("ACL" "model1" ("user=fred" "rwipslextda"))) * LIST "." INBOX.public.fred (("ACL" "model1" ("user=fred" "rwipslextda"))) a OK -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNM2qt064123 for ; Sat, 23 Aug 2003 16:22:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NNM1M8064122 for ietf-imapext-bks; Sat, 23 Aug 2003 16:22:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNLxqt064114 for ; Sat, 23 Aug 2003 16:22:00 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 08B022387F; Sun, 24 Aug 2003 02:21:54 +0300 (EEST) Received: from iki.fi (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 3E067238C9 for ; Sun, 24 Aug 2003 02:21:21 +0300 (EEST) Date: Sun, 24 Aug 2003 02:21:34 +0300 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Maildir ACLs From: Timo Sirainen To: ietf-imapext@imc.org Content-Transfer-Encoding: 7bit Message-Id: <890A53B4-D5C0-11D7-B6EB-000393CC2E90@iki.fi> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_01,USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Courier-like shared maildirs use sticky bit in the mail directory, so mails are owned by the user who stored it there. That means each user has expunge and write access to their own mails, but not for others. ACL2 doesn't really support that. Should it? Or how would I describe ACLs for such mailboxes? Maybe add a new sticky rights attribute? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMfmqt063332 for ; Sat, 23 Aug 2003 15:41:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NMfm23063331 for ietf-imapext-bks; Sat, 23 Aug 2003 15:41:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMfkqt063326 for ; Sat, 23 Aug 2003 15:41:47 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id E5765238565 for ; Sat, 23 Aug 2003 23:40:09 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 23:36:48 +0100 Message-Id: <5.2.1.1.2.20030823232646.04d4be70@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 23:28:49 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030823010843.055d99b8@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 21:30 23/08/2003 +0300, Timo Sirainen wrote: >On Saturday, Aug 23, 2003, at 03:15 Europe/Helsinki, Paul Smith wrote: > >>Wouldn't >>chgrp imapgrp >>(where the imap server is in imapgrp) >>chmod 660 >> >>work? > >Yes, assuming you can give IMAP process access to such group. I think >setgroups() is portable enough. setgid() might be enough too. >Summary: > - Client wouldn't have to think about server restrictions > - Solves about all the current protocol issues > - RFC 2086 is actually implementable with it.. > - Doesn't force users to change existing ways > - I believe it solves the needs for 99% of users > - Perhaps it's not implementable in some rare platforms that don't > provide setgroups()-like functionality. > >Too bad Mark will just shoot this down :) Yep :-( I think the problem has changed from 'RFC 2086 is not implementable on Unix' (which was the original statement) to 'yes, it's implementable, but we don't want to because a few people (including the IMAP server developers) like some features that we might lose if we do it that way'. This is a valid statement, but whether it warrants the extra complexity for everyone else is debatable. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMfFqt063316 for ; Sat, 23 Aug 2003 15:41:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NMfFdJ063315 for ietf-imapext-bks; Sat, 23 Aug 2003 15:41:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMfDqt063309 for ; Sat, 23 Aug 2003 15:41:14 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id D82A2238F5E for ; Sat, 23 Aug 2003 23:40:10 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 23:36:45 +0100 Message-Id: <5.2.1.1.2.20030823230108.04909370@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 23:24:39 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061636769@[192.168.42.6]> References: <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:06 23/08/2003 -0600, Lyndon Nerenberg wrote: >On Saturday, August 23, 2003 12:25 AM +0100 Paul Smith >wrote: > >>>There are also significant security implications to providing a >>>complete list of users. >> >>In some cases, yes, in other cases, there are big usability >>implications in not providing the list.. > >The security implications are by far the most important consideration >here. The most valuable tool for performing a dictionary attack is a list >of authentication identifiers. Any protocol that serves up such a list on >demand doesn't stand a chance of getting past the IESG. Hmm, so LDAP won't get through either... In the vast majority of email systems, the 'authentication identifier' is also the 'user' part of the email address (or in some cases the subdomain part), so the results of an LDAP search will pretty much give you a list of authentication identifiers. >This is *very* basic security design engineering practice. If you don't >understand why what you're proposing is harmful, you really need to spend >some time reading about security design. I understand why it COULD be harmful. I also understand why, in many cases, it wouldn't be harmful at all, but would be a big usability benefit. Eg, in a company of 100 people all of whom are quite happy knowing each others logins (their network OS could well makes the list of users visible in any case), the list will only be available to authenticated users, and will mean that message folder sharing is actually usable within that company rather than being complex to set up. It would obviously have to be an option that mail admins could disable if, for instance, their IMAP server was public rather than private. There is a danger of saying 'security concerns override everything', including usability. In a large number of cases, security concerns are relatively minimal, there should be an optional method of boosting usability in these cases. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMekqt063293 for ; Sat, 23 Aug 2003 15:40:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NMekcA063292 for ietf-imapext-bks; Sat, 23 Aug 2003 15:40:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMeiqt063287 for ; Sat, 23 Aug 2003 15:40:45 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 2C85B238B02 for ; Sat, 23 Aug 2003 23:40:10 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 23:37:25 +0100 Message-Id: <5.2.1.1.2.20030823233048.05cb65e0@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 23:35:54 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061640316@[10.0.1.10]> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs. co.uk> List-ID: List-Unsubscribe: At 12:05 23/08/2003 -0400, Cyrus Daboo wrote: >I am also concerned that the proposed LIST response is going to result in >a lot of data that's going to be the same in each LIST. >How about a new ACL command to enumerate the set of ACL models that the >server currently supports and to tag those with a unique identifier that >is then used in the list response, e.g.: Is this really worth the added complexity? In most cases, isn't the client just going to use the 'LIST (ACL)' command when a user wants to edit the ACL for a group - so the user presses 'Edit ACL', the client sends LIST (ACL) to the server for that group, gets back the response and displays the relevant data for editing. In this case, is an extra 20 bytes going to make that much difference? It'll be a relatively rare event. If you're going to set the ACL for an entire hierarchy at once, why not just say that you only return the rights model if it's different from the previous one returned, so the first mailbox always returns the model, and subsequent ones only return it if it's different from the first one. This would cut down on the extra round trip, would (ISTM) be simpler from the client point of view, and not must harder from the server POV. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NLQHqt061753 for ; Sat, 23 Aug 2003 14:26:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NLQH6q061752 for ietf-imapext-bks; Sat, 23 Aug 2003 14:26:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NLQGqt061747 for ; Sat, 23 Aug 2003 14:26:16 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.10] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA29582; Sat, 23 Aug 2003 17:22:20 -0400 (EDT) Date: Sat, 23 Aug 2003 17:26:13 -0400 From: Cyrus Daboo To: Lyndon Nerenberg {VE6BBM} cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061659573@[10.0.1.10]> In-Reply-To: <2147483647.1061635436@[192.168.42.6]> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> <2147483647.1061640316@[10.0.1.10]> <2147483647.1061635436@[192.168.42.6]> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Lyndon, --On Saturday, August 23, 2003 10:43 -0600 Lyndon Nerenberg {VE6BBM} wrote: |> How about a new ACL command to enumerate the set of ACL models that the |> server currently supports and to tag those with a unique identifier |> that is then used in the list response, e.g.: | | As long as these are guaranteed to be immutable within a session, this | should be fine for the LIST case. | | I would not want to use these labels to set ACLs, though. I don't think | it's possible to guarantee they won't change over time, and if a badly | designed client decided to cache the label->ACL mapping for re-use in | later sessions, the consequences could be bad. Agreed - the labels MUST NOT be cached between sessions or presented to the user in any way. Another thing we could do is define the labels as a lightweight hash of the remainder of the response. That way they could be guaranteed to be unique and change if the model is tweaked a little by a sysadmin. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NIUHqt057531 for ; Sat, 23 Aug 2003 11:30:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NIUHJr057530 for ietf-imapext-bks; Sat, 23 Aug 2003 11:30:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NIUFqt057525 for ; Sat, 23 Aug 2003 11:30:15 -0700 (PDT) (envelope-from tss@iki.fi) Received: from iki.fi (unknown [192.168.10.209]) by oma.irssi.org (Postfix) with ESMTP id 4EE015C65485; Sat, 23 Aug 2003 21:30:10 +0300 (EEST) Date: Sat, 23 Aug 2003 21:30:23 +0300 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-imapext@imc.org To: Paul Smith From: Timo Sirainen In-Reply-To: <5.2.1.1.2.20030823010843.055d99b8@lmail.pscs.co.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Saturday, Aug 23, 2003, at 03:15 Europe/Helsinki, Paul Smith wrote: > Wouldn't > chgrp imapgrp > (where the imap server is in imapgrp) > chmod 660 > > work? Yes, assuming you can give IMAP process access to such group. I think setgroups() is portable enough. setgid() might be enough too. This is actually what I was planning to do from the beginning, although optionally and probably using multiple groups. I wouldn't really mind it if this behaviour was required for ACL. It would really take out most of the complexity. Listing existing ACLs would need to be possible always, but IMHO it's good enough restriction to require all shared mailboxes be in special imapd-group if you want to change their ACLs with IMAP. If it's not enough for you, you're probably in the minority who can just go and use chgrp directly. Nothing would prevent that. Server implementation could be smart as well. As long as the requested rights happen to be what could be expressed exactly with r/w and there's only one group given the access, server can just use that UNIX group instead of the imapd-group. This would work even better with the extended rights vs. basic rights distinction. Server would give the preferred mapping of extended rights to RO, RW, WO basic rights. As long as client used only those, server can use UNIX rights directly. Summary: - Client wouldn't have to think about server restrictions - Solves about all the current protocol issues - RFC 2086 is actually implementable with it.. - Doesn't force users to change existing ways - I believe it solves the needs for 99% of users - Perhaps it's not implementable in some rare platforms that don't provide setgroups()-like functionality. Too bad Mark will just shoot this down :) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NH6Fqt053040 for ; Sat, 23 Aug 2003 10:06:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NH6FRE053039 for ietf-imapext-bks; Sat, 23 Aug 2003 10:06:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NH6Eqt053033 for ; Sat, 23 Aug 2003 10:06:14 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7NH6963032703; Sat, 23 Aug 2003 11:06:15 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Sat, 23 Aug 2003 11:06:09 -0600 From: Lyndon Nerenberg To: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061636769@[192.168.42.6]> In-Reply-To: <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> References: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Saturday, August 23, 2003 12:25 AM +0100 Paul Smith wrote: >> There are also significant security implications to providing a >> complete list of users. > > In some cases, yes, in other cases, there are big usability > implications in not providing the list.. The security implications are by far the most important consideration here. The most valuable tool for performing a dictionary attack is a list of authentication identifiers. Any protocol that serves up such a list on demand doesn't stand a chance of getting past the IESG. This is *very* basic security design engineering practice. If you don't understand why what you're proposing is harmful, you really need to spend some time reading about security design. Steve Bellovin has written countless papers on this topic, and I strongly suggest you search them out and read them. You should also spend some time going through the minutes of the various security-related IETF WGs. There's a lot of history there that describes successful (and more importantly, unsuccessful) implementations of security in various IETF protocols. Cyrus was on the right track when he described the use of friendly identifiers that are decoupled from authentication identifiers. The difficulty with this scheme is designing a friendly identifier from which it is computationally difficult to derive the corresponding authentication identifier. We've been discussing this for years in the various IMAP WGs and discussion forums, but haven't come up with a solution that satisfies both the UI and the security requirements. And the problem is in no way unique to IMAP. Many other WGs have also wrestled with it, and to my knowledge, none of them have managed to solve it. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NGsdqt052731 for ; Sat, 23 Aug 2003 09:54:39 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NGsdts052730 for ietf-imapext-bks; Sat, 23 Aug 2003 09:54:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NGscqt052725 for ; Sat, 23 Aug 2003 09:54:38 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from UNIX45.andrew.cmu.edu (UNIX45.andrew.cmu.edu [128.2.13.175]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7NGsaI3028886; Sat, 23 Aug 2003 12:54:36 -0400 Date: Sat, 23 Aug 2003 12:54:36 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061640316@[10.0.1.10]> Message-ID: References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> <2147483647.1061640316@[10.0.1.10]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 23 Aug 2003, Cyrus Daboo wrote: > I'm concerned about the prospect of per-mailbox ACL models from the > perspective of the user wanting to manipulate multiple mailboxes at one > time, but realize that is probably going to be a reality for a lot of > implementations. The entire system is pretty complex, which is worrying me, but I don't have a good counter-proposal that will allow clients to predict how a server will behave if we want to live with all the constraints various implementations have while retaining the expressability of RFC2086. I'm also not strictly convinced that we must support more than one ACL model on a given server. We shouldn't close the door to it though. > I am also concerned that the proposed LIST response is going to result in a > lot of data that's going to be the same in each LIST. Yes, the size of list response are also concerning me. > How about a new ACL command to enumerate the set of ACL models that the > server currently supports and to tag those with a unique identifier that is > then used in the list response, e.g.: [snip] > This will greatly cut down on the LIST responses at the expense of one > extra roundtrip to list the models. The NIL for the third model implies no > tied rights. This also avoids the need to have a lengthy ACL2 capability > indicator. I don't think it's a real extra round trip though, you can pipeline the GETMODELS command with the LIST ACL command. > We could also use the models response to define what sensible R & W > synonyms might be: > > * ACLMODEL "model1" "MOST_SPECIFIC" "u g" ("lrs" "witextd" "p" "a") > ("R=lrs" "W=witextd") I would just define the last list to be ("lrs" "witextd") with the R and W being understood. This doesn't confuse the issue with a new set of rights tokens. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NGjIqt052520 for ; Sat, 23 Aug 2003 09:45:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NGjIkL052519 for ietf-imapext-bks; Sat, 23 Aug 2003 09:45:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NGjGqt052513 for ; Sat, 23 Aug 2003 09:45:17 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7NGht63032618; Sat, 23 Aug 2003 10:43:56 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Sat, 23 Aug 2003 10:43:56 -0600 From: Lyndon Nerenberg {VE6BBM} To: Cyrus Daboo cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061635436@[192.168.42.6]> In-Reply-To: <2147483647.1061640316@[10.0.1.10]> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> <2147483647.1061640316@[10.0.1.10]> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > How about a new ACL command to enumerate the set of ACL models that the > server currently supports and to tag those with a unique identifier > that is then used in the list response, e.g.: As long as these are guaranteed to be immutable within a session, this should be fine for the LIST case. I would not want to use these labels to set ACLs, though. I don't think it's possible to guarantee they won't change over time, and if a badly designed client decided to cache the label->ACL mapping for re-use in later sessions, the consequences could be bad. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NG5Nqt049195 for ; Sat, 23 Aug 2003 09:05:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NG5NCX049194 for ietf-imapext-bks; Sat, 23 Aug 2003 09:05:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NG5Lqt049184 for ; Sat, 23 Aug 2003 09:05:22 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.10] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA24246; Sat, 23 Aug 2003 12:01:23 -0400 (EDT) Date: Sat, 23 Aug 2003 12:05:16 -0400 From: Cyrus Daboo To: Rob Siemborski , Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061640316@[10.0.1.10]> In-Reply-To: References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Saturday, August 23, 2003 3:06 -0400 Rob Siemborski wrote: | I'd like to hear from a client author about this sort of proposal. I'm concerned about the prospect of per-mailbox ACL models from the perspective of the user wanting to manipulate multiple mailboxes at one time, but realize that is probably going to be a reality for a lot of implementations. I am also concerned that the proposed LIST response is going to result in a lot of data that's going to be the same in each LIST. How about a new ACL command to enumerate the set of ACL models that the server currently supports and to tag those with a unique identifier that is then used in the list response, e.g.: a ACL GETMODELS * ACLMODEL "model1" "MOST_SPECIFIC" "u g" ("lrs" "witextd" "p" "a") * ACLMODEL "model2" "UNION" "*u *g" ("lr" "switextd" "p" "a") * ACLMODEL "model3" "UNION" "*u *g" NIL a OK a LIST (ACL) "" * * LIST () "/" INBOX (("ACL" "model1") ("user=Fred" "rwipslextda"))) * LIST () "." #news.imap (("ACL" "model2") ("user=Fred" "rwipslextda"))) a OK This will greatly cut down on the LIST responses at the expense of one extra roundtrip to list the models. The NIL for the third model implies no tied rights. This also avoids the need to have a lengthy ACL2 capability indicator. We could also use the models response to define what sensible R & W synonyms might be: * ACLMODEL "model1" "MOST_SPECIFIC" "u g" ("lrs" "witextd" "p" "a") ("R=lrs" "W=witextd") This then allows the client to use a basic rights mode by mapping the set of extended rights to R and W. If R and W does not make sense with a particular combination of tied rights then the response could just have ("R=" "W=") or NIL to indicate that. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N8Llqt002962 for ; Sat, 23 Aug 2003 01:21:47 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N8LlV4002961 for ietf-imapext-bks; Sat, 23 Aug 2003 01:21:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N8Ljqt002956 for ; Sat, 23 Aug 2003 01:21:45 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id C8E4F2428D1 for ; Sat, 23 Aug 2003 09:20:44 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 09:15:32 +0100 Message-Id: <5.2.1.1.2.20030823090705.01f5f478@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 09:09:54 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:06 23/08/2003 -0400, Rob Siemborski wrote: > > * LIST () "/" INBOX (("ACL" "UNIX" "UNION" ("lr" "switextd" "p" "a") ("g*" > > "u") ("user=Fred" "rwipslextda"))) > > > > The bits following "ACL" are: > > - 'friendly name' for the rights scheme (in case the client wants to treat > > it specially), not sure about this, but I can't see any harm in it if > > they're registered > >I'd argue to get rid of this. Creating another registry is the last thing >we need, and such a name is really just clutter in the protocol. This >might encourage clients to glean something about the acl based on the >name, when really all the necessary information should be in the rest of >the response. No disagreement here.. If the client assumes that 'UNIX' means the rights are tied in a certain way, it could just check to see if the rights are tied that way and show a different UI if it wants - it wouldn't matter if it WAS Unix or not. > > - access calculation rule > > - rights groupings > >Your example severely penalizes the response given by a server that doesn't >tie rights. Such a server would have to respond: > >("l" "r" "s" "w" "i" "t" "e" "x" "t" "d" "p" "a" "0" "1" "2" "3" "4" "5" >"6" "7" "8" "9") > >for *every* mailbox in the LIST ACL response (remember, we need to >account for numeric rights as well). This is a huge waste of >bandwidth. > >Instead, I propose that rights that are not tied to other rights may be >omitted from the response, e.g.: > > > * LIST () "/" INBOX (("ACL" "UNION" () ("g*" "u*" "o" "a") > ("user=Fred" "rwipslextda"))) Slight proposed change to that - how about the server gives a 'tied rights' response in the ACL2= capability string, and then only reports tied rights in the LIST if it differs from the 'global' list? That would save bandwidth for tied rights servers as well. > > - EBNF style coding for groups/users etc (g? (0 or 1), g (1 exactly) g* (0 > > or more) g+ (1 or more)). Hmm, maybe it should be modified to be able to > > set a maximum number > 0 (eg 'g8' for maximum of 8 groups). You could be > > generic g0:1 g0 g1 g1:* g0:* g3:97 etc (who knows - if we're going to be > > flexible, why not be REALLY generic...) > >I think I'd prefer this to be a single string rather than a list of >strings, since nothing real is gained from the list. OK >I'd also caution being too generic, since we want to keep the ACL model as >simple as possible while preserving implementability (see also: webdav >ACLs). Having the ability for 0, 1, "0 or more", and "atleast 1" is >probably good enough. OK Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N80Oqt099646 for ; Sat, 23 Aug 2003 01:00:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N80Oie099645 for ietf-imapext-bks; Sat, 23 Aug 2003 01:00:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N80Mqt099634 for ; Sat, 23 Aug 2003 01:00:23 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id E3FD924320B for ; Sat, 23 Aug 2003 09:00:15 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 08:58:54 +0100 Message-Id: <5.2.1.1.2.20030823010843.055d99b8@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 01:15:42 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030822232937.0551e300@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <5.2.1.1.2.20030822232937.0551e300@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 16:31 22/08/2003 -0700, you wrote: > > You could look at it the other way, and say that doing it that way means > > that a bug in your server could ONLY affect the mailboxes, rather than all > > the files on the computer.. > >No. You are presuming that there is a userid which is not root but which >has access to all mail data. The only way to do that on UNIX is to make >that userid be the owner of all mail data (which is what Cyrus does); but >that precludes the shell user being the owner of his mail data. Wouldn't chgrp imapgrp (where the imap server is in imapgrp) chmod 660 work? Yes, this would stop arbitrary sharing of mailbox data, if that's an issue, which you say it is, but which surprises me. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N7X3qt092133 for ; Sat, 23 Aug 2003 00:33:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N7X1mI092121 for ietf-imapext-bks; Sat, 23 Aug 2003 00:33:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N7Wxqt092106 for ; Sat, 23 Aug 2003 00:32:59 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX1.andrew.cmu.edu (MX1.andrew.cmu.edu [128.2.10.111]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7N7WaI3028067; Sat, 23 Aug 2003 03:32:36 -0400 Date: Sat, 23 Aug 2003 03:32:36 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Mark Crispin wrote: > > We have this problem today with RFC2086 with > > knowing when to report the READ-ONLY response code to SELECT. > > IMHO, the READ-ONLY response code to SELECT means that that PERMANENTFLAGS > are per-user instead of global and EXPUNGE does nothing; that is, there is > no change that the client can make that will affect another user's SELECT > of the same mailbox. Its too bad RFC2086 says nothing about this (it definitely should be clarified in ACL2). RFC3501 does say: Read-only access through SELECT differs from the EXAMINE command in that certain read-only mailboxes MAY permit the change of permanent state on a per-user (as opposed to global) basis. Last I checked, messages and ACLs were part of the global state of the mailbox. And a user can have 'i' but not 'w'. I'm not going to argue that one interpretation is more correct than the other (I can see reading it both ways), but the semantics for READ-ONLY in the context of an ACL-aware server should be clarified in ACL2 (regardless of the existence of 'basic' ACLs). > > It needs to be > > clear exactly what 'R' and 'W' do. > > Without being able to state this on a per-mailbox basis, there is no > single definition. > > If we say that "W makes changes that another user can see", then that is > actually a separate status from other ACL bits and is useful to include. I have trouble accepting server-defined behavior for ACLs where the client can't tell in advance what is going to happen. For this reason, if 'basic rights' cannot have well-defined semantics, I don't think that they are safe to use. And if they can have well-defined semantics (a possibility that I now can understand as not being the case), then we might as well just use extended rights. > Well, why not just simplify tied rights so that a server can tie as it > pleases, and reports the results. That is, instead of refusing to give a > right until all tied rights are set, just give the additional rights for > free, and require that all tied rights be revoked in order to revoke any. > This is assuming that granting is more common than revoking, and that the > revoke situation implies knowledge of the current rights (and thus how > they are tied). Isn't this worse than the current ACL2, which will refuse to set any tied rights unless all are set at once? I definitely don't think a server should be setting rights behind the client's back. > I agree with Cyrus; most end users are concerned with things at the R > and W level. The "reasonable UI" is already going to reduce to R and W. I'd expect the "reasonable UI" to boil down to a set of checkboxes (or whatever) for groups of tied rights. Describing these tied rights is much harder if the server is free to tie them arbitrarily of course. I suspect an implementation suggestion along the lines of "If a server must tie the rights on a given mailbox, it SHOULD use one of the following groupings..." This might give the clients a chance to take a guess at what group corresponds to 'read' and which one corresponds to 'write'. Having verbatim 'R' and 'W' rights that might not do what the client is expecting (in the extended syntax) worries me though. There should only be one possible interpretation of any given ACL. > > At the minimum, anyone who uses > > shared folders in any serious way realizes that you *do* want to have > > at least separate control over manipulation of the data in the folder, and > > manipulation of the hierarchy underneath the folder (accepting, of course, > > that some mail stores do not allow folders with both contents and > > subordinates). > > I already covered that possibility. R and W for foo means manipulate the > data in the mailbox, where R and W for foo/ (or foo.) means manipulate the > hierarchy underneath. This seems pretty hackish to me, especially for servers that don't currently use this sort of syntax for folder manipulation anywhere else. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N762qt088423 for ; Sat, 23 Aug 2003 00:06:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N76255088422 for ietf-imapext-bks; Sat, 23 Aug 2003 00:06:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N760qt088416 for ; Sat, 23 Aug 2003 00:06:00 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX1.andrew.cmu.edu (MX1.andrew.cmu.edu [128.2.10.111]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7N760I3028026; Sat, 23 Aug 2003 03:06:00 -0400 Date: Sat, 23 Aug 2003 03:06:00 -0400 (EDT) From: Rob Siemborski To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> Message-ID: References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 23 Aug 2003, Paul Smith wrote: > Having both client and server tied rights will cause all sorts of problems. > They can either be at one end or the other, not really both. I don't believe you can legitimately tie rights at the client in any case. The important thing is that the client needs to know how the server functions, preferably before issuing any set-acl type commands. One possibility for this is to force tied rights to always be a certain way. Though, as Mark points out this has drawbacks. One could take something like your proposal and apply it to the capability string (e.g. ACL2=MOST-SPECIFIC=U_G_O=[rl][switextd][p][a]), which is pretty hairy looking but has all the necessary information. Another (as you propose) allows per-mailbox semantics, but requires that the client issue a LIST ACL before knowing what can be done to any mailbox. I'm not sure this is a big loss, since any client who is designing a decent UI will want to know the current contents of the ACL before presenting it anyway. Some comments on your proposal: > * LIST () "/" INBOX (("ACL" "UNIX" "UNION" ("lr" "switextd" "p" "a") ("g*" > "u") ("user=Fred" "rwipslextda"))) > > The bits following "ACL" are: > - 'friendly name' for the rights scheme (in case the client wants to treat > it specially), not sure about this, but I can't see any harm in it if > they're registered I'd argue to get rid of this. Creating another registry is the last thing we need, and such a name is really just clutter in the protocol. This might encourage clients to glean something about the acl based on the name, when really all the necessary information should be in the rest of the response. > - access calculation rule > - rights groupings Your example severely penalizes the response given by a server that doesn't tie rights. Such a server would have to respond: ("l" "r" "s" "w" "i" "t" "e" "x" "t" "d" "p" "a" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9") for *every* mailbox in the LIST ACL response (remember, we need to account for numeric rights as well). This is a huge waste of bandwidth. Instead, I propose that rights that are not tied to other rights may be omitted from the response, e.g.: > * LIST () "/" INBOX (("ACL" "UNION" () ("g*" "u*" "o" "a") ("user=Fred" "rwipslextda"))) > - EBNF style coding for groups/users etc (g? (0 or 1), g (1 exactly) g* (0 > or more) g+ (1 or more)). Hmm, maybe it should be modified to be able to > set a maximum number > 0 (eg 'g8' for maximum of 8 groups). You could be > generic g0:1 g0 g1 g1:* g0:* g3:97 etc (who knows - if we're going to be > flexible, why not be REALLY generic...) I think I'd prefer this to be a single string rather than a list of strings, since nothing real is gained from the list. I'd also caution being too generic, since we want to keep the ACL model as simple as possible while preserving implementability (see also: webdav ACLs). Having the ability for 0, 1, "0 or more", and "atleast 1" is probably good enough. I'd like to hear from a client author about this sort of proposal. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N1Shqt065512 for ; Fri, 22 Aug 2003 18:28:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N1ShiR065511 for ietf-imapext-bks; Fri, 22 Aug 2003 18:28:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N1Seqt065503 for ; Fri, 22 Aug 2003 18:28:42 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7N1S4oa027844; Fri, 22 Aug 2003 18:28:04 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7N1S4Vv021490; Fri, 22 Aug 2003 18:28:04 -0700 Date: Fri, 22 Aug 2003 18:28:04 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: Rob Siemborski , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061587367@[10.0.1.10]> Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> <2147483647.1061587367@[10.0.1.10]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Cyrus Daboo wrote: > | I already covered that possibility. R and W for foo means manipulate the > | data in the mailbox, where R and W for foo/ (or foo.) means manipulate the > | hierarchy underneath. > What if you have a dual-role mailbox - one with messages and a hierarchy > underneath? You might want to allow access to the top-level item's messages > but not allow access to the sub-hierarchy. Clearly the extended rights > model is needed for that. The dual-role mailbox possibility is precisely why you have to say "foo" vs. "foo/" (or "foo" vs. "foo."). In a single-role mailbox, the server can infer; but I think that it's probably best not to have server inference and return an error for an inappropriate operation. So, extended rights aren't needed for that. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N1Maqt065316 for ; Fri, 22 Aug 2003 18:22:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N1Mah1065315 for ietf-imapext-bks; Fri, 22 Aug 2003 18:22:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N1MYqt065310 for ; Fri, 22 Aug 2003 18:22:35 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.10] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id VAA09015; Fri, 22 Aug 2003 21:18:38 -0400 (EDT) Date: Fri, 22 Aug 2003 21:22:47 -0400 From: Cyrus Daboo To: Mark Crispin , Rob Siemborski cc: Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061587367@[10.0.1.10]> In-Reply-To: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Friday, August 22, 2003 5:46 PM -0700 Mark Crispin wrote: | I already covered that possibility. R and W for foo means manipulate the | data in the mailbox, where R and W for foo/ (or foo.) means manipulate the | hierarchy underneath. What if you have a dual-role mailbox - one with messages and a hierarchy underneath? You might want to allow access to the top-level item's messages but not allow access to the sub-hierarchy. Clearly the extended rights model is needed for that. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0wQqt064732 for ; Fri, 22 Aug 2003 17:58:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N0wQ3J064731 for ietf-imapext-bks; Fri, 22 Aug 2003 17:58:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0wPqt064726 for ; Fri, 22 Aug 2003 17:58:25 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.2b2) for ; Fri, 22 Aug 2003 19:58:27 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.0a29] Date: Fri, 22 Aug 2003 19:58:26 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: Point of order Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, let's please keep this discussion to what (if anything) *needs* to change in the current ACL2 spec. Technical discussion of that only. Whether a particular implementation or OS is holy or evil incarnate is not a necessary discussion. Thank you. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0lVqt064493 for ; Fri, 22 Aug 2003 17:47:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N0lVMB064492 for ietf-imapext-bks; Fri, 22 Aug 2003 17:47:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0lRqt064487 for ; Fri, 22 Aug 2003 17:47:27 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7N0koin003696; Fri, 22 Aug 2003 17:46:50 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7N0knFY020293; Fri, 22 Aug 2003 17:46:49 -0700 Date: Fri, 22 Aug 2003 17:46:49 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Rob Siemborski wrote: > > I'm not sure that I understand you. How does -T help you, as opposed to > > just seeing rights being tied? > Currently ACL2 allows rights to be tied in arbitrary ways. This results > in difficulty in presenting a UI and manipulating ACLs. Having only one > way of connecting rights removes this complexity. But what if the rights are in fact tied in arbitary ways, with no way to tie them any differently? Even if you say SHOULD NOT, this will still happen; having t does not necessarily mean that you have eswi. > We have this problem today with RFC2086 with > knowing when to report the READ-ONLY response code to SELECT. IMHO, the READ-ONLY response code to SELECT means that that PERMANENTFLAGS are per-user instead of global and EXPUNGE does nothing; that is, there is no change that the client can make that will affect another user's SELECT of the same mailbox. Consequently, READ-ONLY is orthogonal to ACL with the possible exception of stating that e is never part of an ACL. > If a user > has lrspa as their ACL, is it a READ-ONLY mailbox? Its totally unclear. If you accept my intepretation, then it remains unclear since the two are orthogonal. > 'R' and 'W' are just another way of expressing READ-ONLY. Not necessarily. I think that I want the dividing line to be "W makes changes that another user can see" (and thus would match READ-ONLY), but I can go along with "W means at a minimum that at least one PERMANENTFLAG is alterable." > It needs to be > clear exactly what 'R' and 'W' do. Without being able to state this on a per-mailbox basis, there is no single definition. If we say that "W makes changes that another user can see", then that is actually a separate status from other ACL bits and is useful to include. > And if you have that, you might as > well just stick to using the extended syntax (even if the client only > represents the basic syntax, and the server can only implement the > basic syntax). Well, why not just simplify tied rights so that a server can tie as it pleases, and reports the results. That is, instead of refusing to give a right until all tied rights are set, just give the additional rights for free, and require that all tied rights be revoked in order to revoke any. This is assuming that granting is more common than revoking, and that the revoke situation implies knowledge of the current rights (and thus how they are tied). > > That's a problem. There's a lot of these cases, many of which are > > situational (that is, it may tie one way in one mailbox and a different > > way in another). "s" is a great example. So is "e". > I know. But having 'R' and 'W' and allowing implementations to just pick > what they mean in the extended syntax (even with guidance from the RFC) > isn't any better. I disagree. The implementation is going to pick and choose what R and W means anyway since it's likely to be contextual. Even so, having R and W is better than having nothing at all. And if something better is needed, then use a server which has the full extended rights. > I didn't mean that. I meant that the behavior of the ACL model can be > predicted by a client trying to manipulate the ACL, and therefore be > able to present a reasonable UI. I agree with Cyrus; most end users are concerned with things at the R and W level. The "reasonable UI" is already going to reduce to R and W. It would be lovely if the client can decide what is R and what is W. But that may not be something that the client can decide. > At the minimum, anyone who uses > shared folders in any serious way realizes that you *do* want to have > at least separate control over manipulation of the data in the folder, and > manipulation of the hierarchy underneath the folder (accepting, of course, > that some mail stores do not allow folders with both contents and > subordinates). I already covered that possibility. R and W for foo means manipulate the data in the mailbox, where R and W for foo/ (or foo.) means manipulate the hierarchy underneath. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0CGqt063608 for ; Fri, 22 Aug 2003 17:12:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N0CG3E063607 for ietf-imapext-bks; Fri, 22 Aug 2003 17:12:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0CEqt063602 for ; Fri, 22 Aug 2003 17:12:15 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX1.andrew.cmu.edu (MX1.andrew.cmu.edu [128.2.10.111]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7N0BtI3027445; Fri, 22 Aug 2003 20:11:55 -0400 Date: Fri, 22 Aug 2003 20:11:54 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Mark Crispin wrote: > On Fri, 22 Aug 2003, Rob Siemborski wrote: > > I think having R and W as separate rights could be unfortunate since it > > duplicates data representation. I'd much rather see the protocol using the > > advanced rights all the time, and using the "-T" in the ACL2 capability to > > indicate that the server forces the tying of rights. > > I'm not sure that I understand you. How does -T help you, as opposed to > just seeing rights being tied? Currently ACL2 allows rights to be tied in arbitrary ways. This results in difficulty in presenting a UI and manipulating ACLs. Having only one way of connecting rights removes this complexity. > > Offhand, it worries me because it means that we either have 2 ACL > > mechanisms 'basic' and 'extended' (bad) or we still need to be reporting > > back the extended rights that aren't set as the client expected (also > > bad). > > The only danger with having a basic mechanism is that it is very likely > that basic will become the de facto standard and nobody will do extended. This isn't the only danger. We have this problem today with RFC2086 with knowing when to report the READ-ONLY response code to SELECT. If a user has lrspa as their ACL, is it a READ-ONLY mailbox? Its totally unclear. 'R' and 'W' are just another way of expressing READ-ONLY. It needs to be clear exactly what 'R' and 'W' do. And if you have that, you might as well just stick to using the extended syntax (even if the client only represents the basic syntax, and the server can only implement the basic syntax). > That wouldn't happen if there was an competing ACL3. Lets please not talk about a third ACL mechanism until we're done with the second. > > I'd much rather say "-T" servers *always* tie "rls" and "wipcxted" (Or > > whatever semantics are agreed on, and I'm not sure how to handle 'a'), > > and have such implementations silently ignore rights [such as s] which > > they cannot accomplish (this would be a SHOULD NOT). > > That's a problem. There's a lot of these cases, many of which are > situational (that is, it may tie one way in one mailbox and a different > way in another). "s" is a great example. So is "e". I know. But having 'R' and 'W' and allowing implementations to just pick what they mean in the extended syntax (even with guidance from the RFC) isn't any better. > > This would give us a single ACL model that can be easily predicted by > > clients. > > I suspect that most clients do NOT depend upon ACL to determine if they > can do something or not. I think that most clients just try to do it. I didn't mean that. I meant that the behavior of the ACL model can be predicted by a client trying to manipulate the ACL, and therefore be able to present a reasonable UI. > I think that ACL is, and will be, used solely as a user control. And, as > Cyrus points out, the existing controls are far more complex than most > users desire, and that most users are happy with a four-way R and W > control. I don't think this is truly the case. At the minimum, anyone who uses shared folders in any serious way realizes that you *do* want to have at least separate control over manipulation of the data in the folder, and manipulation of the hierarchy underneath the folder (accepting, of course, that some mail stores do not allow folders with both contents and subordinates). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Uqt063426 for ; Fri, 22 Aug 2003 17:00:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N00UeY063425 for ietf-imapext-bks; Fri, 22 Aug 2003 17:00:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Sqt063415 for ; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id E00A5238907 for ; Sat, 23 Aug 2003 01:00:29 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 00:52:19 +0100 Message-Id: <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 00:21:25 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061560999@[10.0.1.8]> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 14:03 22/08/2003 -0400, Cyrus Daboo wrote: >| 1). Now to announce that the server supports a single user and/or group >| for a mailbox. > >Either this is part of the UNION/MOST-SPECIFIC profile or we have a >separate (additional) capability to announce the restriction: >ACL2=ONE-USERGROUP. Mark's suggestion (which I just saw) of using an >ABNF-style for the capability to be more flexible would be fine too. I'm not keen on the exact syntax (from an aesthetic point of view :-) ) but the idea is good (I don't like the '_'s - they don't exist anywhere else in IMAP) >| 2). "tied rights" debate and alternatives. > >Leave this as it is. In the basic case clients are not likely to expose >the entire set of rights to the user anyway. We do that now and it >confuses the hell out of anyone who is not a sysadmin. Instead clients >will likely have just a limited set of access options as the default: > >Read-Only (lrs) >Read-Write (lrswi) >Write-Only (li) 'drop-box' >No Access () This is actually the BIG problem I see with tied rights at the server. What if the client implements a set of tied rights, but the server implements an incompatible set of tied rights. Eg, if ACL2 stays at it is, but the server ties 'swite' together, That means that the example client above will not be able to set ANY rights apart from 'no access'... (Note that is just an example based on the example client tied rights above) To have arbitrary tied rights at the server the client needs to be able to give the full range of options available to the user, even if it ties them together in the UI somehow (eg by having several checkboxes tick on or off together) Having both client and server tied rights will cause all sorts of problems. They can either be at one end or the other, not really both. >| 3). Enumerating users/groups on the server > >Out-of-scope for ACL2. Should be addressed by another extension. Agreed (but I'd like to see progress on it, even if I have to get involved..) From a usability point of view, I see it as almost critical for the success of any ACL scheme. >| 4). Per-mailbox (per-hierarchy) access calculation models (as opposed to >| per-server) > >not sure... I think this is important if we're allowing tied rights at all. You could put the capabilities into the LIST command, or have a modified 'LISTRIGHTS' command (or an 'ACL-LIST' or similar) They should be per-mailbox rights, and should basically include tying groups and user/group properties, as well as the 'rule identifier' Per-hierarchy adds unnecessary complexity to the client and limitations to the server. Having the same user/group or tied rights groups limits the server. My suggestion would be: The CAPABILITY should just be 'ACL2' The LIST (ACL) command should return the ACL properties - from the client point of view, it will issue a 'LIST (ACL)' command to find what current settings to show to the user, so why not use the same command to return the properties eg * LIST () "/" INBOX (("ACL" "UNIX" "UNION" ("lr" "switextd" "p" "a") ("g*" "u") ("user=Fred" "rwipslextda"))) The bits following "ACL" are: - 'friendly name' for the rights scheme (in case the client wants to treat it specially), not sure about this, but I can't see any harm in it if they're registered - access calculation rule - rights groupings - EBNF style coding for groups/users etc (g? (0 or 1), g (1 exactly) g* (0 or more) g+ (1 or more)). Hmm, maybe it should be modified to be able to set a maximum number > 0 (eg 'g8' for maximum of 8 groups). You could be generic g0:1 g0 g1 g1:* g0:* g3:97 etc (who knows - if we're going to be flexible, why not be REALLY generic...) - current ACL setting list Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Sqt063417 for ; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N00SHB063414 for ietf-imapext-bks; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Mqt063396 for ; Fri, 22 Aug 2003 17:00:24 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 5AFFD238A91 for ; Sat, 23 Aug 2003 01:00:24 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 00:52:29 +0100 Message-Id: <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 00:25:34 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061550187@[192.168.42.6]> References: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:03 22/08/2003 -0600, you wrote: >On Friday, August 22, 2003 10:15 AM +0100 Paul Smith wrote: > >>The IMAP server is the only thing which KNOWS which users/groups are >>available > >Not necessarily. For example, it's (usually) not possible for an IMAP >server to enumerate all the principals in a Kerberos KDC. OK then, so maybe the IMAP server is the only thing which knows what DOES know :-) >There are also significant security implications to providing a complete >list of users. In some cases, yes, in other cases, there are big usability implications in not providing the list.. I agree it should be separate from ACL2. I also agree it should be optional, but I think it should be looked at. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Sqt063413 for ; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N00SRc063411 for ietf-imapext-bks; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Nqt063398 for ; Fri, 22 Aug 2003 17:00:24 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 81A2A238808 for ; Sat, 23 Aug 2003 01:00:25 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 00:52:08 +0100 Message-Id: <5.2.1.1.2.20030822235601.0678de70@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 23:57:33 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <3F464D58.8030501@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:37 22/08/2003 -0500, Pete Resnick wrote: >On 8/22/03 at 6:05 PM +0100, Alexey Melnikov wrote: > >>I think there is a compelling case for working on generic ACL2 with tied >>rights (or a reasonable alternative), etc > >As I read this thread (the S/N ratio being not terribly helpful), leaving >aside all of the other issues that were already addressed, we had Larry >arguing that we should remove the tied rights stuff from the document, and >that's the only relevant part of this discussion to the WG moving forward. >Does anyone care to summarize the technical/operational argument for doing >so at this point? Do folks want to speak up in favor of such a change? I >am sticking with the presumption of leaving the document as-is unless >there is a consensus to change it. I can see a case for leaving tied rights in there. The case against it is primarily a complexity issue - having it in is more complex from a client point of view. I'd like to see another way of finding out about tied rights than the current RIGHTS-INFO response (which comes too late IMHO). I'd also like to see more info in there - eg the single/multiple user/group issue. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Sqt063416 for ; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N00Scb063412 for ietf-imapext-bks; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Mqt063397 for ; Fri, 22 Aug 2003 17:00:24 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id B2263238B00 for ; Sat, 23 Aug 2003 01:00:24 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 00:52:01 +0100 Message-Id: <5.2.1.1.2.20030822235324.06329188@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 23:55:21 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <3F465277.90603@isode.com> References: <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 18:27 22/08/2003 +0100, Alexey Melnikov wrote: You could have >>ACL "FreeAndEasy" s w i t e l r p c x a g u >>which supports anything or >>ACL "VeryLimited" switecxa lr p u1 >>which has a 'read' and a 'write' mode only and only supports a single >>user and no groups >> >>For the Posix case, even if the client didn't understand that case >>specifically it could tie the 'swite' checkboxes (or whatever) together, >>and could only allow the selection of a single user, and multiple groups >>as the identifier. > >I think I mostly like this. >Also note, that currently RIGHTS-INFO response returns "switecxa lr p" >part of the >ACL "VeryLimited" switecxa lr p u1 Yes, I know (that's why I chose that syntax), but (IMHO) it's too late by then - RIGHTS-INFO only comes when an ACL-STORE command fails. It'd be better (from the client viewpoint) to be able to ask for it without having to come up with a failing ACL-STORE command and then undo it. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNigqt063022 for ; Fri, 22 Aug 2003 16:44:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MNigIp063021 for ietf-imapext-bks; Fri, 22 Aug 2003 16:44:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNieqt063016 for ; Fri, 22 Aug 2003 16:44:40 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNi3in030859; Fri, 22 Aug 2003 16:44:04 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNi35n016626; Fri, 22 Aug 2003 16:44:03 -0700 Date: Fri, 22 Aug 2003 16:44:03 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Rob Siemborski wrote: > I think having R and W as separate rights could be unfortunate since it > duplicates data representation. I'd much rather see the protocol using the > advanced rights all the time, and using the "-T" in the ACL2 capability to > indicate that the server forces the tying of rights. I'm not sure that I understand you. How does -T help you, as opposed to just seeing rights being tied? > Offhand, it worries me because it means that we either have 2 ACL > mechanisms 'basic' and 'extended' (bad) or we still need to be reporting > back the extended rights that aren't set as the client expected (also > bad). The only danger with having a basic mechanism is that it is very likely that basic will become the de facto standard and nobody will do extended. This prospect does not frighten me in the least. I suspect that it frightens you. The only answer/consolation that I can offer is that if we solve the problem in ACL2, extended capabilities will still be there. That wouldn't happen if there was an competing ACL3. > I'd much rather say "-T" servers *always* tie "rls" and "wipcxted" (Or > whatever semantics are agreed on, and I'm not sure how to handle 'a'), > and have such implementations silently ignore rights [such as s] which > they cannot accomplish (this would be a SHOULD NOT). That's a problem. There's a lot of these cases, many of which are situational (that is, it may tie one way in one mailbox and a different way in another). "s" is a great example. So is "e". > This would give us a single ACL model that can be easily predicted by > clients. I suspect that most clients do NOT depend upon ACL to determine if they can do something or not. I think that most clients just try to do it. I think that ACL is, and will be, used solely as a user control. And, as Cyrus points out, the existing controls are far more complex than most users desire, and that most users are happy with a four-way R and W control. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNVFqt062798 for ; Fri, 22 Aug 2003 16:31:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MNVFD1062797 for ietf-imapext-bks; Fri, 22 Aug 2003 16:31:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNVEqt062786 for ; Fri, 22 Aug 2003 16:31:14 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNV5in029384; Fri, 22 Aug 2003 16:31:11 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNV5S6015785; Fri, 22 Aug 2003 16:31:05 -0700 Date: Fri, 22 Aug 2003 16:31:05 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822232937.0551e300@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <5.2.1.1.2.20030822232937.0551e300@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > > > Or, Unix developers have to come to terms with having to do something > > > relatively simple such as running the IMAP server in its own account with > > > full access to the mailboxes and implementing their own (straightforward) > > > ACL system on top. > >That's about the worst idea from security point of view. A single bug in > >your server could mean that the attacker got full access to everyone's > >mail. Such a bug has already happened in the Cyrus server. I don't know if the exploit is still secret or not. > You could look at it the other way, and say that doing it that way means > that a bug in your server could ONLY affect the mailboxes, rather than all > the files on the computer.. No. You are presuming that there is a userid which is not root but which has access to all mail data. The only way to do that on UNIX is to make that userid be the owner of all mail data (which is what Cyrus does); but that precludes the shell user being the owner of his mail data. How much do you know about UNIX? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNRUqt062718 for ; Fri, 22 Aug 2003 16:27:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MNRUoW062717 for ietf-imapext-bks; Fri, 22 Aug 2003 16:27:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNRSqt062709 for ; Fri, 22 Aug 2003 16:27:29 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNRKCK018851; Fri, 22 Aug 2003 16:27:25 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNRKi0015613; Fri, 22 Aug 2003 16:27:20 -0700 Date: Fri, 22 Aug 2003 16:27:20 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822172856.03cb4008@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> <5.2.1.1.2.20030822172856.03cb4008@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > > > Do people share the data using non-IMAP methods? > >Yes. Have you ever heard of something called "file sharing"? > With mailbox data? Yes. There is quite a bit of that. > >Oh? So you want the IMAP server to run as root? > No, as 'imapdaemon' or whatever, which has access to the mailbox > directories, but nothing else. There is no way to give user "imapdaemon" special rights over and above some other user or group, other than to make "imapdaemon" be root. What "mailbox directories" are you talking about? Are you still thinking about a black box type world in which mail is stored on a dedicated filesystem or other mechanism separate from the user's home directories? You can't presume that. > I could say 'only because that's what Unix developers give them'. In the > Windows world (and probably many others) people would find it very odd if > they COULD access mailbox files from other programs without causing > problems. Fortunately, UNIX and Windows are two different animals. My UNIX systems are deliciously immune from Sobig.F, other than receiving all the crap that is coming from infected Windows systems. I respectfully suggest that Windows is not making a particularly splendid case for emulation. > However, I think that if you're talking about needing to use the > full Unix command set on things like mailbox files, you're probably talking > about techie usage, rather than the average end-user. Wrong. Even ordinary UNIX users commonly use UNIX tools. UNIX is a different environment from Windows, and I strongly suggest that you read some books about the UNIX environment is used before making such statements. > That's valid, but > should techies restrict the features available to everyone else? Nobody is saying anything at all about *restricting*. Rather, the problem is that RFC 2086 type ACLs, for all their complexity, are too restricted to express UNIX semantics. > I never started off 'whacking' anyone - I was just commenting to messages > seemingly saying that any ACL standard had to bend over backwards to work > with Unix That's a straw man. Nobody has said that. > But, I think the client complexity issue has to be considered. Cyrus Daboo has already stated that for most users, RFC 2086 is much too complex and all that is needed are: read-only, read-write, write-only, and no access. I have no problem with that. I have a problem with the enforced complexity of RFC 2086 that simultaneously (because of its complex rules of inheritance) does not permit the simple setting of "read-only, read-write, write-only, and no access" for the owner, group members, and world. I also have a problem with the way that RFC 2086 overloaded identifiers (e.g. there is no way to distinguish a userid of "anyone" from world access). The current ACL2 document seems to fix these problems. That is a good thing. It would not be a good thing to turn around and create a new problem that was not in RFC 2086. Specifically, tied rights (which are in RFC 2086) can not be removed without a satisfactory substitute. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNBYqt062139 for ; Fri, 22 Aug 2003 16:11:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MNBYNa062138 for ietf-imapext-bks; Fri, 22 Aug 2003 16:11:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNBWqt062133 for ; Fri, 22 Aug 2003 16:11:32 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GEL-FRAME.andrew.cmu.edu (GEL-FRAME.andrew.cmu.edu [128.2.120.180]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7MNBDI3027360; Fri, 22 Aug 2003 19:11:13 -0400 Date: Fri, 22 Aug 2003 19:11:13 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Mark Crispin wrote: > On Fri, 22 Aug 2003, Rob Siemborski wrote: > > How about another suggestion that takes this a step further. Add to > > Mark's ABNF the following (a trailing -T to indicate that the above 4 sets > > of rights are tied together, or alternatively something to indicate that > > all rights may be manipulated separately) > > How about using this as a mechanism for my "basic rights" suggestion, and > leave enough weasel-room via SHOULD to cover up any discrepancies caused > by an implementation that requires tying in a slightly different way. I was about to compose a message suggesting something similar (the two proposals do seem very close to me). I think having R and W as separate rights could be unfortunate since it duplicates data representation. I'd much rather see the protocol using the advanced rights all the time, and using the "-T" in the ACL2 capability to indicate that the server forces the tying of rights. > For example, I don't know if extended right "s" is really part of basic > right "R" or not, but I think that it should be. Someone else may have > reason to disagree. I can envision such circumstances myself. So, we say > SHOULD instead of MUST. This is, of course, the problem with the above solution. Offhand, it worries me because it means that we either have 2 ACL mechanisms 'basic' and 'extended' (bad) or we still need to be reporting back the extended rights that aren't set as the client expected (also bad). I'd much rather say "-T" servers *always* tie "rls" and "wipcxted" (Or whatever semantics are agreed on, and I'm not sure how to handle 'a'), and have such implementations silently ignore rights [such as s] which they cannot accomplish (this would be a SHOULD NOT). If implementations want more control, they should implement a server that doesn't advertise "-T". This would give us a single ACL model that can be easily predicted by clients. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMsKqt061728 for ; Fri, 22 Aug 2003 15:54:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMsKMA061727 for ietf-imapext-bks; Fri, 22 Aug 2003 15:54:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMsJqt061720 for ; Fri, 22 Aug 2003 15:54:19 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MMrfgG019571; Fri, 22 Aug 2003 15:53:41 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MMrfZS014043; Fri, 22 Aug 2003 15:53:41 -0700 Date: Fri, 22 Aug 2003 15:53:41 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Rob Siemborski wrote: > How about another suggestion that takes this a step further. Add to > Mark's ABNF the following (a trailing -T to indicate that the above 4 sets > of rights are tied together, or alternatively something to indicate that > all rights may be manipulated separately) How about using this as a mechanism for my "basic rights" suggestion, and leave enough weasel-room via SHOULD to cover up any discrepancies caused by an implementation that requires tying in a slightly different way. For example, I don't know if extended right "s" is really part of basic right "R" or not, but I think that it should be. Someone else may have reason to disagree. I can envision such circumstances myself. So, we say SHOULD instead of MUST. This also helps with read-only vs. read-write vs. write-only. Although I would normally say that basic right W includes extended rights w and i, perhaps it only includes extended right i if basic right R isn't present. But that's an implementation detail; for the user, a server which has just basic rights only has "read" and "write". We can call it a quality of implementation issue if it makes you happier. If the user really cares one way or another about "s" or "wi" vs "i", then he will demand a server implementation that supports extended rights. If a user just wants to set or clear "read access", a server that only has basic rights will be good enough. For those of you who claim that basic rights aren't good enough, I think that millions of UNIX users the world over who don't have POSIX ACLs (or have but don't use) will disagree. Basic rights may not be good enough for you, but control over basic rights are better than no control at all. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMrMqt061689 for ; Fri, 22 Aug 2003 15:53:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMrM3k061688 for ietf-imapext-bks; Fri, 22 Aug 2003 15:53:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMrKqt061683 for ; Fri, 22 Aug 2003 15:53:20 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 07C122449FF for ; Fri, 22 Aug 2003 23:50:18 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 23:42:05 +0100 Message-Id: <5.2.1.1.2.20030822172856.03cb4008@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 23:27:34 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:56 22/08/2003 -0700, you wrote: >On Fri, 22 Aug 2003, Paul Smith wrote: > > Do people share the data using non-IMAP methods? > >Yes. Have you ever heard of something called "file sharing"? With mailbox data? > > > 1) that all IMAP servers operate on dedicated IMAP-only boxes > > I didn't make that assumption at all. If access restrictions are strong (as > > they are on Unix) then the IMAP Server can run under one account which has > > full access to the mailbox. > >Oh? So you want the IMAP server to run as root? No, as 'imapdaemon' or whatever, which has access to the mailbox directories, but nothing else. > > > 4) that there is no need for non-IMAP type access (e.g. grep, sed, > > > editors) to mail files > > Hmm, I'd see that as a good assumption... I'd see it as bad to allow people > > to be able to edit raw message files... > >Too bad. This is what is there today. It can't be changed. >Basically, nothing shy of the full UNIX command language will do. I could say 'only because that's what Unix developers give them'. In the Windows world (and probably many others) people would find it very odd if they COULD access mailbox files from other programs without causing problems.. I don't want to get into an OS war, because I have no gripe with any OS. However, I think that if you're talking about needing to use the full Unix command set on things like mailbox files, you're probably talking about techie usage, rather than the average end-user. That's valid, but should techies restrict the features available to everyone else? Maybe that's one of the reasons Windows (which probably goes too far the OTHER way) is generally considered more usable. > > I would have less problem with being able to advertise an arbitrarily > > reduced ACL feature-set for those unable/unwilling to implement the full > > feature-set. > >This is exactly what I am talking about. Why then are you whacking me >with a strawman that is not my position? I never started off 'whacking' anyone - I was just commenting to messages seemingly saying that any ACL standard had to bend over backwards to work with Unix - which I disagree with. I said - come up with something that does what is needed (ACL2 seems to meet that criteria) then see if there's ways of tweaking it that will make it work with OSes, but without weakening the original design. But, I think the client complexity issue has to be considered. I've seen comments such as 'it makes things easier for server developers, the 'only thing that client developers have to worry about is to understand every server platform' which are not realistic. (I still think that a Unix IMAP server which was written to get around the filesystem restrictions (even if it imposed other restrictions for a few people - eg no file sharing of raw mailbox directories) would have a very strong USP) Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMqfqt061668 for ; Fri, 22 Aug 2003 15:52:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMqfCg061667 for ietf-imapext-bks; Fri, 22 Aug 2003 15:52:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMqeqt061662 for ; Fri, 22 Aug 2003 15:52:40 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 54783244786 for ; Fri, 22 Aug 2003 23:50:09 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 23:43:41 +0100 Message-Id: <5.2.1.1.2.20030822232937.0551e300@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 23:31:56 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <1061564263.24982.166.camel@hurina> References: <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 17:57 22/08/2003 +0300, you wrote: >On Fri, 2003-08-22 at 11:50, Paul Smith wrote: > > > Or, Unix developers have to come to terms with having to do something > > relatively simple such as running the IMAP server in its own account with > > full access to the mailboxes and implementing their own (straightforward) > > ACL system on top. > >That's about the worst idea from security point of view. A single bug in >your server could mean that the attacker got full access to everyone's >mail. You could look at it the other way, and say that doing it that way means that a bug in your server could ONLY affect the mailboxes, rather than all the files on the computer.. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMdcqt061373 for ; Fri, 22 Aug 2003 15:39:38 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMdcRt061372 for ietf-imapext-bks; Fri, 22 Aug 2003 15:39:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMdbqt061365 for ; Fri, 22 Aug 2003 15:39:37 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MMd5oa012420; Fri, 22 Aug 2003 15:39:05 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MMd5cK013198; Fri, 22 Aug 2003 15:39:05 -0700 Date: Fri, 22 Aug 2003 15:39:05 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> <2147483647.1061558528@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Rob Siemborski wrote: > This is more along the lines of what I was going for when I suggested > ACL2=UNIX (the suggested name, of course, bearing unintended > connotations). Mark's later ABNF example is also okay with me. Are we moving toward concensus here? I think that it would be a terrible mistake to have something that is specific to UNIX. However, anything that tells the client how rights work on the server is good. > Of course, this doesn't solve the complexity issue with tied rights. RFC 2086 had tied rights; it isn't as if this is something new. Strawman solution: I would be happy to see a set of "basic rights" defined in addition to the "advanced rights". Following Cyrus' four-way list: read-only read-write write-only ("drop-box") no access we have just two basic rights: R and W (are rights case-dependent? If not, then other names are needed). Basic rights can also be applied to a level of hierarchy, by appending the hierarchy delimiter to the name ala CREATE. In this case, R means "can list inferiors" and W means "can create inferiors". This is more or less trivial to implement almost anywhere. On systems such as TOPS-20 which support per-mailbox invisible status, I'd have a problem, but I'm willing to swallow that pill. Basic rights are simple. Perhaps too simple, but they get rid of tied rights and let us move forward. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMQiqt060647 for ; Fri, 22 Aug 2003 15:26:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMQifY060646 for ietf-imapext-bks; Fri, 22 Aug 2003 15:26:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMQgqt060641 for ; Fri, 22 Aug 2003 15:26:42 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7MMQLI3027289; Fri, 22 Aug 2003 18:26:21 -0400 Date: Fri, 22 Aug 2003 18:26:22 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Alexey Melnikov , Mark Crispin , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061560999@[10.0.1.8]> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Cyrus Daboo wrote: > | 2). "tied rights" debate and alternatives. > > Leave this as it is. In the basic case clients are not likely to expose the > entire set of rights to the user anyway. We do that now and it confuses the > hell out of anyone who is not a sysadmin. Instead clients will likely have > just a limited set of access options as the default: > > Read-Only (lrs) > Read-Write (lrswi) > Write-Only (li) 'drop-box' > No Access () You probably want 'p' in Read-Write and Write-Only. Leaving this as it is still complicates the protocol unnecessarily. > i.e. the client effectively implements its own set of tied rights. > > The client can offer a more advanced UI for admins if the need arises. And > in that case it can find a way to express the server's tied-rights > capability in the more complex UI. How about another suggestion that takes this a step further. Add to Mark's ABNF the following (a trailing -T to indicate that the above 4 sets of rights are tied together, or alternatively something to indicate that all rights may be manipulated separately): A UNIX server: ACL2=MOST-SPECIFIC=U_G_O-T A fancier UNIX server with authuser vs. anyone (anonymous) support: ACL2=MOST-SPECIFIC=U_G_O_A-T A Cyrus server: ACL2=UNION=*U_*G_O A Cyrus server with authuser vs. anymous (anonymous) support: ACL2=UNION=*U_*G_O_A A TOPS-20 server [I'm not personally sure, but guessing]: ACL2=UNION=U_*G_O-T This removes the protocol and interface complications of arbitrary tied rights. The client knows in advance *exactly* what rights need to be set and removed together, and can present an appropriate UI. Of course, someone will now point out some implementation that requires tying the rights together in a different way... > NB I would find it useful if this document could actually specify what set > of rights should appear in the basic set I outlined above because I think a > lot of clients will present it that way. In particular what set of rights > should be used for 'Read-Write' - should they include 't' and/or 'e'? This > could appear in an 'implementation guide' section in the document. This needs to be done in any case. > | 4). Per-mailbox (per-hierarchy) access calculation models (as opposed to > | per-server) > > not sure... If this isn't addressed by ACL2, we need to leave a way for it to be extended without bringing up ACL3. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMDaqt060072 for ; Fri, 22 Aug 2003 15:13:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMDYLo060071 for ietf-imapext-bks; Fri, 22 Aug 2003 15:13:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMDWqt060064 for ; Fri, 22 Aug 2003 15:13:33 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7MMCsI3027270; Fri, 22 Aug 2003 18:12:54 -0400 Date: Fri, 22 Aug 2003 18:12:55 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Mark Crispin , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061558528@[10.0.1.8]> Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> <2147483647.1061558528@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Cyrus Daboo wrote: > ACL2=UNION > user= no limit > group= no limit > > ACL2=MOST-SPECIFIC > user= 1 always present > group= 1 always present > > Or if needs be we add another ACL2= capability that expresses the > restricted user=/group= model: ACL2=UGO (for user/group/others model) - > that would be added to the capabilities along with either of UNION or > MOST-SPECIFIC. This is more along the lines of what I was going for when I suggested ACL2=UNIX (the suggested name, of course, bearing unintended connotations). Mark's later ABNF example is also okay with me. Of course, this doesn't solve the complexity issue with tied rights. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MIOYqt051839 for ; Fri, 22 Aug 2003 11:24:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MIOYM2051838 for ietf-imapext-bks; Fri, 22 Aug 2003 11:24:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MIOSqt051824 for ; Fri, 22 Aug 2003 11:24:28 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MINmgG014449; Fri, 22 Aug 2003 11:23:48 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MINmY0023300; Fri, 22 Aug 2003 11:23:48 -0700 Date: Fri, 22 Aug 2003 11:23:48 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061560999@[10.0.1.8]> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Cyrus Daboo wrote: > | 1). Now to announce that the server supports a single user and/or group > | for a mailbox. > Either this is part of the UNION/MOST-SPECIFIC profile or we have a > separate (additional) capability to announce the restriction: > ACL2=ONE-USERGROUP. Mark's suggestion (which I just saw) of using an > ABNF-style for the capability to be more flexible would be fine too. Mind you, that was just a strawman to show that this isn't an intractable problem. I'm fine with any other solution, although being more flexible seems to be a good idea in general > | 2). "tied rights" debate and alternatives. > Leave this as it is. In the basic case clients are not likely to expose the > entire set of rights to the user anyway. We do that now and it confuses the > hell out of anyone who is not a sysadmin. Instead clients will likely have > just a limited set of access options as the default: > Read-Only (lrs) > Read-Write (lrswi) > Write-Only (li) 'drop-box' > No Access () Golly gee. That's the precise 99% case that I'm talking about!! If I were to do an ACL3, I would have just those four rights. Also, a "dual-use" name would have its "mailbox rights" and its "inferior rights", which would take care of list and create; there is a need for invisible mailboxes especially with drop-boxes. Everything else is fluff for most users. > | 3). Enumerating users/groups on the server > Out-of-scope for ACL2. Should be addressed by another extension. Agreed. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MI3Eqt051199 for ; Fri, 22 Aug 2003 11:03:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MI3EHi051198 for ietf-imapext-bks; Fri, 22 Aug 2003 11:03:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MI3Cqt051192 for ; Fri, 22 Aug 2003 11:03:13 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA01724; Fri, 22 Aug 2003 13:59:12 -0400 (EDT) Date: Fri, 22 Aug 2003 14:03:19 -0400 From: Cyrus Daboo To: Alexey Melnikov , Mark Crispin cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061560999@[10.0.1.8]> In-Reply-To: <3F4650A6.2020105@isode.com> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Friday, August 22, 2003 6:19 PM +0100 Alexey Melnikov wrote: | 1). Now to announce that the server supports a single user and/or group | for a mailbox. Either this is part of the UNION/MOST-SPECIFIC profile or we have a separate (additional) capability to announce the restriction: ACL2=ONE-USERGROUP. Mark's suggestion (which I just saw) of using an ABNF-style for the capability to be more flexible would be fine too. | 2). "tied rights" debate and alternatives. Leave this as it is. In the basic case clients are not likely to expose the entire set of rights to the user anyway. We do that now and it confuses the hell out of anyone who is not a sysadmin. Instead clients will likely have just a limited set of access options as the default: Read-Only (lrs) Read-Write (lrswi) Write-Only (li) 'drop-box' No Access () i.e. the client effectively implements its own set of tied rights. The client can offer a more advanced UI for admins if the need arises. And in that case it can find a way to express the server's tied-rights capability in the more complex UI. NB I would find it useful if this document could actually specify what set of rights should appear in the basic set I outlined above because I think a lot of clients will present it that way. In particular what set of rights should be used for 'Read-Write' - should they include 't' and/or 'e'? This could appear in an 'implementation guide' section in the document. | 3). Enumerating users/groups on the server Out-of-scope for ACL2. Should be addressed by another extension. | 4). Per-mailbox (per-hierarchy) access calculation models (as opposed to | per-server) not sure... -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHp4qt050845 for ; Fri, 22 Aug 2003 10:51:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHp4m2050844 for ietf-imapext-bks; Fri, 22 Aug 2003 10:51:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHp3qt050836 for ; Fri, 22 Aug 2003 10:51:03 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHovgG009045; Fri, 22 Aug 2003 10:50:58 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHovhY019105; Fri, 22 Aug 2003 10:50:57 -0700 Date: Fri, 22 Aug 2003 10:50:57 -0700 (PDT) From: Mark Crispin To: Pete Resnick cc: Alexey Melnikov , Steve Hole , Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Pete Resnick wrote: > we > had Larry arguing that we should remove the tied rights stuff from > the document, and that's the only relevant part of this discussion to > the WG moving forward. Does anyone care to summarize the > technical/operational argument for doing so at this point? Do folks > want to speak up in favor of such a change? I speak up against it. It is harmful. Tied rights were in RFC 2086. The effect of removing tied rights from ACL2 (or at least doing so without an acceptable alternative) would have the effect of rendering the other changes of ACL2 moot from my perspective. An example of an acceptable alternative would be to make r, w, and a the only mandatory-to-implement rights; meaning that s and t are implicitly part of the w right. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHnFqt050782 for ; Fri, 22 Aug 2003 10:49:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHnF6i050781 for ietf-imapext-bks; Fri, 22 Aug 2003 10:49:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHnEqt050775 for ; Fri, 22 Aug 2003 10:49:14 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7MHnC63027063; Fri, 22 Aug 2003 11:49:12 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Fri, 22 Aug 2003 11:49:12 -0600 From: Lyndon Nerenberg To: Timo Sirainen cc: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061552952@[192.168.42.6]> In-Reply-To: <54ED396C-D4C5-11D7-8B96-000393CC2E90@iki.fi> References: <54ED396C-D4C5-11D7-8B96-000393CC2E90@iki.fi> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7MHnEqt050777 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The problem with this is that you most likely want to see the full > message, or at least the message headers. After that grep you'd have to > use less and search the pattern again to see the full message. [We're really getting off topic here, but ...] Thanks for making my point: # display full (raw) text of matching messages grep -r -l -i pattern ~/Mail | xargs less # display just the headers of matching messages grep -r -l -i pattern ~/Mail | xargs sed -e '1,/^$/xGpq' | less > echo "1 list * | search from someone body hello | fetch > body.peek[header.fields (subject)] body.peek[text]<0.1000>" | imap > | less The RTTs associated with the several hundred SELECTS (one per folder searched) are what will kill you. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHl9qt050685 for ; Fri, 22 Aug 2003 10:47:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHl9q1050684 for ietf-imapext-bks; Fri, 22 Aug 2003 10:47:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHl7qt050679 for ; Fri, 22 Aug 2003 10:47:08 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA01405; Fri, 22 Aug 2003 13:43:03 -0400 (EDT) Date: Fri, 22 Aug 2003 13:47:11 -0400 From: Cyrus Daboo To: Lyndon Nerenberg , Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061560031@[10.0.1.8]> In-Reply-To: <2147483647.1061550187@[192.168.42.6]> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <2147483647.1061550187@[192.168.42.6]> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Lyndon, --On Friday, August 22, 2003 11:03 AM -0600 Lyndon Nerenberg wrote: |> The IMAP server is the only thing which KNOWS which users/groups are |> available | | Not necessarily. For example, it's (usually) not possible for an IMAP | server to enumerate all the principals in a Kerberos KDC. | | There are also significant security implications to providing a complete | list of users. Agreed. I think all the client needs to be able to do is map an ACL uid into some type of 'friendly name'. That could easily be done by providing a mapping between an email address (which will likely have the 'friendly name' associated with it via an address book/directory service in the client) and the ACL uid. Whether that is done through IMAP or via some other route is open for debate. I think one proposal was to simply have the IMAP server return a uri indicating the appropriate way to do that mapping. That could point to an LDAP server and include a search spec/schema etc for doing the mapping in each direction, or it could indicate the presence of an IMAP command that would do the mapping via IMP itself. In any case this is not for ACL2 but some other extension... -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHgGqt050318 for ; Fri, 22 Aug 2003 10:42:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHgGMu050317 for ietf-imapext-bks; Fri, 22 Aug 2003 10:42:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHgFqt050312 for ; Fri, 22 Aug 2003 10:42:15 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 18:41:35 +0100 Message-ID: <3F4655CC.50408@isode.com> Date: Fri, 22 Aug 2003 18:41:32 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: Mark Crispin , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> <2147483647.1061558528@[10.0.1.8]> In-Reply-To: <2147483647.1061558528@[10.0.1.8]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > > Hi Mark, > > --On Friday, August 22, 2003 9:58 AM -0700 Mark Crispin > wrote: > > |> > Mark, do you have a strawman for such a proposal? Since each of the > |> > proposals served up by the "RFC 2086 camp" are getting volleyed > back, > |> > perhaps its time for a proposal from the "UNIX ACL camp". ;) > |> For better or worse, the current ACL2 document seems to address the > |> problem. We could simply sign off on ACL2, declare victory, and go > home. > | > | In case it wasn't clear, that *is* my proposal. > | > | Put another way: end the Byzantine argument, sign off on the current > ACL2 > | document as-is, declare victory, and go home. > > I am almost OK with ACL2, but my big concern is still translating this > into something that will be useable in a client. I don't want to > present a UI to a user that allows them to do something the server > does not support - i.e. try and set ACLs for multiple user='s when the > server only allows one user/group etc. Right now ACL2 is not specific > enough in pinning down the allowed behaviour of identifiers - > specifically how many user/group identifiers are allowed in any one > ACL. If we can simply address that I will be happy. This could simply > be done by stating the maximum number of allowed user= or group= > identifiers for each profile, i.e.: > > ACL2=UNION > user= no limit > group= no limit > > ACL2=MOST-SPECIFIC > user= 1 always present > group= 1 always present > > Or if needs be we add another ACL2= capability that expresses the > restricted user=/group= model: ACL2=UGO (for user/group/others model) > - that would be added to the capabilities along with either of UNION > or MOST-SPECIFIC. > I've just replied to Paul that I like his suggestion. What you propose (the latter, as I think the number of users/groups allowed is actually orthogonal to access calculation model. Of course just having one user/group make it simpler) will work for me too. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHeLqt050246 for ; Fri, 22 Aug 2003 10:40:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHeL3X050245 for ietf-imapext-bks; Fri, 22 Aug 2003 10:40:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHeKqt050234 for ; Fri, 22 Aug 2003 10:40:20 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHdcCK002469; Fri, 22 Aug 2003 10:39:38 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHdcEj018412; Fri, 22 Aug 2003 10:39:38 -0700 Date: Fri, 22 Aug 2003 10:39:37 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061558528@[10.0.1.8]> Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> <2147483647.1061558528@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Cyrus Daboo wrote: > Right now ACL2 is not specific enough in pinning down the > allowed behaviour of identifiers - specifically how many user/group > identifiers are allowed in any one ACL. If we can simply address that I > will be happy. Sounds good to me. > This could simply be done by stating the maximum number of > allowed user= or group= identifiers for each profile Is it really true that all ACL2=UNION will have no limit and all ACL2=MOST-SPECIFIC will be fixed at 1? Suggest some way that the server can indicate this. After all, ABNF has foo always one foo *foo zero or more foo's 1*foo one or more foo's so it isn't as if we don't know how to express this concept in a concise way. > Or if needs be we add another ACL2= capability that expresses the > restricted user=/group= model: ACL2=UGO (for user/group/others model) - > that would be added to the capabilities along with either of UNION or > MOST-SPECIFIC. What about just one user, but zero or more groups? Using ABNF, maybe we could have something like: A UNIX server: ACL2=MOST-SPECIFIC=U_G_O A fancier UNIX server with authuser vs. anyone (anonymous) support: ACL2=MOST-SPECIFIC=U_G_O_A A Cyrus server: ACL2=UNION=*U_*G_O A Cyrus server with authuser vs. anymous (anonymous) support: ACL2=UNION=*U_*G_O_A A TOPS-20 server: ACL2=UNION=U_*G_O -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHbMqt050143 for ; Fri, 22 Aug 2003 10:37:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHbMuU050142 for ietf-imapext-bks; Fri, 22 Aug 2003 10:37:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHbLqt050136 for ; Fri, 22 Aug 2003 10:37:21 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.2b2); Fri, 22 Aug 2003 12:37:22 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <3F464D58.8030501@isode.com> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> X-Mailer: Eudora [Macintosh version 6.0a29] Date: Fri, 22 Aug 2003 12:37:19 -0500 To: Alexey Melnikov From: Pete Resnick Subject: Re: acl-08: questions Cc: Mark Crispin , Steve Hole , Paul Smith , ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 8/22/03 at 6:05 PM +0100, Alexey Melnikov wrote: >I think there is a compelling case for working on generic ACL2 with >tied rights (or a reasonable alternative), etc As I read this thread (the S/N ratio being not terribly helpful), leaving aside all of the other issues that were already addressed, we had Larry arguing that we should remove the tied rights stuff from the document, and that's the only relevant part of this discussion to the WG moving forward. Does anyone care to summarize the technical/operational argument for doing so at this point? Do folks want to speak up in favor of such a change? I am sticking with the presumption of leaving the document as-is unless there is a consensus to change it. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHRbqt049617 for ; Fri, 22 Aug 2003 10:27:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHRbQM049616 for ietf-imapext-bks; Fri, 22 Aug 2003 10:27:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHRaqt049610 for ; Fri, 22 Aug 2003 10:27:36 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 18:27:25 +0100 Message-ID: <3F465277.90603@isode.com> Date: Fri, 22 Aug 2003 18:27:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Smith CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> In-Reply-To: <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Smith wrote: > > At 14:42 22/08/2003 +0100, Alexey Melnikov wrote: > >> Paul Smith wrote: >> >>> Maybe the server should be able to say exactly what rights it >>> allows, eg 'I support xyz rights', and if server developers want to >>> be restricted by the 'one user/one group/anyone' Unix problem, maybe >>> that could be another limit that the server could advertise, in a >>> general way that can be designed. That wouldn't be too bad - but >>> don't make it OS specific. >> >> >> I agree. >> >> My own position on this that a client should be able to >> a). Implement a basic UI for showing/modifying ACLs without a >> knowledge of the access calculation model being used by the server. >> We should be aiming to add all required commands/responses to achieve >> this. >> b). Implement an advanced UI for particular model(s) that the client >> recognizes. > > > How about, in either the LIST responses or a separate 'ACL-CAPA' > response having something like > ACL "Posix" swite lr p cx a g u1 > This could indicate that this mailbox is 'Unix' (in case someone wants > to have an advanced UI for that type) , and the 'swite' 'lr' 'p' 'cx' > 'a' rights are tied together, it supports multiple groups and a single > user > > You could have > ACL "FreeAndEasy" s w i t e l r p c x a g u > which supports anything or > ACL "VeryLimited" switecxa lr p u1 > which has a 'read' and a 'write' mode only and only supports a single > user and no groups > > For the Posix case, even if the client didn't understand that case > specifically it could tie the 'swite' checkboxes (or whatever) > together, and could only allow the selection of a single user, and > multiple groups as the identifier. I think I mostly like this. Also note, that currently RIGHTS-INFO response returns "switecxa lr p" part of the ACL "VeryLimited" switecxa lr p u1 Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHNoqt049458 for ; Fri, 22 Aug 2003 10:23:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHNoc1049457 for ietf-imapext-bks; Fri, 22 Aug 2003 10:23:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHNnqt049447 for ; Fri, 22 Aug 2003 10:23:49 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 515E7238CB; Fri, 22 Aug 2003 20:23:42 +0300 (EEST) Received: from iki.fi (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 5CA0423994; Fri, 22 Aug 2003 20:23:10 +0300 (EEST) Date: Fri, 22 Aug 2003 20:23:22 +0300 Subject: Re: acl-08: questions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Paul Smith , ietf-imapext@imc.org To: Lyndon Nerenberg From: Timo Sirainen In-Reply-To: <2147483647.1061549681@[192.168.42.6]> Message-Id: <54ED396C-D4C5-11D7-8B96-000393CC2E90@iki.fi> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7MHNnqt049452 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, Aug 22, 2003, at 19:54 Europe/Helsinki, Lyndon Nerenberg wrote: > Time has shown that monolithic tools just don't scale or provide the > power that a group of ad hoc simple tools can provide. This is the > power of UNIX. MH has this philosophy at its core. This again brings to my mind mail selection / action separation. I'm not sure how reasonably IMAP could be extended to do it, or if anyone else actually even would like to do it, but I've often wanted it when searching mails. > grep -r -i 'pattern' ${HOME}/Mail > > There is absolutely no way doing this search through IMAP will be even > close to as fast as that grep command. The problem with this is that you most likely want to see the full message, or at least the message headers. After that grep you'd have to use less and search the pattern again to see the full message. I'd much rather do something like this: echo "1 list * | search from someone body hello | fetch body.peek[header.fields (subject)] body.peek[text]<0.1000>" | imap | less I think it should even be possible to implement this in backwards compatible way. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHLwqt049391 for ; Fri, 22 Aug 2003 10:21:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHLwOV049390 for ietf-imapext-bks; Fri, 22 Aug 2003 10:21:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHLvqt049383 for ; Fri, 22 Aug 2003 10:21:57 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA00935; Fri, 22 Aug 2003 13:18:00 -0400 (EDT) Date: Fri, 22 Aug 2003 13:22:08 -0400 From: Cyrus Daboo To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061558528@[10.0.1.8]> In-Reply-To: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Friday, August 22, 2003 9:58 AM -0700 Mark Crispin wrote: |> > Mark, do you have a strawman for such a proposal? Since each of the |> > proposals served up by the "RFC 2086 camp" are getting volleyed back, |> > perhaps its time for a proposal from the "UNIX ACL camp". ;) |> For better or worse, the current ACL2 document seems to address the |> problem. We could simply sign off on ACL2, declare victory, and go home. | | In case it wasn't clear, that *is* my proposal. | | Put another way: end the Byzantine argument, sign off on the current ACL2 | document as-is, declare victory, and go home. I am almost OK with ACL2, but my big concern is still translating this into something that will be useable in a client. I don't want to present a UI to a user that allows them to do something the server does not support - i.e. try and set ACLs for multiple user='s when the server only allows one user/group etc. Right now ACL2 is not specific enough in pinning down the allowed behaviour of identifiers - specifically how many user/group identifiers are allowed in any one ACL. If we can simply address that I will be happy. This could simply be done by stating the maximum number of allowed user= or group= identifiers for each profile, i.e.: ACL2=UNION user= no limit group= no limit ACL2=MOST-SPECIFIC user= 1 always present group= 1 always present Or if needs be we add another ACL2= capability that expresses the restricted user=/group= model: ACL2=UGO (for user/group/others model) - that would be added to the capabilities along with either of UNION or MOST-SPECIFIC. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHK3qt049317 for ; Fri, 22 Aug 2003 10:20:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHK3d3049316 for ietf-imapext-bks; Fri, 22 Aug 2003 10:20:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHK2qt049307 for ; Fri, 22 Aug 2003 10:20:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 18:19:38 +0100 Message-ID: <3F4650A6.2020105@isode.com> Date: Fri, 22 Aug 2003 18:19:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Let's now talk about the list of open issues: 1). Now to announce that the server supports a single user and/or group for a mailbox. 2). "tied rights" debate and alternatives. 3). Enumerating users/groups on the server 4). Per-mailbox (per-hierarchy) access calculation models (as opposed to per-server) Have I forgotten anything? Mark Crispin wrote: >On Fri, 22 Aug 2003, Alexey Melnikov wrote: > > >>I think there is a compelling case for working on generic ACL2 with tied >>rights (or a reasonable alternative), etc even if we disagree whether >>using a filesystem ACL implementation is a good idea. >> >> > >Agreed. > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHFaqt049191 for ; Fri, 22 Aug 2003 10:15:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHFagV049190 for ietf-imapext-bks; Fri, 22 Aug 2003 10:15:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHFYqt049174 for ; Fri, 22 Aug 2003 10:15:35 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7MHFQri007765; Fri, 22 Aug 2003 13:15:28 -0400 (EDT) Message-ID: <3F465025.30703@oceana.com> Date: Fri, 22 Aug 2003 13:17:25 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Fri, 22 Aug 2003, Mark Crispin wrote: > >>>Mark, do you have a strawman for such a proposal? Since each of the >>>proposals served up by the "RFC 2086 camp" are getting volleyed back, >>>perhaps its time for a proposal from the "UNIX ACL camp". ;) >> >>For better or worse, the current ACL2 document seems to address the >>problem. We could simply sign off on ACL2, declare victory, and go home. > > > In case it wasn't clear, that *is* my proposal. Got it. For some reason I thought you weren't happy with the current ACL2. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHCuqt049038 for ; Fri, 22 Aug 2003 10:12:56 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHCtno049037 for ietf-imapext-bks; Fri, 22 Aug 2003 10:12:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHCrqt049027 for ; Fri, 22 Aug 2003 10:12:53 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHCnoa029019; Fri, 22 Aug 2003 10:12:49 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHCn1i017038; Fri, 22 Aug 2003 10:12:49 -0700 Date: Fri, 22 Aug 2003 10:12:49 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov cc: Steve Hole , Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F464D58.8030501@isode.com> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Alexey Melnikov wrote: > I think there is a compelling case for working on generic ACL2 with tied > rights (or a reasonable alternative), etc even if we disagree whether > using a filesystem ACL implementation is a good idea. Agreed. I don't seek to convince anyone that a filesystem ACL implementation is a good idea. I just seek to have a generic ACL2 which does not preclude implementation through the filesystem. The current ACL2 document seems to fufill that requirement. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHAFqt048927 for ; Fri, 22 Aug 2003 10:10:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHAFBE048926 for ietf-imapext-bks; Fri, 22 Aug 2003 10:10:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHACqt048917 for ; Fri, 22 Aug 2003 10:10:13 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHA7oa028605; Fri, 22 Aug 2003 10:10:07 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHA737016988; Fri, 22 Aug 2003 10:10:07 -0700 Date: Fri, 22 Aug 2003 10:10:07 -0700 (PDT) From: Mark Crispin To: Lyndon Nerenberg cc: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061549681@[192.168.42.6]> Message-ID: References: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> <2147483647.1061549681@[192.168.42.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Lyndon Nerenberg wrote: > Time has shown that monolithic tools just don't scale or provide the > power that a group of ad hoc simple tools can provide. This is the power > of UNIX. Amen to that. > If all you do is read and delete your e-mail, it's hard to understand why > this matters. If you use e-mail to the n'th degree, you quickly come to > appreciate the power and flexibility of having an arsenal of tools, and > you will use whichever tool is appropriate to solving a specific problem. Amen once again. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MH67qt048815 for ; Fri, 22 Aug 2003 10:06:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MH67qX048814 for ietf-imapext-bks; Fri, 22 Aug 2003 10:06:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MH65qt048808 for ; Fri, 22 Aug 2003 10:06:06 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 18:05:33 +0100 Message-ID: <3F464D58.8030501@isode.com> Date: Fri, 22 Aug 2003 18:05:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Steve Hole , Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: May I suggest that we stop this particular debate, as this is not productive. I think there is a compelling case for working on generic ACL2 with tied rights (or a reasonable alternative), etc even if we disagree whether using a filesystem ACL implementation is a good idea. Mark Crispin wrote: >On Fri, 22 Aug 2003, Steve Hole wrote: > > >>In fact, I would claim that what you are >>attempting is to use IMAP as a backdoor access control management protocol >>for regular UNIX files. >> >> > >That is true, just as IMAP is a backdoor file access mechanism for regular >files that just happen to contain messages. > >If you wish to change IMAP into something else, such as an operating >system, then you should realize that you are changing IMAP in a >fundamental way from what its creator intended. > >And by changing IMAP into something that it was never intended to be, it >will suck. It will cease to be the useful thing that it was intended to >be at its creation, and it will never be as good as something like >Exchange (note the recent Microsoft quote) which was intended to be the >other thing from its inception. > > > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MH38qt048715 for ; Fri, 22 Aug 2003 10:03:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MH38ix048714 for ietf-imapext-bks; Fri, 22 Aug 2003 10:03:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MH36qt048709 for ; Fri, 22 Aug 2003 10:03:06 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7MH3763026782; Fri, 22 Aug 2003 11:03:07 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Fri, 22 Aug 2003 11:03:07 -0600 From: Lyndon Nerenberg To: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061550187@[192.168.42.6]> In-Reply-To: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, August 22, 2003 10:15 AM +0100 Paul Smith wrote: > The IMAP server is the only thing which KNOWS which users/groups are > available Not necessarily. For example, it's (usually) not possible for an IMAP server to enumerate all the principals in a Kerberos KDC. There are also significant security implications to providing a complete list of users. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGxDqt048560 for ; Fri, 22 Aug 2003 09:59:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MGxDOj048559 for ietf-imapext-bks; Fri, 22 Aug 2003 09:59:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGxCqt048554 for ; Fri, 22 Aug 2003 09:59:12 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7MGxD63026748; Fri, 22 Aug 2003 10:59:13 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Fri, 22 Aug 2003 10:59:13 -0600 From: Lyndon Nerenberg To: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061549953@[192.168.42.6]> In-Reply-To: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thursday, August 21, 2003 5:26 PM +0100 Paul Smith wrote: > What other INTERNET protocol can you think of that requires clients to > behave differently depending on what OS their server is running on? FTP. (The TYPE and STRU commands.) --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGwtqt048550 for ; Fri, 22 Aug 2003 09:58:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MGwtZ1048549 for ietf-imapext-bks; Fri, 22 Aug 2003 09:58:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGwsqt048534 for ; Fri, 22 Aug 2003 09:58:54 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MGwnxu019340; Fri, 22 Aug 2003 09:58:49 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MGwnda016538; Fri, 22 Aug 2003 09:58:49 -0700 Date: Fri, 22 Aug 2003 09:58:49 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Mark Crispin wrote: > > Mark, do you have a strawman for such a proposal? Since each of the > > proposals served up by the "RFC 2086 camp" are getting volleyed back, > > perhaps its time for a proposal from the "UNIX ACL camp". ;) > For better or worse, the current ACL2 document seems to address the > problem. We could simply sign off on ACL2, declare victory, and go home. In case it wasn't clear, that *is* my proposal. Put another way: end the Byzantine argument, sign off on the current ACL2 document as-is, declare victory, and go home. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGsgqt048434 for ; Fri, 22 Aug 2003 09:54:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MGsgA6048433 for ietf-imapext-bks; Fri, 22 Aug 2003 09:54:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGsfqt048428 for ; Fri, 22 Aug 2003 09:54:41 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7MGsf63026705; Fri, 22 Aug 2003 10:54:41 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Fri, 22 Aug 2003 10:54:41 -0600 From: Lyndon Nerenberg To: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061549681@[192.168.42.6]> In-Reply-To: <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> References: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, August 22, 2003 3:42 PM +0100 Paul Smith wrote: > Do people share the data using non-IMAP methods? Yes. MH provides support for shared folders in it's toolset. And at least one IMAP server can provide an IMAP view of MH message stores. > If not, then make the mailbox data accessible to the user (owner) and > to a group containing the IMAP Server (and NNTP server, POP3 server etc > if you want) > >> > Am I missing something obvious? I must be, because it seems so >> > simple. > If people want to have shell access to an IMAP message store, then > maybe we should be looking into why they don't feel that IMAP clients > will do what they want. Eg, do people want a regex search facility in > IMAP? Time has shown that monolithic tools just don't scale or provide the power that a group of ad hoc simple tools can provide. This is the power of UNIX. MH has this philosophy at its core. If all you do is read and delete your e-mail, it's hard to understand why this matters. If you use e-mail to the n'th degree, you quickly come to appreciate the power and flexibility of having an arsenal of tools, and you will use whichever tool is appropriate to solving a specific problem. One example illustrates this. I have archives of my email going back to around 1987. This consists of tens of thousands of messages spread across hundreds of folders, all stored in MH format. If I want to search the entire archive for a string I can do two things: for i in folders ; do SELECT $i SEARCH .... done or grep -r -i 'pattern' ${HOME}/Mail There is absolutely no way doing this search through IMAP will be even close to as fast as that grep command. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGhNqt048164 for ; Fri, 22 Aug 2003 09:43:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MGhNXc048159 for ietf-imapext-bks; Fri, 22 Aug 2003 09:43:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGhMqt048136 for ; Fri, 22 Aug 2003 09:43:22 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MGhDoa024147; Fri, 22 Aug 2003 09:43:19 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MGhD7T014663; Fri, 22 Aug 2003 09:43:13 -0700 Date: Fri, 22 Aug 2003 09:43:13 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F4625C4.3040800@oceana.com> Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Ken Murchison wrote: > > Fortunately, there is another alternative: create an ACL mechanism which > > expresses relatively simple access control (such as UNIX) in a simple way, > > and allows for additional facilities as options. > Mark, do you have a strawman for such a proposal? Since each of the > proposals served up by the "RFC 2086 camp" are getting volleyed back, > perhaps its time for a proposal from the "UNIX ACL camp". ;) I've made such proposals numerous times. First of all, it is not "UNIX ACL camp". That label is a calculated straw man designed to descredit the position. This issue is reminiscent of a Byzantine debate. The Turks are at the gates, yet the entire focus is whether angels are male or female. For the 99% case, a user only needs to be able to control whether other users can read and/or tamper with a mailbox. "Other users" are split into "everybody" and "subset of everybody". For the most part, ACL2 does this. All other semantics, including such esoteric concepts as inheritance from less specific rights to more specific rights, negative rights, etc. should be optional. Their availability should be announced, but not made mandatory. For the most part, ACL2 fixes this flaw in RFC 2086. There needs to be a better identifier naming scheme than RFC 2086; I don't think that anyone disputs that RFC 2086's naming was broken. For the most part, ACL2 fixes this as well. For better or worse, the current ACL2 document seems to address the problem. We could simply sign off on ACL2, declare victory, and go home. Yes, it's hairy, but if it gets the hold-out servers on board and prevents a competiting ACL3 from happening it will be a good thing. Suppose we fail to agree? The outcome will be that IMAP ACLs will continue to languish in poorly-implemented obscurity because major servers and clients do not implement it. And the possibility of ACL3 always looms. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGKPqt047323 for ; Fri, 22 Aug 2003 09:20:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MGKPM9047322 for ietf-imapext-bks; Fri, 22 Aug 2003 09:20:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGKOqt047316 for ; Fri, 22 Aug 2003 09:20:24 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 2BA732869E0 for ; Fri, 22 Aug 2003 17:20:21 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 17:18:51 +0100 Message-Id: <5.2.1.1.2.20030822160111.05413d40@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 16:07:56 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:02 22/08/2003 -0400, you wrote: >On Fri, 22 Aug 2003, Paul Smith wrote: > > > Thinking of it from a CLIENT end, if the IMAP client can't obtain a list of > > users/groups that can be set, then ACL2 is going to be moderately unusable > > (even less so than ACL, because now the client needs to specify 'group=' or > > 'user=' correctly) > >If we were going to do this it should almost certainly be a separate >extention. OK, as I expected > > The IMAP server is the only thing which KNOWS which users/groups are > > available - so maybe the ACL standard should define a way of getting a list > > of users/groups, or there should be an accompanying IMAP extension to > do so. > >There are cases where the IMAP server may not, in fact, be able to >efficiently enumerate all of the users/groups it has available (though >verification/lookup may be cheap). Adding this additional requirement to >ACL2 is unaccepable. Okey dokey - it'd be a nice extra extension though, usability-wise. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MG2uqt046083 for ; Fri, 22 Aug 2003 09:02:56 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MG2ugE046082 for ietf-imapext-bks; Fri, 22 Aug 2003 09:02:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MG2sqt046067 for ; Fri, 22 Aug 2003 09:02:55 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MG2nin029866; Fri, 22 Aug 2003 09:02:50 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MG2njX012592; Fri, 22 Aug 2003 09:02:49 -0700 Date: Fri, 22 Aug 2003 09:02:49 -0700 (PDT) From: Mark Crispin To: Steve Hole cc: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Steve Hole wrote: > In fact, I would claim that what you are > attempting is to use IMAP as a backdoor access control management protocol > for regular UNIX files. That is true, just as IMAP is a backdoor file access mechanism for regular files that just happen to contain messages. If you wish to change IMAP into something else, such as an operating system, then you should realize that you are changing IMAP in a fundamental way from what its creator intended. And by changing IMAP into something that it was never intended to be, it will suck. It will cease to be the useful thing that it was intended to be at its creation, and it will never be as good as something like Exchange (note the recent Microsoft quote) which was intended to be the other thing from its inception. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFuUqt045218 for ; Fri, 22 Aug 2003 08:56:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MFuUkE045216 for ietf-imapext-bks; Fri, 22 Aug 2003 08:56:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFuTqt045206 for ; Fri, 22 Aug 2003 08:56:29 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MFuOgG023245; Fri, 22 Aug 2003 08:56:24 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MFuOoI012204; Fri, 22 Aug 2003 08:56:24 -0700 Date: Fri, 22 Aug 2003 08:56:24 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > Do people share the data using non-IMAP methods? Yes. Have you ever heard of something called "file sharing"? > > 1) that all IMAP servers operate on dedicated IMAP-only boxes > I didn't make that assumption at all. If access restrictions are strong (as > they are on Unix) then the IMAP Server can run under one account which has > full access to the mailbox. Oh? So you want the IMAP server to run as root? > I'd be wary of allowing shell access users full access to their mailbox > directories in any case (maybe I'm being naive again..) Yes, you are. There is 30 years of history in which people who have done just that. > If the IMAP server > uses a certain directory as its mailbox, what happens if the user goes and > dumps lots of raw MPG files into that directory with similar filenames as > files that the IMAP server expects to be message or mailbox files? Arbitrary file export works fine in UW imapd. > > 4) that there is no need for non-IMAP type access (e.g. grep, sed, > > editors) to mail files > Hmm, I'd see that as a good assumption... I'd see it as bad to allow people > to be able to edit raw message files... Too bad. This is what is there today. It can't be changed. Experience teaches that the world sometimes isn't as perfect and wonderful as you would like it to be. Sometimes you have to accomodate truly > If people want to have shell access to an IMAP message store, then maybe we > should be looking into why they don't feel that IMAP clients will do what > they want. Eg, do people want a regex search facility in IMAP? Yes, indeed, some people would like regex search in IMAP. But adding regex searches to IMAP won't make the problem go away (and it's not as easy to add regex search as you may think -- the problem being that there is no clear definition of what regex is). They also want to be able to use all their other tools. Basically, nothing shy of the full UNIX command language will do. > >No matter how contemptuously you may want to dismiss such environments, > >they are out there, and they represent the majority of IMAP servers. > But those IMAP servers don't support ACL, and no one's forcing them to. That's the problem. These IMAP servers don't support ACL, and want to because of client demand, but can't because RFC 2086 sucks so badly. The whole point of the IMAPEXT exercise with ACL was to fix this. Now, when it seems that we have a hard-fought fix, there is an aggressive effort to sabotage the fix and to preserve the status quo of IMAP ACL that can't be implemented in the majority of deployed IMAP servers. > My view is that people seem to have been saying 'lets have a unix variant > of ACL', which I would strongly oppose. I haven't been saying that. What I am saying is IMAP ACL should be fixed so that: 1) it can express UNIX access control (RFC 2086 is too weak to do so) 2) UNIX access control is a compliant subset of IMAP ACL (there are mandatory to implement aspects of RFC 2086 that conflict with this) > I would have less problem with being able to advertise an arbitrarily > reduced ACL feature-set for those unable/unwilling to implement the full > feature-set. This is exactly what I am talking about. Why then are you whacking me with a strawman that is not my position? Of course it is absurd to have a special ACL2=unix mode. The entire reason why I started discussing all the ACL2=tops-20, ACL2=NTFS, etc. modes was to demonstrate that ACL2=unix leads to madness. > I would see it as better to advertise the > feature-set available at the start of the session than only when someone > tries to do something that breaks it. Once again, this is what we are talking about. > But, if I was a Unix developer looking to implement an ACL-aware IMAP > server, I'd certainly be looking into ways of trying to get more > functionality than the Unix filesystem can offer, eg it can't be uncommon > for users to want to give both themselves and their PA full access to their > mailbox, but their associates read-only access and other people no access. The same desire applies to files. For better or worse, people have worked out ways of doing this with files. The problem is that RFC 2086 precludes this from being managed or queried from the IMAP end. RFC 2086 imposes an AFS model upon the world, whether or not AFS translates well to what is there. So people are forced to log in to a shell to do chmod/chgrp. And while they are there, they get into the habit of doing other shell operations instead of using IMAP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFm4qt044724 for ; Fri, 22 Aug 2003 08:48:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MFm4kQ044723 for ietf-imapext-bks; Fri, 22 Aug 2003 08:48:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFlwqt044716 for ; Fri, 22 Aug 2003 08:48:02 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7MFpNn07601; Fri, 22 Aug 2003 09:51:23 -0600 From: Steve Hole Date: Fri, 22 Aug 2003 09:51:23 -0700 To: Mark Crispin Subject: Re: acl-08: questions Cc: Paul Smith , ietf-imapext@imc.org In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7MFm2qt044718 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003 05:43:19 -0700 (PDT) Mark Crispin wrote: > > On Thu, 21 Aug 2003, Paul Smith wrote: > > But, why does the IMAP4 server have to rely solely on UNIX rights? Can't it > > implement its own on top? > > The answer is no. Yes, it can! > Some of the world is servers that co-exist with shell accounts. It is > meaningless for an IMAP server to implement ACL rights that are trivially > evaded by anyone who has shell (or FTP) access. It is not meaningless at all. In fact, I would claim that what you are attempting is to use IMAP as a backdoor access control management protocol for regular UNIX files. It absoutely is possible to (1) restrict access to mailbox files in traditional UNIX format such that shells and ftp have no more or less rights than they have today and (2) provide a richer, more granular access to mailboxes in the IMAP context. You will have to provide external IMAP-only metadata. > An ACL mechanism which is unable to express the rights of the existing > underlying mail store is worse than useless in environments in which the > underlying mail store is exposed in other ways. I strongly disagree. I believe that others do as well. I think that we are trading server implementation difficulty on one platform and format into protocol complexity, and thus client implementation difficulty. I think that is just full on wrong. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFDdqt042255 for ; Fri, 22 Aug 2003 08:13:39 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MFDdbY042254 for ietf-imapext-bks; Fri, 22 Aug 2003 08:13:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFDZqt042229 for ; Fri, 22 Aug 2003 08:13:37 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7MFH9n07087; Fri, 22 Aug 2003 09:17:09 -0600 From: Steve Hole Date: Fri, 22 Aug 2003 09:17:08 -0700 To: Paul Smith Subject: Re: acl-08: questions Cc: ietf-imapext@imc.org In-Reply-To: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> References: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7MFDcqt042246 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003 17:26:57 +0100 Paul Smith wrote: > What other INTERNET protocol can you think of that requires clients to > behave differently depending on what OS their server is running on? > > The whole point of INTERNET STANDARDS is that they aren't OS dependent. Precisely. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MF08qt040087 for ; Fri, 22 Aug 2003 08:00:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MF08VF040086 for ietf-imapext-bks; Fri, 22 Aug 2003 08:00:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MF06qt040076 for ; Fri, 22 Aug 2003 08:00:06 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 5765528632C for ; Fri, 22 Aug 2003 16:00:02 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 15:58:09 +0100 Message-Id: <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 15:42:18 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:45 22/08/2003 -0700, you wrote: > > Where's the flaw with that? > >We have terabytes (at least I think that it's still just terabytes) of >mail file data that people access both with IMAP and non-IMAP methods. Do people share the data using non-IMAP methods? If not, then make the mailbox data accessible to the user (owner) and to a group containing the IMAP Server (and NNTP server, POP3 server etc if you want) > > Am I missing something obvious? I must be, because it seems so simple. > >Yes, you are missing something obvious. You are making many false >presumptions: > 1) that all IMAP servers operate on dedicated IMAP-only boxes I didn't make that assumption at all. If access restrictions are strong (as they are on Unix) then the IMAP Server can run under one account which has full access to the mailbox. Other users can run on their own accounts on the same box without access to the mailbox directories. I'd be wary of allowing shell access users full access to their mailbox directories in any case (maybe I'm being naive again..) If the IMAP server uses a certain directory as its mailbox, what happens if the user goes and dumps lots of raw MPG files into that directory with similar filenames as files that the IMAP server expects to be message or mailbox files? By allowing (and 'encouraging') this type of free access to the mailbox files, then you're potentially asking for trouble with naive or malicious users. If you still want users to have access to their own mailbox, you could still give them access (see above) > 2) that all IMAP servers should operate only on dedicated IMAP-only boxes see above > 3) that it is alright to prohibit non-IMAP type access to mail files OK, maybe I made that assumption incorrectly, but there are ways around that, see above. > 4) that there is no need for non-IMAP type access (e.g. grep, sed, > editors) to mail files Hmm, I'd see that as a good assumption... I'd see it as bad to allow people to be able to edit raw message files... If people want to have shell access to an IMAP message store, then maybe we should be looking into why they don't feel that IMAP clients will do what they want. Eg, do people want a regex search facility in IMAP? But, see my responses above. >No matter how contemptuously you may want to dismiss such environments, >they are out there, and they represent the majority of IMAP servers. But those IMAP servers don't support ACL, and no one's forcing them to. >But, on the other hand, the repeated efforts to sabotage any attempt to >make IMAP ACLs be implementable in a UNIX filesystem environment are >equally non-constructive. My view is that people seem to have been saying 'lets have a unix variant of ACL', which I would strongly oppose. If you are going to support that, then you need Windows, Posix, DOS, VMS, MS SQL etc variants of ACL as well - and it becomes unworkable. I would have less problem with being able to advertise an arbitrarily reduced ACL feature-set for those unable/unwilling to implement the full feature-set. The only problem I have with this is that it will make life harder than ever for IMAP client developers who want to implement it - which isn't a good thing. I would see it as better to advertise the feature-set available at the start of the session than only when someone tries to do something that breaks it. (FWIW I have no problem with the draft-ietf-imapext-acl-09.txt document, except for the client implementation complexity issue) But, if I was a Unix developer looking to implement an ACL-aware IMAP server, I'd certainly be looking into ways of trying to get more functionality than the Unix filesystem can offer, eg it can't be uncommon for users to want to give both themselves and their PA full access to their mailbox, but their associates read-only access and other people no access. That wouldn't be possible if you limit yourselves to the Unix filesystem's capabilities. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MF05qt040073 for ; Fri, 22 Aug 2003 08:00:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MF05Qa040072 for ietf-imapext-bks; Fri, 22 Aug 2003 08:00:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MF04qt040066 for ; Fri, 22 Aug 2003 08:00:04 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 0452B284829 for ; Fri, 22 Aug 2003 16:00:00 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 15:58:12 +0100 Message-Id: <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 15:57:28 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <3F461DC0.1000805@isode.com> References: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 14:42 22/08/2003 +0100, Alexey Melnikov wrote: >Paul Smith wrote: >>Maybe the server should be able to say exactly what rights it allows, eg >>'I support xyz rights', and if server developers want to be restricted by >>the 'one user/one group/anyone' Unix problem, maybe that could be another >>limit that the server could advertise, in a general way that can be >>designed. That wouldn't be too bad - but don't make it OS specific. > >I agree. > >My own position on this that a client should be able to >a). Implement a basic UI for showing/modifying ACLs without a knowledge of >the access calculation model being used by the server. We should be aiming >to add all required commands/responses to achieve this. >b). Implement an advanced UI for particular model(s) that the client >recognizes. How about, in either the LIST responses or a separate 'ACL-CAPA' response having something like ACL "Posix" swite lr p cx a g u1 This could indicate that this mailbox is 'Unix' (in case someone wants to have an advanced UI for that type) , and the 'swite' 'lr' 'p' 'cx' 'a' rights are tied together, it supports multiple groups and a single user You could have ACL "FreeAndEasy" s w i t e l r p c x a g u which supports anything or ACL "VeryLimited" switecxa lr p u1 which has a 'read' and a 'write' mode only and only supports a single user and no groups For the Posix case, even if the client didn't understand that case specifically it could tie the 'swite' checkboxes (or whatever) together, and could only allow the selection of a single user, and multiple groups as the identifier. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEwxqt039865 for ; Fri, 22 Aug 2003 07:58:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MEwxPk039864 for ietf-imapext-bks; Fri, 22 Aug 2003 07:58:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org ([213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEwwqt039672 for ; Fri, 22 Aug 2003 07:58:58 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 65E255C65485 for ; Fri, 22 Aug 2003 17:57:43 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> Content-Type: text/plain Message-Id: <1061564263.24982.166.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 22 Aug 2003 17:57:43 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 2003-08-22 at 11:50, Paul Smith wrote: > Or, Unix developers have to come to terms with having to do something > relatively simple such as running the IMAP server in its own account with > full access to the mailboxes and implementing their own (straightforward) > ACL system on top. That's about the worst idea from security point of view. A single bug in your server could mean that the attacker got full access to everyone's mail. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEV5qt037076 for ; Fri, 22 Aug 2003 07:31:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MEV5fo037075 for ietf-imapext-bks; Fri, 22 Aug 2003 07:31:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEV4qt037068 for ; Fri, 22 Aug 2003 07:31:04 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 15:28:39 +0100 Message-ID: <3F462894.1060609@isode.com> Date: Fri, 22 Aug 2003 15:28:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Cyrus Daboo , Rob Siemborski , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >>, and >>the core set of rights. Then separate ACL2=AFS and ACL2=UNIX documents that >>implement the real extensions that provide specific implementations of this >>wrt identifiers etc. Rob already described what ACL2=UNIX would look like, >>and ACL2=AFS is pretty much already covered by the original ACL. >> > >Half-agree. > >I suggest something a bit different: > >Define a set of rights, not as protocol items, but as "operations". Then >define a means by which a server announces the rights that it exports and >what the operations are. For example, a UNIX server may says "I have a W >right which permits operations wisd." In a Cyrus type server, it would >have a one right/one operation export. > >Now, instead of defining ACL2=AFS, ACL2=UNIX, ACL2=BLURDYBLOOP, we have a >general means by which the server announces how its access control model >works. > >There would be no tied rights in the ACL commands themselves. They'll >just use the server-announced rights, which on a UNIX server would >probably be R and W. > >Since there are no tied rights, there is no longer any magic about how >rights get set and cleared. Furthermore, the client has perfect knowledge >about the impact of what it does. > Although, this seems like an interesting idea, I don't think this is going to work. The client will have to present these server-announced rights in UI. You will either have to create an IANA registry for them, or the server has to send a description of what it is. This will require i18n... So I am not sure I would like to go this way. >The only wart is that we have to define what to do with operations which >either can not be granted or can not be revoked as a right. ACL's "a" >comes immediately to mind. Perhaps a template of such "fixed" items? > > > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MENiqt036568 for ; Fri, 22 Aug 2003 07:23:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MENi1O036567 for ietf-imapext-bks; Fri, 22 Aug 2003 07:23:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MENhqt036562 for ; Fri, 22 Aug 2003 07:23:43 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 15:23:22 +0100 Message-ID: <3F462757.6020804@isode.com> Date: Fri, 22 Aug 2003 15:23:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Newman CC: Rob Siemborski , Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: >On Fri, 22 Aug 2003, Paul Smith wrote: > > >>Thinking of it from a CLIENT end, if the IMAP client can't obtain a list of >>users/groups that can be set, then ACL2 is going to be moderately unusable >>(even less so than ACL, because now the client needs to specify 'group=' or >>'user=' correctly) >> >> > >If we were going to do this it should almost certainly be a separate >extention. > > >>The IMAP server is the only thing which KNOWS which users/groups are >>available - so maybe the ACL standard should define a way of getting a list >>of users/groups, or there should be an accompanying IMAP extension to do so. >> >> > >There are cases where the IMAP server may not, in fact, be able to >efficiently enumerate all of the users/groups it has available (though >verification/lookup may be cheap). Adding this additional requirement to >ACL2 is unaccepable. > I agree to both. If I remember correctly Chris Newman was planning to do a draft on this. Chris, are you going to do this, or should we solicit for a volunteer? Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEEpqt035959 for ; Fri, 22 Aug 2003 07:14:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MEEp5u035958 for ietf-imapext-bks; Fri, 22 Aug 2003 07:14:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEEnqt035953 for ; Fri, 22 Aug 2003 07:14:50 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7MEEbri030385; Fri, 22 Aug 2003 10:14:38 -0400 (EDT) Message-ID: <3F4625C4.3040800@oceana.com> Date: Fri, 22 Aug 2003 10:16:36 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > Fortunately, there is another alternative: create an ACL mechanism which > expresses relatively simple access control (such as UNIX) in a simple way, > and allows for additional facilities as options. Mark, do you have a strawman for such a proposal? Since each of the proposals served up by the "RFC 2086 camp" are getting volleyed back, perhaps its time for a proposal from the "UNIX ACL camp". ;) -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ME2qqt035571 for ; Fri, 22 Aug 2003 07:02:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ME2qDJ035570 for ietf-imapext-bks; Fri, 22 Aug 2003 07:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ME2pqt035560 for ; Fri, 22 Aug 2003 07:02:51 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX1.andrew.cmu.edu (MX1.andrew.cmu.edu [128.2.10.111]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7ME2oI3025851; Fri, 22 Aug 2003 10:02:50 -0400 Date: Fri, 22 Aug 2003 10:02:50 -0400 (EDT) From: Rob Siemborski To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > Thinking of it from a CLIENT end, if the IMAP client can't obtain a list of > users/groups that can be set, then ACL2 is going to be moderately unusable > (even less so than ACL, because now the client needs to specify 'group=' or > 'user=' correctly) If we were going to do this it should almost certainly be a separate extention. > The IMAP server is the only thing which KNOWS which users/groups are > available - so maybe the ACL standard should define a way of getting a list > of users/groups, or there should be an accompanying IMAP extension to do so. There are cases where the IMAP server may not, in fact, be able to efficiently enumerate all of the users/groups it has available (though verification/lookup may be cheap). Adding this additional requirement to ACL2 is unaccepable. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDoXqt035040 for ; Fri, 22 Aug 2003 06:50:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MDoXbC035039 for ietf-imapext-bks; Fri, 22 Aug 2003 06:50:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDoVqt035033 for ; Fri, 22 Aug 2003 06:50:32 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1) with ESMTP-TLS id 418398 for ietf-imapext@imc.org; Fri, 22 Aug 2003 08:50:34 -0500 Message-ID: <3F461FA5.7040106@ehsco.com> Date: Fri, 22 Aug 2003 08:50:29 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IMAP Extensions WG Subject: acl2=os-fs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just a comment that filesystem acls are a function of the OS plus the filesystem, so any declaration would need to allow both to be declared. EG, Win32+FAT is different from Win32+NTFS is different from UNIX+NTFS is different from UNIX+XFS is different from ... -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDkBqt034791 for ; Fri, 22 Aug 2003 06:46:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MDkBc9034789 for ietf-imapext-bks; Fri, 22 Aug 2003 06:46:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDkAqt034782 for ; Fri, 22 Aug 2003 06:46:10 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MDjxgG011562; Fri, 22 Aug 2003 06:46:05 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MDjxJC009271; Fri, 22 Aug 2003 06:45:59 -0700 Date: Fri, 22 Aug 2003 06:45:59 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > Didn't you see my possible 'solution' to the problem? I saw it. It isn't a solution. > Make the IMAP mailboxes *only* accessible to the 'imapdaemon' user account, > not to *anyone* else. Then the IMAP server has full access to all > accounts, and can control it as necessary, but no one else (except root) has. > Where's the flaw with that? We have terabytes (at least I think that it's still just terabytes) of mail file data that people access both with IMAP and non-IMAP methods. > Am I missing something obvious? I must be, because it seems so simple. Yes, you are missing something obvious. You are making many false presumptions: 1) that all IMAP servers operate on dedicated IMAP-only boxes 2) that all IMAP servers should operate only on dedicated IMAP-only boxes 3) that it is alright to prohibit non-IMAP type access to mail files 4) that there is no need for non-IMAP type access (e.g. grep, sed, editors) to mail files If you were to decree to our users that IMAP would henceforth be the only permitted access to mail data, you would get some rather forceful pushback. There are many many sites which still use (shudder) the traditional UNIX mailbox format, with INBOX on /var/spool/mail and all other mailboxes in a subdirectory of a shell account home directory. No matter how contemptuously you may want to dismiss such environments, they are out there, and they represent the majority of IMAP servers. IMAP ACL has stood out as something that is unimplementable in such environments; and yes I have had multiple requests to provide a means to manipulate UNIX access control via IMAP. I have resisted this, in the hope that RFC 2086 will be fixed. It seems that this was a mistake. Perhaps I should just specify CHMOD, CHGRP, CHOWN commands in IMAP. And get this so widely distributed that clients will feel compelled to implement it; and thus force all other servers to implement it too because everybody uses CHMOD/CHGRP/CHOWN and nobody uses RFC 2086. And, of course, IESG will halt all advancement of any form of IMAP ACL because there are now two competing IMAP ACL specifications. I do not think that this is constructive. I have not done this. But, on the other hand, the repeated efforts to sabotage any attempt to make IMAP ACLs be implementable in a UNIX filesystem environment are equally non-constructive. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDgvqt034683 for ; Fri, 22 Aug 2003 06:42:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MDgvZu034682 for ietf-imapext-bks; Fri, 22 Aug 2003 06:42:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDguqt034676 for ; Fri, 22 Aug 2003 06:42:56 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 14:42:27 +0100 Message-ID: <3F461DC0.1000805@isode.com> Date: Fri, 22 Aug 2003 14:42:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Smith CC: ietf-imapext@imc.org, Cyrus Daboo Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> In-Reply-To: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Smith wrote: > > At 11:37 21/08/2003 -0400, Cyrus Daboo wrote: > >> wrt identifiers etc. Rob already described what ACL2=UNIX would look >> like, and ACL2=AFS is pretty much already covered by the original ACL. >> >> The benefit of this is that server vendors only need concern >> themselves with coding to the particular model that is specific to >> them. The disadvantage is that clients have to implement multiple >> extensions. However, the UIs for those can be specifically tailored >> to each and can have safety checks etc to aid users in setting things >> up. > > > Sorry, but I think that's silly, and would quickly become a nightmare. > > What other INTERNET protocol can you think of that requires clients to > behave differently depending on what OS their server is running on? > > The whole point of INTERNET STANDARDS is that they aren't OS dependent. > > What happens if another platform comes along and wants another > 'ACL2=MYFABOS' identifier - either they'll have to do what everyone > else should have done and produce their own rights system to emulate > an existing one, or you'll have to force all IMAP client developers to > produce a new version of their software. > > That isn't workable. > > > Maybe the server should be able to say exactly what rights it allows, > eg 'I support xyz rights', and if server developers want to be > restricted by the 'one user/one group/anyone' Unix problem, maybe that > could be another limit that the server could advertise, in a general > way that can be designed. That wouldn't be too bad - but don't make it > OS specific. I agree. My own position on this that a client should be able to a). Implement a basic UI for showing/modifying ACLs without a knowledge of the access calculation model being used by the server. We should be aiming to add all required commands/responses to achieve this. b). Implement an advanced UI for particular model(s) that the client recognizes. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDTSqt034255 for ; Fri, 22 Aug 2003 06:29:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MDTSKt034254 for ietf-imapext-bks; Fri, 22 Aug 2003 06:29:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDTRqt034247 for ; Fri, 22 Aug 2003 06:29:27 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MDTMxu030055; Fri, 22 Aug 2003 06:29:22 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MDTL4I009011; Fri, 22 Aug 2003 06:29:22 -0700 Date: Fri, 22 Aug 2003 06:29:21 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > The file system is irrelevant IMHO... This is essentially a software issue. > IMAP isn't a unix protocol. Nonsense, and as the inventor of IMAP I deeply resent being lectured to in this way. IMAP is not a UNIX protocol, but it does not disregard (and has never disregarded) the requirements of the underlying mail store. The purpose of IMAP is to smooth out the various differences between mail stores, and to create a common framework in which they all interoperate. Note that word "interoperate". IMAP does not -- MUST NOT -- mandate something which is non-implementable and non-interoperable in a particular mail store. Making compromises in order to create interoperability is what the Internet protocols are all about. If you don't want to work on interoperable protocols, then go to work for AOL or Microsoft or one of the other vendors of proprietary protocols that go to great efforts to lock out other vendors. > >For all the ranting and raving about how ACL should be "good" or "ideal", > >RFC 2086 is a very limited design that can not express valid UNIX ACLs. > But why should it?? Because RFC 2086 is useless when what has to be expressed and maintained are UNIX ACLs, that's why. > RFC 2086 (for all its faults) is not about expressing > OS ACLs, it's about expressing IMAP mailbox ACLs. They're two totally > different things. They should not be, and in any environment other than a black box they must not be. > Our IMAP server is written for Windows, it totally ignores the Windows > ACLs, and implements its own RFC 2086 compliant ACLs - no problem. You don't have any users who access message data from non-IMAP applications, do you? In fact, you go to great efforts to document that the IMAP data files have to be protected from other Windows applications, since none of your access control works against those other applications, right? > a) Make it so that neither mary, nor harry, nor joe THEMSELVES have access > to the mail folders, but only the 'imapdaemon' account which is the > account which the IMAP server runs under which has full access to the > mailbox files and nothing else (this is what we do on Windows). That's a black box. Black boxes are not the entire world. > I don't see > how this is a problem. This sort of comment usually comes from a novice who has only been exposed to a limited number of environments and can't conceive of anything else. Experience generally cures this. > b) Encrypt the message files. This also suggest inexperience; you're thinking of read access while disregarding write, delete, rename access which encryption does nothing to address. > >There seems to be a false idea wedged inside the heads of certain > >individuals that an operating system is just an annoyance and that every > >Internet service can and should be its own operating system unto itself. > Yes, it should. Otherwise - why have Java? (just pass around raw binaries) > Why have HTML? (use .DOC, .PS etc). Etc, etc. The whole point of Internet > standards is that they are Platform/OS independent. You are comparing apples and oranges. Java is a programming language; HTML/Word/Postscript are document representations. These are not data access protocols; nor do they make any attempt to deal with a legacy. > >Once upon a time, the Internet development community understood this. > >That is what gave us interoperable protocols such as TELNET, FTP, and > >SMTP. > Yes, none of which (except for FTP, slightly (which cause quite a few > problems IME)) have platform specific features. They all work exactly the > same regardless of which platform the server is running on. Wrong. TELNET is very platform specific. As an example, for many years, a mandatory part of the TELNET protocol had no purpose other than to unlock the keyboard on an IBM 2741. TELNET went to great efforts to smooth out these details to the client and the end user, but it certainly did not ignore platform requirements. > To have the same platform independence allowing for file systems to be used > as the ACL system you MUST go for the lowest common denominator. Yes. The lowest common denominator must be supported and supportable. > So to allow for Unix developers to use the file system as their access > control system, the ACLs should be limited to 'read' or 'write' or > 'read/write' access, with one user (mailbox owner - presumably with full > rights), one group and anyone. Period. There should be no possibility of > being more granular with access, or by allowing multiple users different > rights etc. Wrong. Do not confuse "mandatory to implement" with "mandatory not to implement". Do not confuse "compliant implementation" with "implementation of all options." It is not required to limit IMAP ACLs to what UNIX can provide. It is simply required that UNIX access control be compliant with IMAP ACLs, and that UNIX access control must be expressible in IMAP ACLs. This means that IMAP ACLs must be rich enough to express UNIX access control (RFC 2086 is not -- it is inferior in certain ways), and that UNIX access control expressed in IMAP ACLs should be a compliant subset (not omit required attributes) of IMAP ACLs (RFC 2086 does not do this either). > However, that wouldn't be acceptable for many other developers who WANT > those other features (eg we have users who want to be able to STORE flags > on messages, but not be able to delete them or insert messages, and people > want to be able to give different rights to different people) RFC 2086 is not widely implemented by clients or deployed servers. Most users do not have any access control features today, much less fancy ones. > So, a platform independent (given Unix developers' wish to use their file > system as their access control system) method won't work. Non-sequitor. In effect, you are saying, "RFC 2086 is not widely implemented, therefore making it implementable on UNIX won't make it more widely implemented." > Either we have to make it vastly more complex and have different servers > providing different access methods That is not the only possibility. > Or, Unix developers have to come to terms with having to do something > relatively simple such as running the IMAP server in its own account with > full access to the mailboxes and implementing their own (straightforward) > ACL system on top. This is completely unacceptable. I think that you would be very unhappy if I dictated to you how a Windows server would work. Fortunately, there is another alternative: create an ACL mechanism which expresses relatively simple access control (such as UNIX) in a simple way, and allows for additional facilities as options. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDG8qt033412 for ; Fri, 22 Aug 2003 06:16:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MDG8Vc033410 for ietf-imapext-bks; Fri, 22 Aug 2003 06:16:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDG6qt033396 for ; Fri, 22 Aug 2003 06:16:07 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 14:15:31 +0100 Message-ID: <3F461771.6090600@isode.com> Date: Fri, 22 Aug 2003 14:15:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> In-Reply-To: <2147483647.1061465831@[10.0.1.6]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > This may be out of scope at this stage in the proceedings, but what I > would like to see is an ACL2 framework document that defines a basic > set of commands (ACL STORE/DELETE/SET, LISTRIGHTS) without explicit > syntax, and the core set of rights. Then separate ACL2=AFS and > ACL2=UNIX documents that implement the real extensions that provide > specific implementations of this wrt identifiers etc. I was trying to structure the document in the way that keeps this separation. Whether I was successful or not is of course a separate question. If the WG prefer to have separate documents, I can do that. > Rob already described what ACL2=UNIX would look like, and ACL2=AFS is > pretty much already covered by the original ACL. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MD1Gqt032007 for ; Fri, 22 Aug 2003 06:01:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MD1G4l032006 for ietf-imapext-bks; Fri, 22 Aug 2003 06:01:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MD1Fqt032000 for ; Fri, 22 Aug 2003 06:01:15 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id B578D237812 for ; Fri, 22 Aug 2003 14:00:07 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 13:57:43 +0100 Message-Id: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 13:56:33 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:43 22/08/2003 -0700, you wrote: >On Thu, 21 Aug 2003, Paul Smith wrote: > > But, why does the IMAP4 server have to rely solely on UNIX rights? Can't it > > implement its own on top? > >The answer is no. > >Some of the world is servers that co-exist with shell accounts. It is >meaningless for an IMAP server to implement ACL rights that are trivially >evaded by anyone who has shell (or FTP) access. Didn't you see my possible 'solution' to the problem? Make the IMAP mailboxes *only* accessible to the 'imapdaemon' user account, not to *anyone* else. Then the IMAP server has full access to all accounts, and can control it as necessary, but no one else (except root) has. Where's the flaw with that? Am I missing something obvious? I must be, because it seems so simple. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MChQqt031636 for ; Fri, 22 Aug 2003 05:43:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MChQTe031635 for ietf-imapext-bks; Fri, 22 Aug 2003 05:43:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MChOqt031629 for ; Fri, 22 Aug 2003 05:43:25 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MChJCK005054; Fri, 22 Aug 2003 05:43:19 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MChJDp008311; Fri, 22 Aug 2003 05:43:19 -0700 Date: Fri, 22 Aug 2003 05:43:19 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Paul Smith wrote: > But, why does the IMAP4 server have to rely solely on UNIX rights? Can't it > implement its own on top? The answer is no. Some of the world is servers that co-exist with shell accounts. It is meaningless for an IMAP server to implement ACL rights that are trivially evaded by anyone who has shell (or FTP) access. An ACL mechanism which is unable to express the rights of the existing underlying mail store is worse than useless in environments in which the underlying mail store is exposed in other ways. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KHqt014534 for ; Fri, 22 Aug 2003 02:20:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M9KHhm014533 for ietf-imapext-bks; Fri, 22 Aug 2003 02:20:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KFqt014520 for ; Fri, 22 Aug 2003 02:20:16 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 7643425C17F for ; Fri, 22 Aug 2003 10:20:12 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 10:16:20 +0100 Message-Id: <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 09:50:17 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:54 21/08/2003 -0700, Mark Crispin wrote: >On Thu, 21 Aug 2003, Paul Smith wrote: > > Exactly. (not being a Unix developer) I can't see why Unix should have > > special treatment and force an Internet standard to behave specially just > > because Unix does it that way. > >I am not asking for UNIX to have special treatment. I am asking for the >IMAP ACL specification to be well-designed enough that it can be >implemented with the underlying store being a UNIX filesystem. The file system is irrelevant IMHO... This is essentially a software issue. IMAP isn't a unix protocol. >For all the ranting and raving about how ACL should be "good" or "ideal", >RFC 2086 is a very limited design that can not express valid UNIX ACLs. But why should it?? RFC 2086 (for all its faults) is not about expressing OS ACLs, it's about expressing IMAP mailbox ACLs. They're two totally different things. Our IMAP server is written for Windows, it totally ignores the Windows ACLs, and implements its own RFC 2086 compliant ACLs - no problem. > > Exactly (again). The IMAP4 server can implement *any* scheme of rights on > > top of a file system. Forcing everyone into a non-ideal scheme just because > > 'it'll be easier for Unix developers' is a bad idea. > >Please explain how an IMAP server, logged in as user joe and with user >joe's filesystem access rights, can access a file on user mary's protected >directory. > >If your answer is "user mary's directory should not be protected against >joe", Yep - see below > that's the whole point -- how is this to happen given that joe and >mary only have IMAP access? Note that we do not want mary's directory to >be accessible to her ex-boyfriend harry who has shell access to that >system. a) Make it so that neither mary, nor harry, nor joe THEMSELVES have access to the mail folders, but only the 'imapdaemon' account which is the account which the IMAP server runs under which has full access to the mailbox files and nothing else (this is what we do on Windows). I don't see how this is a problem. or b) Encrypt the message files. >There seems to be a false idea wedged inside the heads of certain >individuals that an operating system is just an annoyance and that every >Internet service can and should be its own operating system unto itself. Yes, it should. Otherwise - why have Java? (just pass around raw binaries) Why have HTML? (use .DOC, .PS etc). Etc, etc. The whole point of Internet standards is that they are Platform/OS independent. >In the real world, you can't just go off and design your own universe unto >yourself. You have to work and interoperate with what is already there. >That means making compromises, and going the extra mile because some other >implementor is faced with a problem otherwise. See my earlier section with possible solutions to the Unix problem. Maybe Unix developers could make compromises like that... >Once upon a time, the Internet development community understood this. >That is what gave us interoperable protocols such as TELNET, FTP, and >SMTP. Yes, none of which (except for FTP, slightly (which cause quite a few problems IME)) have platform specific features. They all work exactly the same regardless of which platform the server is running on. To have the same platform independence allowing for file systems to be used as the ACL system you MUST go for the lowest common denominator. So to allow for Unix developers to use the file system as their access control system, the ACLs should be limited to 'read' or 'write' or 'read/write' access, with one user (mailbox owner - presumably with full rights), one group and anyone. Period. There should be no possibility of being more granular with access, or by allowing multiple users different rights etc. (Actually, there should probably just be a 'read-only' status that applies to everyone, so every mailbox is readable by everyone, but may be made not writable to everyone - we need to support Windows 95 'ACL's after all...) However, that wouldn't be acceptable for many other developers who WANT those other features (eg we have users who want to be able to STORE flags on messages, but not be able to delete them or insert messages, and people want to be able to give different rights to different people) So, a platform independent (given Unix developers' wish to use their file system as their access control system) method won't work. So, we need a compromise. Either we have to make it vastly more complex and have different servers providing different access methods (in a non-platform-specific way - ACL2=Unix won't work. ACL2=w:swid,r:lr would work), but this will make it MUCH more complex for client authors - and given the low take up that RFC 2086 has had in clients, I wouldn't want to make it even more difficult.. Or, Unix developers have to come to terms with having to do something relatively simple such as running the IMAP server in its own account with full access to the mailboxes and implementing their own (straightforward) ACL system on top. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KGqt014523 for ; Fri, 22 Aug 2003 02:20:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M9KGQ1014522 for ietf-imapext-bks; Fri, 22 Aug 2003 02:20:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KEqt014511 for ; Fri, 22 Aug 2003 02:20:14 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id EAC2525C16F for ; Fri, 22 Aug 2003 10:20:08 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 10:17:27 +0100 Message-Id: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 10:15:43 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:53 21/08/2003 -0400, Rob Siemborski wrote: >There is still magic about identifiers, however (e.g. you can only have >one user, one group, and anyone in the UNIX model). Sort of related to that. Is there any way, in IMAP, of a client getting hold of a list of users/groups that are available. Thinking of it from a CLIENT end, if the IMAP client can't obtain a list of users/groups that can be set, then ACL2 is going to be moderately unusable (even less so than ACL, because now the client needs to specify 'group=' or 'user=' correctly) You may say, that's an OS issue, but what if the client is on a different network from the server (or is, say, a Windows client talking to a Unix server) - it won't have access to the OS group/user lists It could potentially be an LDAP issue, but, say, on Windows, LDAP will generally be to an Active Directory Server, which may have different groupings and users from the IMAP server, and, for instance, many users on the LDAP server may not be users on the same IMAP server as you. The IMAP server is the only thing which KNOWS which users/groups are available - so maybe the ACL standard should define a way of getting a list of users/groups, or there should be an accompanying IMAP extension to do so. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KBqt014498 for ; Fri, 22 Aug 2003 02:20:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M9KB2H014496 for ietf-imapext-bks; Fri, 22 Aug 2003 02:20:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9K9qt014481 for ; Fri, 22 Aug 2003 02:20:10 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id C6AA225C059 for ; Fri, 22 Aug 2003 10:20:06 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 10:17:10 +0100 Message-Id: <5.2.1.1.2.20030822100237.03595020@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 10:03:23 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061471207@[10.0.1.6]> References: <1061484126.19011.119.camel@hurina> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 13:06 21/08/2003 -0400, you wrote: >|> It is probably also necessary to say that only one ACL2= can be in >|> the CAPABILITY line. >| >| My server supports multiple mailbox formats in same session. For example >| UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability >| wouldn't work. > >If that's going to be the case then there has to be a way for the client >to discover which ACL mode is being used on any one particular mailbox. >The current spec does not address that. This could be solved by having the >ACL response in LIST return the mode if more than one is present in capability: > >C: A002 LIST (ACL) "" * >S: * LIST () "/" INBOX (("ACL=UNIX" (("user=Fred" "rwipslextda")))) >S: * LIST () "." #news (("ACL=AFS" (("user=Fred" "rwipslextda")))) >S: A002 OK List with acl info completed Doesn't this start to look over complex... Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KCqt014503 for ; Fri, 22 Aug 2003 02:20:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M9KCmk014501 for ietf-imapext-bks; Fri, 22 Aug 2003 02:20:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KAqt014488 for ; Fri, 22 Aug 2003 02:20:10 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id B5E7025C12F for ; Fri, 22 Aug 2003 10:20:07 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 10:16:44 +0100 Message-Id: <5.2.1.1.2.20030822095735.04a5f238@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 10:02:22 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <2147483647.1061465831@[10.0.1.6]> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:19 21/08/2003 -0500, you wrote: >Before we get much further with this entire conversation: > >1. Who on this list has can and intends to implement ACL2 if it stays in >its current form? Yes, if and when it is implemented by a reasonable number of clients. We have implemented ACL because *some* form of ACL is required to allow usable mailbox sharing. Most of our users don't use ACL enabled IMAP clients (ie they use Eudora, Outlook, Outlook Express, Opera etc), so they actually need to set rights using our servers own UI. We've had no complaints from users that ACL isn't adequate for requirements, so we won't implement ACL2 'just for the sake of it' (it seems a lot more complex), but we will implement it if IMAP clients (that people use) start supporting it. >2. Who on this list cannot implement ACL2 in its current form? Not a problem. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M8AAqt007275 for ; Fri, 22 Aug 2003 01:10:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M8AA0O007274 for ietf-imapext-bks; Fri, 22 Aug 2003 01:10:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M8A9qt007258 for ; Fri, 22 Aug 2003 01:10:09 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id B30EC2597EB for ; Fri, 22 Aug 2003 09:10:05 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 09:00:53 +0100 Message-Id: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 21 Aug 2003 17:26:57 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061465831@[10.0.1.6]> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:37 21/08/2003 -0400, Cyrus Daboo wrote: >wrt identifiers etc. Rob already described what ACL2=UNIX would look like, >and ACL2=AFS is pretty much already covered by the original ACL. > >The benefit of this is that server vendors only need concern themselves >with coding to the particular model that is specific to them. The >disadvantage is that clients have to implement multiple extensions. >However, the UIs for those can be specifically tailored to each and can >have safety checks etc to aid users in setting things up. Sorry, but I think that's silly, and would quickly become a nightmare. What other INTERNET protocol can you think of that requires clients to behave differently depending on what OS their server is running on? The whole point of INTERNET STANDARDS is that they aren't OS dependent. What happens if another platform comes along and wants another 'ACL2=MYFABOS' identifier - either they'll have to do what everyone else should have done and produce their own rights system to emulate an existing one, or you'll have to force all IMAP client developers to produce a new version of their software. That isn't workable. Maybe the server should be able to say exactly what rights it allows, eg 'I support xyz rights', and if server developers want to be restricted by the 'one user/one group/anyone' Unix problem, maybe that could be another limit that the server could advertise, in a general way that can be designed. That wouldn't be too bad - but don't make it OS specific. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M8A6qt007239 for ; Fri, 22 Aug 2003 01:10:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M8A6YZ007236 for ietf-imapext-bks; Fri, 22 Aug 2003 01:10:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M8A4qt007217 for ; Fri, 22 Aug 2003 01:10:04 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id A15722596E3 for ; Fri, 22 Aug 2003 09:10:01 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 09:02:36 +0100 Message-Id: <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 21 Aug 2003 17:30:36 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:53 21/08/2003 -0400, Rob Siemborski wrote: >There is still magic about identifiers, however (e.g. you can only have >one user, one group, and anyone in the UNIX model). But, why does the IMAP4 server have to rely solely on UNIX rights? Can't it implement its own on top? By saying that you want IMAP4 ACLs to only allow 'one user, one group and anyone' you are placing a BIG restriction on everyone else who can allow anything because they implement their own rights model. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI8Oqt045717 for ; Thu, 21 Aug 2003 11:08:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LI8OPZ045716 for ietf-imapext-bks; Thu, 21 Aug 2003 11:08:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI8Mqt045711 for ; Thu, 21 Aug 2003 11:08:23 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI7Yxu006450; Thu, 21 Aug 2003 11:07:34 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI7YTF024262; Thu, 21 Aug 2003 11:07:34 -0700 Date: Thu, 21 Aug 2003 11:07:34 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: Rob Siemborski , Cyrus Daboo , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <1061486469.24980.124.camel@hurina> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> <2147483647.1061471207@[10.0.1.6]> <1061486469.24980.124.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Timo Sirainen wrote: > Since MOST-SPECIFIC is more limited and mostly useful only for UNIX > filesystems Is that true? Don't most other filesystems implement MOST-SPECIFIC? TOPS-20 implemented UNION, but since there were no negative rights there wasn't the complexity associated with that. Actually, I misspoke earlier about TOPS-20. I just remembered that in TOPS-20 release 7, the ability exists to have an arbitrary site-written ACL mechanism. The way this is done is that if access is denied via the traditional access control mechanism, a daemon is queried if it will grant the access. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI2kqt045576 for ; Thu, 21 Aug 2003 11:02:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LI2kTL045575 for ietf-imapext-bks; Thu, 21 Aug 2003 11:02:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI2jqt045567 for ; Thu, 21 Aug 2003 11:02:45 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI2din024161; Thu, 21 Aug 2003 11:02:39 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI2dXh024035; Thu, 21 Aug 2003 11:02:39 -0700 Date: Thu, 21 Aug 2003 11:02:39 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Rob Siemborski wrote: > We're certainly not going to implement it until its clear that the spec > has stabilized I agree that this is a concern. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI0Hqt045496 for ; Thu, 21 Aug 2003 11:00:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LI0HJE045495 for ietf-imapext-bks; Thu, 21 Aug 2003 11:00:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI0Gqt045490 for ; Thu, 21 Aug 2003 11:00:16 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI0CCK013319 for ; Thu, 21 Aug 2003 11:00:12 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI0C51023898 for ; Thu, 21 Aug 2003 11:00:12 -0700 Date: Thu, 21 Aug 2003 11:00:12 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: ACL2=TOPS-20 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Like UNIX, TOPS-20 has three fields for both files and directories: owner, group, and world. There are two major differences from UNIX in the interpretation of these fields: 1) The owner of a home directory is the associated user name (guaranteed one to one); this includes directories on other domestic filesystems with the same directory name. Directories on foreign filesystems, and non-home directories, do not have an owner. The owner name can not be changed. 2) Multiple groups are possible; the list is associated with the containing directory (so all files in the directory get the same group list). All groups get the same access. The owner of a directory can alter a directory's group list but only a sysadmin can grant a user's membership in a group. TOPS-20 files have the following independent access bits which are relevant: read, write, append, list in directory. TOPS-20 directories have the following independent access bits: contained files can be accessed (if their access bits permit), administer, create new files in directory. Unlike UNIX, rights are inherited from least to most specific. Unlike AFS, inheritance is cumulative; there are no negative rights. So if world has a right, that right goes to group and owner; and if group has a right, that right goes to owner. I'll look into the details of ACL2=NTFS, ACL2=SQL, ACL2=POSIX, ACL2=VMS, ACL2=VM370, etc. shortly. Get ready to implement all of these in your clients. Who knows, maybe in a little while we'll have as many ACL2=xxx types as we have valid MIME charsets; and we all know how wonderful that experience has been for all of us. Of course, the current ACL2 draft expresses (or at least tries to do so) all of this now, without making the client know about all these different types of filesystems. Perhaps we ought to give the current ACL2 draft a try before talking further about undoing the years of work put into it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHVmqt044505 for ; Thu, 21 Aug 2003 10:31:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LHVm3T044504 for ietf-imapext-bks; Thu, 21 Aug 2003 10:31:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHVlqt044499 for ; Thu, 21 Aug 2003 10:31:47 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7LHVlI3023589 for ; Thu, 21 Aug 2003 13:31:47 -0400 Date: Thu, 21 Aug 2003 13:31:47 -0400 (EDT) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Pete Resnick wrote: > 1. Who on this list has can and intends to implement ACL2 if it stays > in its current form? There is nothing preventing us from implementing ACL2 in its current form. I'm not sure we'd be in a big rush to do it unless a number of clients implemented the feature and we saw demand for it. We're certainly not going to implement it until its clear that the spec has stabilized (We're having enough fun tracking ANNOTATEMORE). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHLAqt044233 for ; Thu, 21 Aug 2003 10:21:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LHLAeL044232 for ietf-imapext-bks; Thu, 21 Aug 2003 10:21:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHL8qt044214 for ; Thu, 21 Aug 2003 10:21:09 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id B5D875EBF9AE; Thu, 21 Aug 2003 20:21:09 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: Rob Siemborski Cc: Cyrus Daboo , ietf-imapext@imc.org In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> <2147483647.1061471207@[10.0.1.6]> Content-Type: text/plain Message-Id: <1061486469.24980.124.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 21 Aug 2003 20:21:09 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-08-21 at 20:11, Rob Siemborski wrote: > This is only the case in the current model if there is some reason that a > server will *interpret* any ACL differently (so it would be possible for > Timo's server to get away with always using MOST-SPECIFIC, for example). > > If he wants some mailboxes to be UNION and some to be MOST-SPECIFIC, then > the current spec is in trouble of course. Since MOST-SPECIFIC is more limited and mostly useful only for UNIX filesystems, of course I'll want to implement UNION for stores which allow it. If there really will be multiple rules, I would probably add support for all of them in all stores which can be made to support them, and let the administrator choose which one to use. This is to make sure people don't start complaining "but it worked this way in the other server and we already got used to it, why doesn't yours work like that?". Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHHSqt044061 for ; Thu, 21 Aug 2003 10:17:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LHHSxn044056 for ietf-imapext-bks; Thu, 21 Aug 2003 10:17:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHHOqt043984 for ; Thu, 21 Aug 2003 10:17:24 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7LHHGI3023558; Thu, 21 Aug 2003 13:17:16 -0400 Date: Thu, 21 Aug 2003 13:17:16 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Timo Sirainen , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Mark Crispin wrote: > On Thu, 21 Aug 2003, Timo Sirainen wrote: > > My server supports multiple mailbox formats in same session. For example > > UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability > > wouldn't work. > > SQL mailboxes, eh? OK, we need an eighth (or was it ninth?) ACL2=type > model. Looks like that way won't scale. It is totally unclear that one of ACL2=UNIX, ACL2=MOST-SPECIFIC, or ACL2=UNION would not work for an SQL mailbox. The problem Timo is demonstrating is that the spec wouldn't allow for different ACL types on different mailboxes on the same server. One that the current ACL2 draft shares. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHBsqt043644 for ; Thu, 21 Aug 2003 10:11:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LHBrL3043643 for ietf-imapext-bks; Thu, 21 Aug 2003 10:11:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHBpqt043635 for ; Thu, 21 Aug 2003 10:11:52 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7LHBkI3023551; Thu, 21 Aug 2003 13:11:46 -0400 Date: Thu, 21 Aug 2003 13:11:46 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Timo Sirainen , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061471207@[10.0.1.6]> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> <2147483647.1061471207@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Cyrus Daboo wrote: > | My server supports multiple mailbox formats in same session. For example > | UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability > | wouldn't work. > > If that's going to be the case then there has to be a way for the client to > discover which ACL mode is being used on any one particular mailbox. The > current spec does not address that. This could be solved by having the ACL > response in LIST return the mode if more than one is present in capability: This is only the case in the current model if there is some reason that a server will *interpret* any ACL differently (so it would be possible for Timo's server to get away with always using MOST-SPECIFIC, for example). If he wants some mailboxes to be UNION and some to be MOST-SPECIFIC, then the current spec is in trouble of course. > S: * LIST () "." #news (("ACL=AFS" (("user=Fred" "rwipslextda")))) Note that ACL=AFS is a misnomer, it should be UNION. Though both would be interpreted the same way when authorization happened, the mere fact that we are using UNION semantics does not imply AFS is in use. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LH6iqt043447 for ; Thu, 21 Aug 2003 10:06:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LH6iqT043446 for ietf-imapext-bks; Thu, 21 Aug 2003 10:06:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LH6hqt043440 for ; Thu, 21 Aug 2003 10:06:43 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA04909; Thu, 21 Aug 2003 13:02:45 -0400 (EDT) Date: Thu, 21 Aug 2003 13:06:47 -0400 From: Cyrus Daboo To: Timo Sirainen , Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061471207@[10.0.1.6]> In-Reply-To: <1061484126.19011.119.camel@hurina> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Timo, --On Thursday, August 21, 2003 7:42 PM +0300 Timo Sirainen wrote: |> It is probably also necessary to say that only one ACL2= can be in |> the CAPABILITY line. | | My server supports multiple mailbox formats in same session. For example | UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability | wouldn't work. If that's going to be the case then there has to be a way for the client to discover which ACL mode is being used on any one particular mailbox. The current spec does not address that. This could be solved by having the ACL response in LIST return the mode if more than one is present in capability: C: A002 LIST (ACL) "" * S: * LIST () "/" INBOX (("ACL=UNIX" (("user=Fred" "rwipslextda")))) S: * LIST () "." #news (("ACL=AFS" (("user=Fred" "rwipslextda")))) S: A002 OK List with acl info completed -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LH11qt043227 for ; Thu, 21 Aug 2003 10:01:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LH11eo043226 for ietf-imapext-bks; Thu, 21 Aug 2003 10:01:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LH10qt043209 for ; Thu, 21 Aug 2003 10:01:00 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LH0kCK002311; Thu, 21 Aug 2003 10:00:46 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LH0kj8019416; Thu, 21 Aug 2003 10:00:46 -0700 Date: Thu, 21 Aug 2003 10:00:46 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: Rob Siemborski , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <1061484126.19011.119.camel@hurina> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Timo Sirainen wrote: > My server supports multiple mailbox formats in same session. For example > UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability > wouldn't work. SQL mailboxes, eh? OK, we need an eighth (or was it ninth?) ACL2=type model. Looks like that way won't scale. If we have some way to fetch a prototype that expresses how the server does access control, we wouldn't be in this situation. RFC 2086 LISTRIGHTS sort-of did this, but fell short of what is needed. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGsnqt042957 for ; Thu, 21 Aug 2003 09:54:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGsnsP042956 for ietf-imapext-bks; Thu, 21 Aug 2003 09:54:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGsmqt042951 for ; Thu, 21 Aug 2003 09:54:48 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGshoa031454; Thu, 21 Aug 2003 09:54:43 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGsgnN019105; Thu, 21 Aug 2003 09:54:43 -0700 Date: Thu, 21 Aug 2003 09:54:42 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Paul Smith wrote: > Exactly. (not being a Unix developer) I can't see why Unix should have > special treatment and force an Internet standard to behave specially just > because Unix does it that way. I am not asking for UNIX to have special treatment. I am asking for the IMAP ACL specification to be well-designed enough that it can be implemented with the underlying store being a UNIX filesystem. For all the ranting and raving about how ACL should be "good" or "ideal", RFC 2086 is a very limited design that can not express valid UNIX ACLs. > Exactly (again). The IMAP4 server can implement *any* scheme of rights on > top of a file system. Forcing everyone into a non-ideal scheme just because > 'it'll be easier for Unix developers' is a bad idea. Please explain how an IMAP server, logged in as user joe and with user joe's filesystem access rights, can access a file on user mary's protected directory. If your answer is "user mary's directory should not be protected against joe", that's the whole point -- how is this to happen given that joe and mary only have IMAP access? Note that we do not want mary's directory to be accessible to her ex-boyfriend harry who has shell access to that system. There seems to be a false idea wedged inside the heads of certain individuals that an operating system is just an annoyance and that every Internet service can and should be its own operating system unto itself. In the real world, you can't just go off and design your own universe unto yourself. You have to work and interoperate with what is already there. That means making compromises, and going the extra mile because some other implementor is faced with a problem otherwise. Once upon a time, the Internet development community understood this. That is what gave us interoperable protocols such as TELNET, FTP, and SMTP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGgDqt042380 for ; Thu, 21 Aug 2003 09:42:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGgDGw042379 for ietf-imapext-bks; Thu, 21 Aug 2003 09:42:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGgBqt042373 for ; Thu, 21 Aug 2003 09:42:11 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id ACC7E5EBF9AE; Thu, 21 Aug 2003 19:42:06 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: Rob Siemborski Cc: ietf-imapext@imc.org In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Content-Type: text/plain Message-Id: <1061484126.19011.119.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 21 Aug 2003 19:42:06 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-08-21 at 17:54, Rob Siemborski wrote: > One way to do this would be to define an ACL2=UNIX, with a description > like the following (I suspect Mark could supply better text/requirements): Remember also that there's POSIX ACLs which want tied rights, but don't have the user/group count restriction. > It is probably also necessary to say that only one ACL2= can be in > the CAPABILITY line. My server supports multiple mailbox formats in same session. For example UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability wouldn't work. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGeaqt042304 for ; Thu, 21 Aug 2003 09:40:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGeaNM042303 for ietf-imapext-bks; Thu, 21 Aug 2003 09:40:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGeZqt042297 for ; Thu, 21 Aug 2003 09:40:35 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGdnxu023101; Thu, 21 Aug 2003 09:39:49 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGdnjH018405; Thu, 21 Aug 2003 09:39:49 -0700 Date: Thu, 21 Aug 2003 09:39:49 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , Larry Greenfield , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Rob Siemborski wrote: > There is still magic about identifiers, however (e.g. you can only have > one user, one group, and anyone in the UNIX model). ACL2's way of fixing the broken RFC 2086 model of identifers is one way of doing it. I can envision others, including some which may be cleaner. The only "magic" is that defining a group's right can remove another group's right; and this could be resolved with a means that makes it clear that there is only (and always) one group. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGYcqt042073 for ; Thu, 21 Aug 2003 09:34:38 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGYcPX042072 for ietf-imapext-bks; Thu, 21 Aug 2003 09:34:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGYbqt042066 for ; Thu, 21 Aug 2003 09:34:37 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGYXoa028052; Thu, 21 Aug 2003 09:34:33 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGYXkn018282; Thu, 21 Aug 2003 09:34:33 -0700 Date: Thu, 21 Aug 2003 09:34:33 -0700 (PDT) From: Mark Crispin To: Pete Resnick cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Pete Resnick wrote: > 1. Who on this list has can and intends to implement ACL2 if it stays > in its current form? I intend to implement ACL2, as long as ACL2 does not preclude a compliant *and* useful implementation on UNIX the way that RFC 2086 did. I believe that ACL2 in its current form can be implemented in a compliant and useful way on UNIX. This is not to say that it is certain that I will not discover an unpleasant surprise in the process of implementing it; but I do not anticipate any such surprises. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGU8qt041944 for ; Thu, 21 Aug 2003 09:30:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGU8AD041943 for ietf-imapext-bks; Thu, 21 Aug 2003 09:30:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGU6qt041938 for ; Thu, 21 Aug 2003 09:30:06 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id CCA11243218 for ; Thu, 21 Aug 2003 17:29:58 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Thu, 21 Aug 2003 17:24:23 +0100 Message-Id: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 21 Aug 2003 17:24:09 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:38 21/08/2003 -0700, Mark Crispin wrote: >This horror will be inflicted >the IMAP world if the IMAP world refuses to bite the bullet and create a >general ACL model. Exactly. (not being a Unix developer) I can't see why Unix should have special treatment and force an Internet standard to behave specially just because Unix does it that way. IMAP4 isn't a Unix protocol, it's a platform independent Internet protocol. When designing an ACL standard, you should primarily design it to do its job, regardless of platform - ie be able to define access rights for various actions to various people/groups on various objects. Once you've got an ACL design that works well, then, if you want, you can look at the WHOLE RANGE of platforms it may be run on, to see if there's any minor changes that could be made to the design to make it easier to implement, but, if there's any hint of conflict, the 'good' design should obviously be preferred over the 'easy on one platform' design. >Tied rights aren't the problem. It's RFC 2086's broken design of >identifiers that were the problem. Exactly (again). The IMAP4 server can implement *any* scheme of rights on top of a file system. Forcing everyone into a non-ideal scheme just because 'it'll be easier for Unix developers' is a bad idea. When designing an ACL standard, the platforms it's going to run on should be the last thing to consider. It's possible to implement any ACL system I can think of using software, so come up with one that makes sense and then everyone can implement it that way (unless Unix developers aren't as resourceful as developers on other platforms ;-) ) Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGJKqt041677 for ; Thu, 21 Aug 2003 09:19:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGJKbL041676 for ietf-imapext-bks; Thu, 21 Aug 2003 09:19:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGJIqt041670 for ; Thu, 21 Aug 2003 09:19:19 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.2b2) for ; Thu, 21 Aug 2003 11:19:16 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <2147483647.1061465831@[10.0.1.6]> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> X-Mailer: Eudora [Macintosh version 6.0a29] Date: Thu, 21 Aug 2003 11:19:14 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: Re: acl-08: questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 8/21/03 at 11:37 AM -0400, Cyrus Daboo wrote: >This may be out of scope at this stage in the proceedings... I'm not picking on Cyrus; it was just a good line to quote. Before we get much further with this entire conversation: 1. Who on this list has can and intends to implement ACL2 if it stays in its current form? 2. Who on this list cannot implement ACL2 in its current form? It is way late in the game to be revisiting this topic yet again and I want to get a sense of where we are before we start down any sort of new path. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFrCqt040650 for ; Thu, 21 Aug 2003 08:53:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LFrCO1040649 for ietf-imapext-bks; Thu, 21 Aug 2003 08:53:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFrAqt040641 for ; Thu, 21 Aug 2003 08:53:10 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7LFr14w022814; Thu, 21 Aug 2003 11:53:01 -0400 Date: Thu, 21 Aug 2003 11:53:00 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Cyrus Daboo , Larry Greenfield , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Mark Crispin wrote: > Since there are no tied rights, there is no longer any magic about how > rights get set and cleared. Furthermore, the client has perfect knowledge > about the impact of what it does. > > The only wart is that we have to define what to do with operations which > either can not be granted or can not be revoked as a right. ACL's "a" > comes immediately to mind. Perhaps a template of such "fixed" items? There is still magic about identifiers, however (e.g. you can only have one user, one group, and anyone in the UNIX model). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFpBqt040489 for ; Thu, 21 Aug 2003 08:51:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LFpBIm040488 for ietf-imapext-bks; Thu, 21 Aug 2003 08:51:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFpAqt040479 for ; Thu, 21 Aug 2003 08:51:10 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LFoQoa020950; Thu, 21 Aug 2003 08:50:26 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LFoPQf015718; Thu, 21 Aug 2003 08:50:25 -0700 Date: Thu, 21 Aug 2003 08:50:25 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: Rob Siemborski , Larry Greenfield , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061465831@[10.0.1.6]> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Cyrus Daboo wrote: > This may be out of scope at this stage in the proceedings, but what I would > like to see is an ACL2 framework document that defines a basic set of > commands (ACL STORE/DELETE/SET, LISTRIGHTS) without explicit syntax Agreed. >, and > the core set of rights. Then separate ACL2=AFS and ACL2=UNIX documents that > implement the real extensions that provide specific implementations of this > wrt identifiers etc. Rob already described what ACL2=UNIX would look like, > and ACL2=AFS is pretty much already covered by the original ACL. Half-agree. I suggest something a bit different: Define a set of rights, not as protocol items, but as "operations". Then define a means by which a server announces the rights that it exports and what the operations are. For example, a UNIX server may says "I have a W right which permits operations wisd." In a Cyrus type server, it would have a one right/one operation export. Now, instead of defining ACL2=AFS, ACL2=UNIX, ACL2=BLURDYBLOOP, we have a general means by which the server announces how its access control model works. There would be no tied rights in the ACL commands themselves. They'll just use the server-announced rights, which on a UNIX server would probably be R and W. Since there are no tied rights, there is no longer any magic about how rights get set and cleared. Furthermore, the client has perfect knowledge about the impact of what it does. The only wart is that we have to define what to do with operations which either can not be granted or can not be revoked as a right. ACL's "a" comes immediately to mind. Perhaps a template of such "fixed" items? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFd6qt039667 for ; Thu, 21 Aug 2003 08:39:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LFd6g7039666 for ietf-imapext-bks; Thu, 21 Aug 2003 08:39:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFd5qt039651 for ; Thu, 21 Aug 2003 08:39:05 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LFcxoa019223; Thu, 21 Aug 2003 08:38:59 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LFcwEW015312; Thu, 21 Aug 2003 08:38:58 -0700 Date: Thu, 21 Aug 2003 08:38:58 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Larry Greenfield , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Rob Siemborski wrote: > However, we keep coming back to this problem *only* because of the > specific case of the UNIX filesystem. I want to implement the specific case of the TOPS-20 filesystem as well. In my copious free time, I am upgrading the TOPS-20 IMAP server to talk IMAP4rev1 (currently it is at RFC 1176 state). This is becoming especially important since TOPS-20's mailer seems to be much more spam/virus-resistant than UNIX; apparently most spamware sends LF-only newlines which TOPS-20's SMTP server rejects. I can guess that perhaps some people may want to implement the specific case of the VMS filesystem. On a more serious vein, I am also working on the specific case of the Windows filesystem. You can't wish this problem away by saying that it is "just UNIX". > One way to do this would be to define an ACL2=UNIX I don't object to this, but be prepared for ACL2=TOPS-20, ACL2=VMS, ACL2=WINDOWS. Probably also ACL2=POSIX. This horror will be inflicted the IMAP world if the IMAP world refuses to bite the bullet and create a general ACL model. > This, of course, has the disadvantage of adding a third ACL model Fourth, fifth, sixth, and seventh. > I think there are less general implementation questions with this than > there are with arbitrary tied rights. If we do want to go forward with > the possibility of arbitrary tied rights, I would very much like to hear > about implementation experience. Tied rights aren't the problem. It's RFC 2086's broken design of identifiers that were the problem. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFbYqt039485 for ; Thu, 21 Aug 2003 08:37:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LFbYKC039483 for ietf-imapext-bks; Thu, 21 Aug 2003 08:37:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFbWqt039474 for ; Thu, 21 Aug 2003 08:37:32 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA03333; Thu, 21 Aug 2003 11:33:06 -0400 (EDT) Date: Thu, 21 Aug 2003 11:37:11 -0400 From: Cyrus Daboo To: Rob Siemborski , Larry Greenfield cc: Mark Crispin , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061465831@[10.0.1.6]> In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Thursday, August 21, 2003 10:54 AM -0400 Rob Siemborski wrote: | This, of course, has the disadvantage of adding a third ACL model, and | extending what the model controls (instead of specifying just how access | is calculated, it also specifies what an ACL can look like). It also | probably requires client authors to do a little more work to support the | wildly different ACL model, though I think this is mitigated by avoiding | the need to deal with arbitrary tied rights. I was actually composing a message to propose something similar. Right now I think the current ACL2 is too complex from an implementation point of view. Frankly, if the client UI is any more complicated than the OS's UI for setting file system permissions, the ordinary users are not going to be able to cope - or even worse do something stupid and expose themselves to security breaches. I think the whole union vs most-specific bit is way out of scope for ordinary users - its fine if we're only targeting ACL at admins though. This may be out of scope at this stage in the proceedings, but what I would like to see is an ACL2 framework document that defines a basic set of commands (ACL STORE/DELETE/SET, LISTRIGHTS) without explicit syntax, and the core set of rights. Then separate ACL2=AFS and ACL2=UNIX documents that implement the real extensions that provide specific implementations of this wrt identifiers etc. Rob already described what ACL2=UNIX would look like, and ACL2=AFS is pretty much already covered by the original ACL. The benefit of this is that server vendors only need concern themselves with coding to the particular model that is specific to them. The disadvantage is that clients have to implement multiple extensions. However, the UIs for those can be specifically tailored to each and can have safety checks etc to aid users in setting things up. The ACL2 framework document should explicitly state that a client will be expected to support the official multiple variants of ACL2. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LEt8qt036786 for ; Thu, 21 Aug 2003 07:55:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LEt8OM036784 for ietf-imapext-bks; Thu, 21 Aug 2003 07:55:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LEt1qt036766 for ; Thu, 21 Aug 2003 07:55:02 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7LEsx4w022689; Thu, 21 Aug 2003 10:54:59 -0400 Date: Thu, 21 Aug 2003 10:54:59 -0400 (EDT) From: Rob Siemborski To: Larry Greenfield cc: Mark Crispin , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F43EF41.1060307@andrew.cmu.edu> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Larry Greenfield wrote: > > This argument has been made over and over again for years now, and has > > been rejected every time. > > > > If the IMAPEXT Working Group is unable to create an ACL mechanism that > > will support UNIX filesystem permissions, then it should declare > > defeat. > > The reason this keeps coming up is that UNIX filesystem permissions are > not ACLs. The insistence to force them into an ACL model is ungainly and > shows the problems with drastically increased complexity. > > RFC 2086 isn't implementable on top of AFS, either. While it is nice to > be able to export legacy mail stores via IMAP, it should not be a > requirement for every IMAP feature to support every legacy mail store. The constraints that the UNIX filesystem are currently placing on ACL2 cause several warts to appear in the design and usability of the specification. a) Arbitrary tied rights cause clients a problem in that it is hard to predict what a given command will do, even if we report what actually happened afterwards. This makes UI hard to design. b) Restrictions placed on identifiers also don't fit very well (as evidenced by Mark's 'ACL RENAME' proposal earlier this year) Dealing with this sort of thing in a general way is bound to cause interoperability problems, and make designing a reasonable client interface hard. However, we keep coming back to this problem *only* because of the specific case of the UNIX filesystem. It is unclear to me that there is a demand for arbitrary tied rights. What does appear to be demanded is the ability to use the UNIX filesystem mode bits. We shouldn't twist the entire protocol just to force ACL semantics onto the UNIX filesystem. However, it may be possible to just solve the UNIX filesystem case (within ACL2) without the above problems. One way to do this would be to define an ACL2=UNIX, with a description like the following (I suspect Mark could supply better text/requirements): a) an ACL must always have entries for 'user=(owner)' 'group=(a group)' and 'anyone'/'anonymous' - if the group or user is changed, than the current group or user is removed from the ACL. b) only the owner of the mailbox may have the 'a' rights c) the following rights for a given identifier must always be set or cleared together: 'swite' 'lr' (I'm not personally sure what happens to d, x, p, and c) d) negative rights are not allowed If a client violates any of these (say, buy setting rights separately, or by setting two groups in one command), simply return NO (and fail the entire command-- no ACL changes). This is a significant improvement because now a client knows *in advance* *exactly* how the server will react to a given ACL command. It can also provide an appropriate UI for each of UNIX, MOST-SPECIFIC, and UNION. The complexity of arbitrary tied rights can be removed, along with the desire for ACL RENAME, and the extra responses generated by tied rights commands which don't set all of the appropriate bits. This, of course, has the disadvantage of adding a third ACL model, and extending what the model controls (instead of specifying just how access is calculated, it also specifies what an ACL can look like). It also probably requires client authors to do a little more work to support the wildly different ACL model, though I think this is mitigated by avoiding the need to deal with arbitrary tied rights. It is probably also necessary to say that only one ACL2= can be in the CAPABILITY line. I think there are less general implementation questions with this than there are with arbitrary tied rights. If we do want to go forward with the possibility of arbitrary tied rights, I would very much like to hear about implementation experience. Comments? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L9e5qt012962 for ; Thu, 21 Aug 2003 02:40:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7L9e5jB012961 for ietf-imapext-bks; Thu, 21 Aug 2003 02:40:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L9e0qt012952 for ; Thu, 21 Aug 2003 02:40:05 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7L9hiV26562; Thu, 21 Aug 2003 03:43:45 -0600 Message-ID: <3F449368.3050706@isode.com> Date: Thu, 21 Aug 2003 10:39:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061419465.19010.110.camel@hurina> <200308202327.h7KNRSf16708@katroo.Sendmail.COM> In-Reply-To: <200308202327.h7KNRSf16708@katroo.Sendmail.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Timo Sirainen writes: > > >>On Thu, 2003-08-21 at 01:17, Mark Crispin wrote: >> >> >>>While we're at it, since you keep on asking to remove the reference >>>argument in LIST, we will also need to add CWD and PWD commands to replace >>>this functionality. >>> >>> >>I never really understood this. What exactly do you gain from the >>reference argument? Isn't LIST ref/ box exactly the same as >>LIST "" ref/box? >> >> > >There are at least two differences: >1) if the mailbox name argument starts with a namespace prefix, > then the reference argument is ignored (consider the last two rows > in the table on page 41 of rfc3051) >2) % and * should not be treated specially when present in the reference > argument > I am not sure that the 2 is true? Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KNRXqt064442 for ; Wed, 20 Aug 2003 16:27:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KNRXZY064441 for ietf-imapext-bks; Wed, 20 Aug 2003 16:27:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KNRWqt064435 for ; Wed, 20 Aug 2003 16:27:33 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.sendmail.com [63.211.143.38]) by spork.sendmail.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h7KNRQU2009000; Wed, 20 Aug 2003 16:27:26 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.7) with ESMTP id h7KNRSf16708; Wed, 20 Aug 2003 16:27:28 -0700 (PDT) Message-Id: <200308202327.h7KNRSf16708@katroo.Sendmail.COM> To: Timo Sirainen Cc: ietf-imapext@imc.org From: Philip Guenther Subject: Re: acl-08: questions In-reply-to: <1061419465.19010.110.camel@hurina> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061419465.19010.110.camel@hurina> Date: Wed, 20 Aug 2003 16:21:24 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen writes: > >On Thu, 2003-08-21 at 01:17, Mark Crispin wrote: >> While we're at it, since you keep on asking to remove the reference >> argument in LIST, we will also need to add CWD and PWD commands to replace >> this functionality. > >I never really understood this. What exactly do you gain from the >reference argument? Isn't LIST ref/ box exactly the same as >LIST "" ref/box? There are at least two differences: 1) if the mailbox name argument starts with a namespace prefix, then the reference argument is ignored (consider the last two rows in the table on page 41 of rfc3051) 2) % and * should not be treated specially when present in the reference argument Philip Guenther guenther@sendmail.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KNFmqt064211 for ; Wed, 20 Aug 2003 16:15:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KNFmrf064210 for ietf-imapext-bks; Wed, 20 Aug 2003 16:15:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KNFlqt064205 for ; Wed, 20 Aug 2003 16:15:47 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KNFeCK004036; Wed, 20 Aug 2003 16:15:40 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KNFeXa028369 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 16:15:40 -0700 Date: Wed, 20 Aug 2003 16:16:02 -0700 (Pacific Daylight Time) From: Mark Crispin To: Timo Sirainen cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <1061419465.19010.110.camel@hurina> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061419465.19010.110.camel@hurina> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 21 Aug 2003, Timo Sirainen wrote: > > While we're at it, since you keep on asking to remove the reference > > argument in LIST, we will also need to add CWD and PWD commands to replace > > this functionality. > I never really understood this. What exactly do you gain from the > reference argument? Isn't LIST ref/ box exactly the same as > LIST "" ref/box? No, those two are most certainly not the same. LIST ref/ box is equivalent to CWD ref/ LIST "" box This *may* be the equivalent of LIST "" ref/box or it may be something completely different. Consider LIST mail/ ~fred/box on a UNIX system. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMiVqt063496 for ; Wed, 20 Aug 2003 15:44:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KMiVN6063495 for ietf-imapext-bks; Wed, 20 Aug 2003 15:44:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMiTqt063489 for ; Wed, 20 Aug 2003 15:44:29 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 299105EBF9AE; Thu, 21 Aug 2003 01:44:26 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: Mark Crispin Cc: ietf-imapext@imc.org In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Content-Type: text/plain Message-Id: <1061419465.19010.110.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 21 Aug 2003 01:44:26 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-08-21 at 01:17, Mark Crispin wrote: > While we're at it, since you keep on asking to remove the reference > argument in LIST, we will also need to add CWD and PWD commands to replace > this functionality. I never really understood this. What exactly do you gain from the reference argument? Isn't LIST ref/ box exactly the same as LIST "" ref/box? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMHGqt061860 for ; Wed, 20 Aug 2003 15:17:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KMHGlc061859 for ietf-imapext-bks; Wed, 20 Aug 2003 15:17:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMHEqt061848 for ; Wed, 20 Aug 2003 15:17:15 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KMH9oa023532; Wed, 20 Aug 2003 15:17:09 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KMH9Xa024121 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 15:17:09 -0700 Date: Wed, 20 Aug 2003 15:17:30 -0700 (Pacific Daylight Time) From: Mark Crispin To: Larry Greenfield cc: Rob Siemborski , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F43EF41.1060307@andrew.cmu.edu> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Larry Greenfield wrote: > The reason this keeps coming up is that UNIX filesystem permissions are > not ACLs. The insistence to force them into an ACL model is ungainly and > shows the problems with drastically increased complexity. IMHO, this is a flaw in the design of ACL; that is, RFC 2086 has certain unnecessary attributes which created the problem. > While it is nice to > be able to export legacy mail stores via IMAP, it should not be a > requirement for every IMAP feature to support every legacy mail store. ACL stands out as the one IMAP feature that (1) does not support legacy mail stores and (2) can not be addressed in some other way. Here is a possible alternative to having UNIX filesystem permissions in ACL2: 1) add UNIXACL extension 2) add UNIXCHMOD, UNIXCHOWN, UNIXCHGRP commands 3) add \UNIXMOD=xxx \UNIXGROUP=xxx \UNIXOWNER=xxx attributes to LIST While we're at it, since you keep on asking to remove the reference argument in LIST, we will also need to add CWD and PWD commands to replace this functionality. A successor to RFC 2683 will state that due since UNIX filesystems are so common, that all client and server implementations SHOULD implement UNIXACL in addition to ACL or ACL2. CWD/PWD will be mandatory to implement. Or.... We can stop this bickering and work together on a common specification that is suitable for all of us. I know which choice I prefer. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLxfqt060694 for ; Wed, 20 Aug 2003 14:59:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLxfRR060693 for ietf-imapext-bks; Wed, 20 Aug 2003 14:59:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLxeqt060652 for ; Wed, 20 Aug 2003 14:59:40 -0700 (PDT) (envelope-from leg@andrew.cmu.edu) Received: from mirapoint.corp.google.com (IDENT:mirapoint@mirapoint.corp.google.com [10.32.0.80]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h7KLxZ3d007608; Wed, 20 Aug 2003 14:59:35 -0700 Received: from andrew.cmu.edu (dunbar.corp.google.com [10.2.2.110]) by mirapoint.corp.google.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACN83917 (AUTH leg); Wed, 20 Aug 2003 14:59:30 -0700 (PDT) Message-ID: <3F43EF41.1060307@andrew.cmu.edu> Date: Wed, 20 Aug 2003 17:59:29 -0400 From: Larry Greenfield User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Wed, 20 Aug 2003, Rob Siemborski wrote: > >>It has been become clear that the ACL2 specification is made >>substantially more complex by the requirement that it be implemented >>on top of Unix filesystem permissions with tied rights. It is time to >>accept the fact that this may not be a reasonable requirement that can >>be satisfied in a simple and interoperable way. > > This argument has been made over and over again for years now, and has > been rejected every time. > > If the IMAPEXT Working Group is unable to create an ACL mechanism that > will support UNIX filesystem permissions, then it should declare > defeat. The reason this keeps coming up is that UNIX filesystem permissions are not ACLs. The insistence to force them into an ACL model is ungainly and shows the problems with drastically increased complexity. RFC 2086 isn't implementable on top of AFS, either. While it is nice to be able to export legacy mail stores via IMAP, it should not be a requirement for every IMAP feature to support every legacy mail store. Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLsaqt058708 for ; Wed, 20 Aug 2003 14:54:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLsaX1058707 for ietf-imapext-bks; Wed, 20 Aug 2003 14:54:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLsZqt058671 for ; Wed, 20 Aug 2003 14:54:35 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLsVgG026573; Wed, 20 Aug 2003 14:54:31 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLsVXa022434 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 14:54:31 -0700 Date: Wed, 20 Aug 2003 14:54:52 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lyndon Nerenberg {VE6BBM} cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <7B6BE881-D357-11D7-A887-000393D34A62@orthanc.ab.ca> Message-ID: References: <7B6BE881-D357-11D7-A887-000393D34A62@orthanc.ab.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: > > If you examine that code carefully, you will see that there is no > > requirement that it be used. > And ditto for POSIX ACLs. If you don't have them, you don't support > ACL2. There is a growing requirement to have ACLs in a traditional UNIX filesystem based IMAP environment. If ACL2 does not provide this, this requirement will mandate the creation of ACL3. It is bad enough that we will need ACL2. Please, let's solve the problem and avoid ACL3. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLn8qt056788 for ; Wed, 20 Aug 2003 14:49:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLn85V056787 for ietf-imapext-bks; Wed, 20 Aug 2003 14:49:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLn3qt056729 for ; Wed, 20 Aug 2003 14:49:03 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLmvoa018333; Wed, 20 Aug 2003 14:48:57 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLmv4A014230 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 14:48:57 -0700 Date: Wed, 20 Aug 2003 14:49:18 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: Lyndon Nerenberg {VE6BBM} , Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Rob Siemborski wrote: > It has been become clear that the ACL2 specification is made substantially > more complex by the requirement that it be implemented on top of Unix > filesystem permissions with tied rights. It is time to accept the fact > that this may not be a reasonable requirement that can be satisfied in a > simple and interoperable way. This argument has been made over and over again for years now, and has been rejected every time. If the IMAPEXT Working Group is unable to create an ACL mechanism that will support UNIX filesystem permissions, then it should declare defeat. I prefer that we work together in a spirit of cooperation without attacking the needs of a portion of the community. I do not understand why it is so important to certain individuals that IMAP not support UNIX filesystem permissions. I am not proposing that IMAP ACL not support Andrew filesystem permissions (which is essentially what RFC 2086 is). I am just trying to make IMAP ACL general enough to support other permission models. I need an ACL mechanism which supports UNIX filesystem permissions. If there is no other way, I will provide the IMAP world with a specification for a replacement to RFC 2086 which supports UNIX filesystem permissions. We would then end up with two non-interoperable ACL facilities in IMAP, and IESG will have to sort out the mess. I don't think that this is a good outcome. Please, let's work together and stop this sniping. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLiXqt055355 for ; Wed, 20 Aug 2003 14:44:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLiXso055354 for ietf-imapext-bks; Wed, 20 Aug 2003 14:44:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLiVqt055340 for ; Wed, 20 Aug 2003 14:44:32 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7KLiW63016413; Wed, 20 Aug 2003 15:44:32 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Wed, 20 Aug 2003 15:44:31 -0600 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-imapext@imc.org To: Mark Crispin From: Lyndon Nerenberg {VE6BBM} In-Reply-To: Message-Id: <7B6BE881-D357-11D7-A887-000393D34A62@orthanc.ab.ca> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, August 20, 2003, at 03:23 PM, Mark Crispin wrote: > On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: >>> What TCP/IP-specific network support is there in IMAP? >> Please examine tcp_unix.c in the c-client source code. > > If you examine that code carefully, you will see that there is no > requirement that it be used. And ditto for POSIX ACLs. If you don't have them, you don't support ACL2. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLSeqt050169 for ; Wed, 20 Aug 2003 14:28:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLSeqa050168 for ietf-imapext-bks; Wed, 20 Aug 2003 14:28:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLSdqt050143 for ; Wed, 20 Aug 2003 14:28:39 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7KLSb4w021042; Wed, 20 Aug 2003 17:28:37 -0400 Date: Wed, 20 Aug 2003 17:28:37 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Lyndon Nerenberg {VE6BBM} , Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Mark Crispin wrote: > On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: > > Please remove all the network support from IMAP. IP networking not > > supported on versions of UNIX that pre-date the elitist 4.2BSD release. > > What TCP/IP-specific network support is there in IMAP? The KERBEROS_V4 SASL Mechanism described in RFC2222 (normative to 3501) requires IPv4 support. Of course, its perfectly possible to implement an IMAP server without support for the KERBEROS_V4 SASL mechanism. Its also perfectly possible to implement one without ACL[2] support. It should not be a requirement that all extentions of a protocol are implementable everywhere that the base protocol is implementable. It has been become clear that the ACL2 specification is made substantially more complex by the requirement that it be implemented on top of Unix filesystem permissions with tied rights. It is time to accept the fact that this may not be a reasonable requirement that can be satisfied in a simple and interoperable way. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLN3qt047998 for ; Wed, 20 Aug 2003 14:23:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLN3E5047997 for ietf-imapext-bks; Wed, 20 Aug 2003 14:23:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLN2qt047957 for ; Wed, 20 Aug 2003 14:23:02 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLMwCK017798; Wed, 20 Aug 2003 14:22:58 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLMw4A012186 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 14:22:58 -0700 Date: Wed, 20 Aug 2003 14:23:19 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lyndon Nerenberg {VE6BBM} cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: > > What TCP/IP-specific network support is there in IMAP? > Please examine tcp_unix.c in the c-client source code. If you examine that code carefully, you will see that there is no requirement that it be used. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLIkqt046336 for ; Wed, 20 Aug 2003 14:18:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLIknm046331 for ietf-imapext-bks; Wed, 20 Aug 2003 14:18:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLIiqt046311 for ; Wed, 20 Aug 2003 14:18:44 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7KLIi63016290; Wed, 20 Aug 2003 15:18:44 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Wed, 20 Aug 2003 15:18:43 -0600 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-imapext@imc.org To: Mark Crispin From: Lyndon Nerenberg {VE6BBM} In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > What TCP/IP-specific network support is there in IMAP? Please examine tcp_unix.c in the c-client source code. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KL7Tqt041844 for ; Wed, 20 Aug 2003 14:07:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KL7TP4041843 for ietf-imapext-bks; Wed, 20 Aug 2003 14:07:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KL7Rqt041802 for ; Wed, 20 Aug 2003 14:07:28 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KL7IgG018557; Wed, 20 Aug 2003 14:07:18 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KL7I4A010969 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 14:07:18 -0700 Date: Wed, 20 Aug 2003 14:07:40 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lyndon Nerenberg {VE6BBM} cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: > Please remove all the network support from IMAP. IP networking not > supported on versions of UNIX that pre-date the elitist 4.2BSD release. What TCP/IP-specific network support is there in IMAP? IMAP works quite well over non-TCP/IP links, or for that matter any link which provides a reliable stream. I've done IMAP over serial lines with a very basic checksum/retransmission protocol which was implemented in BASIC on an 8-bit micro. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKpFqt036572 for ; Wed, 20 Aug 2003 13:51:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KKpFrw036571 for ietf-imapext-bks; Wed, 20 Aug 2003 13:51:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKpDqt036565 for ; Wed, 20 Aug 2003 13:51:13 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7KKpA63016163; Wed, 20 Aug 2003 14:51:10 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Wed, 20 Aug 2003 14:51:09 -0600 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org To: Mark Crispin From: Lyndon Nerenberg {VE6BBM} In-Reply-To: Message-Id: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Some people believe in compatibility with the past. Others do not. Please remove all the network support from IMAP. IP networking not supported on versions of UNIX that pre-date the elitist 4.2BSD release. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKEkqt035256 for ; Wed, 20 Aug 2003 13:14:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KKEkEs035255 for ietf-imapext-bks; Wed, 20 Aug 2003 13:14:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKEjqt035249 for ; Wed, 20 Aug 2003 13:14:45 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KKEdCK006308; Wed, 20 Aug 2003 13:14:39 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KKEdXa015605 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 13:14:39 -0700 Date: Wed, 20 Aug 2003 13:15:00 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lyndon Nerenberg {VE6BBM} cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <46993FC6-D349-11D7-9BBA-000393D34A62@orthanc.ab.ca> Message-ID: References: <46993FC6-D349-11D7-9BBA-000393D34A62@orthanc.ab.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: > Which current versions of UNIX do not support POSIX ACLs? I really > don't think we have to think in the user/group/other paradigm any more. > This means sacrificing support for older UNIX variants. Oh well. The > future before us, not behind us. Some people believe in compatibility with the past. Others do not. I happen to believe in compatibility with the past, and as long as I am in any way associated with IMAP I will insist that IMAP do so. IMAP, like other Internet protocols, is not limited to elitist environments. Great effort went into the design of IMAP to support a wide variety of environments including 30 years' worth of legacy mail stores. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KK3Cqt034933 for ; Wed, 20 Aug 2003 13:03:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KK3BM8034932 for ietf-imapext-bks; Wed, 20 Aug 2003 13:03:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KK38qt034920 for ; Wed, 20 Aug 2003 13:03:10 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7KK2o63015963; Wed, 20 Aug 2003 14:02:50 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Wed, 20 Aug 2003 14:02:50 -0600 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org To: Mark Crispin From: Lyndon Nerenberg {VE6BBM} In-Reply-To: Message-Id: <46993FC6-D349-11D7-9BBA-000393D34A62@orthanc.ab.ca> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Please explain how a UNIX filesystem access control model is to > represent > ACL2 rights without tied rights. Which current versions of UNIX do not support POSIX ACLs? I really don't think we have to think in the user/group/other paradigm any more. This means sacrificing support for older UNIX variants. Oh well. The future before us, not behind us. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KJ7qqt032890 for ; Wed, 20 Aug 2003 12:07:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KJ7qPK032889 for ietf-imapext-bks; Wed, 20 Aug 2003 12:07:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KJ7oqt032873 for ; Wed, 20 Aug 2003 12:07:50 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 850565C896D9; Wed, 20 Aug 2003 22:07:41 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: Mark Crispin Cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1061406461.24980.86.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 20 Aug 2003 22:07:41 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-08-20 at 21:58, Mark Crispin wrote: > On Wed, 20 Aug 2003, Timo Sirainen wrote: > > - if there's conflicting rules in same level (eg. two groups), the less > > permissive rights always takes precedence > > But what about if the server gets a request that has such a conflict? What request? Like adding ACL for two groups with conflicting rights with each others? I don't think there's any problem with that. If there are users who belong to those two groups, it works like I said above. Server shouldn't prevent ACL changes just because it might happen to create conflicts. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIxLqt032670 for ; Wed, 20 Aug 2003 11:59:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KIxLMo032669 for ietf-imapext-bks; Wed, 20 Aug 2003 11:59:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIxKqt032663 for ; Wed, 20 Aug 2003 11:59:20 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KIx4oa022800; Wed, 20 Aug 2003 11:59:04 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KIwqXa010780 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 11:59:00 -0700 Date: Wed, 20 Aug 2003 11:58:48 -0700 (Pacific Daylight Time) From: Mark Crispin To: Timo Sirainen cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Timo Sirainen wrote: > - if there's conflicting rules in same level (eg. two groups), the less > permissive rights always takes precedence But what about if the server gets a request that has such a conflict? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIrBqt032458 for ; Wed, 20 Aug 2003 11:53:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KIrBFu032457 for ietf-imapext-bks; Wed, 20 Aug 2003 11:53:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIrAqt032451 for ; Wed, 20 Aug 2003 11:53:10 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KIqvCK025400; Wed, 20 Aug 2003 11:53:02 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KIqc4A002161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 11:52:50 -0700 Date: Wed, 20 Aug 2003 11:52:35 -0700 (Pacific Daylight Time) From: Mark Crispin To: Timo Sirainen cc: Alexey Melnikov , Barry Leiba , IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Timo Sirainen wrote: > The capability string is already getting annoyingly large and having > some extension give two capabilities makes it even worse. Why not just > make LIST-SUBSCRIBED behaviour required by LISTEXT itself? All servers > are able to implement that functionality and it most likely won't take > many lines of code. If LIST-SUBSCRIBED is to become mandatory to implement I would like to see some changes. In particular, it should be alright for LIST-SUBSCRIBED to be implemented as a LIST that shows only mailboxes that are in the LSUB subscription list. That distinction is important to me. LSUB can include names that would not show up in LIST. Consider # namespaces vs. *. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIXbqt031773 for ; Wed, 20 Aug 2003 11:33:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KIXbCO031771 for ietf-imapext-bks; Wed, 20 Aug 2003 11:33:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIXZqt031762 for ; Wed, 20 Aug 2003 11:33:35 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id A8BED238C6; Wed, 20 Aug 2003 21:33:31 +0300 (EEST) Received: from iki.fi (unknown [192.168.123.201]) by danu.procontrol.fi (Postfix) with ESMTP id 1F3E923896; Wed, 20 Aug 2003 21:33:30 +0300 (EEST) Date: Wed, 20 Aug 2003 21:33:41 +0300 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org To: Mark Crispin From: Timo Sirainen In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, Aug 20, 2003, at 20:31 Europe/Helsinki, Mark Crispin wrote: > One of the purposes of the ACL2 exercise it to make IMAP ACL > implementable > with the UNIX filesystem access control model. If ACL2 does not do > this, > then it will be a failure. IMHO rule identifiers are still it's biggest potential failure. I know I already hate them. And I don't think there really is a need for them. There really isn't need a for tied rights either, although they could help. All that really is needed is ability for servers to accurately describe to clients what the current access rights are. If client requests some change that server cannot perform exactly, it would do what it thinks is the best and return the new rights to client. Server should never grant anyone more permissions than what was requested by client. Tied rights are one way to prevent this, another way would be to give client a suggestion of what rights server would accept instead of the one it asked. That might give worse user interface, but it would be more flexible. Anyway, the single rule that I think should be able to describe all kinds of rights: - you have + and - rights - you get union of rights - more specific rules always overrides less specific rules if they have conflicting rights - if there's conflicting rules in same level (eg. two groups), the less permissive rights always takes precedence For example: -r---w-rw- 1 cras users 40013065 Jul 12 02:11 inbox "ACL" (("user=cras" "r-w") ("group=users" "w-r") ("anyone" "rw")) I don't remember the exact ACL equilevants to rw now, but the idea should work. Only problem with having only single rule is that client wouldn't have exact knowledge of how the server works, but it probably couldn't know it in any case, unix group changing as one example. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHvDqt029222 for ; Wed, 20 Aug 2003 10:57:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KHvDGG029221 for ietf-imapext-bks; Wed, 20 Aug 2003 10:57:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHvBqt029198 for ; Wed, 20 Aug 2003 10:57:11 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 7CCAA2399C; Wed, 20 Aug 2003 20:57:02 +0300 (EEST) Received: from iki.fi (unknown [192.168.123.201]) by danu.procontrol.fi (Postfix) with ESMTP id A3DA523996; Wed, 20 Aug 2003 20:57:00 +0300 (EEST) Date: Wed, 20 Aug 2003 20:57:12 +0300 Subject: Re: Last Calling the LISTEXT draft? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Alexey Melnikov , Barry Leiba , IMAP extensions Mailing List To: Mark Crispin From: Timo Sirainen In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, Aug 20, 2003, at 19:10 Europe/Helsinki, Mark Crispin wrote: > Alternatively, have no LIST-xxx of any type and only LISTEXT, and > depend > everything upon another extension. We have a MAILBOX-REFERRALS and (I > think) a CHILDREN extension. The only problem is LIST-SUBSCRIBED. The capability string is already getting annoyingly large and having some extension give two capabilities makes it even worse. Why not just make LIST-SUBSCRIBED behaviour required by LISTEXT itself? All servers are able to implement that functionality and it most likely won't take many lines of code. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHVHqt027565 for ; Wed, 20 Aug 2003 10:31:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KHVH9O027564 for ietf-imapext-bks; Wed, 20 Aug 2003 10:31:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHVEqt027559 for ; Wed, 20 Aug 2003 10:31:16 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KHV8xu001109; Wed, 20 Aug 2003 10:31:13 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KHV8Qh023895; Wed, 20 Aug 2003 10:31:08 -0700 Date: Wed, 20 Aug 2003 10:31:08 -0700 (PDT) From: Mark Crispin To: Larry Greenfield cc: Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F43A3F5.2080406@andrew.cmu.edu> Message-ID: References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> <3F435473.2000302@isode.com> <3F43A3F5.2080406@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Larry Greenfield wrote: > >> . Do we have any experience with servers that have tied rights with > >> the current ACL specification? > > I have no idea. Anybody? > If there is no experience, I would guess that this is a feature that no > client is going to be able to display correctly and comprehensibly and > it should be dropped. Please explain how a UNIX filesystem access control model is to represent ACL2 rights without tied rights. The only way that I can see this working is if a server is permitted to tie rights internally, and thus just magically change rights without announcing to the client how it works. I don't know how this magic should work if a request simultaneously asks to remove a right and to add a right that is tied to the removed right. Tied rights were presumably intended to prevent this. One of the purposes of the ACL2 exercise it to make IMAP ACL implementable with the UNIX filesystem access control model. If ACL2 does not do this, then it will be a failure. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHL7qt027173 for ; Wed, 20 Aug 2003 10:21:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KHL780027172 for ietf-imapext-bks; Wed, 20 Aug 2003 10:21:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHL6qt027163 for ; Wed, 20 Aug 2003 10:21:06 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KHKsin018111; Wed, 20 Aug 2003 10:20:59 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KHKsVm022955; Wed, 20 Aug 2003 10:20:54 -0700 Date: Wed, 20 Aug 2003 10:20:54 -0700 (PDT) From: Mark Crispin To: Larry Greenfield cc: Steve Hole , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F43A2E7.409@andrew.cmu.edu> Message-ID: References: <3F435473.2000302@isode.com> <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> <3F43A2E7.409@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Larry Greenfield wrote: > We should be designing protocols to have simple, analogous rules, not > "oh, in this circumstance only X is allowed, but in this circumstance > only Y". > > I strongly disagree with confining ACLs to "quoted". FWIW, I agree with Larry here. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGtDqt025780 for ; Wed, 20 Aug 2003 09:55:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGtDOB025779 for ietf-imapext-bks; Wed, 20 Aug 2003 09:55:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGtCqt025772 for ; Wed, 20 Aug 2003 09:55:12 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7KGx0V28504; Wed, 20 Aug 2003 10:59:00 -0600 Message-ID: <3F43A7EA.8090008@isode.com> Date: Wed, 20 Aug 2003 17:55:06 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Larry Greenfield CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> <3F435473.2000302@isode.com> <3F43A3F5.2080406@andrew.cmu.edu> In-Reply-To: <3F43A3F5.2080406@andrew.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Larry Greenfield wrote: > Alexey Melnikov wrote: > >> [Sorry, it took me ages to write a full reply to this message.] >> >> Lawrence Greenfield wrote: >> >>> . Why is there no 'anonymous' identifier in addition to 'anyone' and >>> 'authuser'? >> >> >> I've just added "anonymous" as a synonym for "anyone" (actually the >> other way around). Any objections to this? > > > "anonymous" is defined in the current draft as only the anonymous > user. It does not include all users. the current is draft-ietf-imapext-acl-09.txt, section 3.1 a). "anonymous" - special group that refers to the universal identity (all authentications, including anonymous). A special identifier "anyone" is a synonym for the "anonymous". Is this what you want? >>> . Do we have any experience with servers that have tied rights with >>> the current ACL specification? >>> >> I have no idea. Anybody? > > > If there is no experience, I would guess that this is a feature that > no client is going to be able to display correctly and comprehensibly > and it should be dropped. Mark will probably use this. I am not going to do any changes unless I hear more opinions. >> Now, does anybody has an argument for allowing rights to be >> represented as literals? >> If the working group thinks that, I will change the document. >> >>> How a string is sent is a lexical issue. Where strings are allowed is >>> a grammar issue. It's unfortunate that we specify both levels in a >>> single ABNF, but that's no reason to allow the two levels to mix. >> > > You helpfully quoted my argument right below your question. It was > correct when I wrote it and it's still correct now. And BINARY allows for 8bit data only in certain places. I am sorry, but I just fail to see this as a big deal. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGcKqt025058 for ; Wed, 20 Aug 2003 09:38:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGcK0Q025057 for ietf-imapext-bks; Wed, 20 Aug 2003 09:38:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGcJqt025049 for ; Wed, 20 Aug 2003 09:38:19 -0700 (PDT) (envelope-from leg@andrew.cmu.edu) Received: from mirapoint.corp.google.com (IDENT:mirapoint@mirapoint.corp.google.com [10.32.0.80]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h7KGcG3d020335; Wed, 20 Aug 2003 09:38:16 -0700 Received: from andrew.cmu.edu (dunbar.corp.google.com [10.2.2.110]) by mirapoint.corp.google.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACN53924 (AUTH leg); Wed, 20 Aug 2003 09:38:14 -0700 (PDT) Message-ID: <3F43A3F5.2080406@andrew.cmu.edu> Date: Wed, 20 Aug 2003 12:38:13 -0400 From: Larry Greenfield User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexey Melnikov CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> <3F435473.2000302@isode.com> In-Reply-To: <3F435473.2000302@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > [Sorry, it took me ages to write a full reply to this message.] > > Lawrence Greenfield wrote: > >> . Why is there no 'anonymous' identifier in addition to 'anyone' and >> 'authuser'? > > I've just added "anonymous" as a synonym for "anyone" (actually the > other way around). Any objections to this? "anonymous" is defined in the current draft as only the anonymous user. It does not include all users. >> . Do we have any experience with servers that have tied rights with >> the current ACL specification? >> > I have no idea. Anybody? If there is no experience, I would guess that this is a feature that no client is going to be able to display correctly and comprehensibly and it should be dropped. > Now, does anybody has an argument for allowing rights to be represented > as literals? > If the working group thinks that, I will change the document. > >> How a string is sent is a lexical issue. Where strings are allowed is >> a grammar issue. It's unfortunate that we specify both levels in a >> single ABNF, but that's no reason to allow the two levels to mix. You helpfully quoted my argument right below your question. It was correct when I wrote it and it's still correct now. Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGXpqt024931 for ; Wed, 20 Aug 2003 09:33:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGXpB8024930 for ietf-imapext-bks; Wed, 20 Aug 2003 09:33:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGXoqt024924 for ; Wed, 20 Aug 2003 09:33:50 -0700 (PDT) (envelope-from leg@andrew.cmu.edu) Received: from mirapoint.corp.google.com (IDENT:mirapoint@mirapoint.corp.google.com [10.32.0.80]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h7KGXk3d017743; Wed, 20 Aug 2003 09:33:46 -0700 Received: from andrew.cmu.edu (dunbar.corp.google.com [10.2.2.110]) by mirapoint.corp.google.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACN53462 (AUTH leg); Wed, 20 Aug 2003 09:33:44 -0700 (PDT) Message-ID: <3F43A2E7.409@andrew.cmu.edu> Date: Wed, 20 Aug 2003 12:33:43 -0400 From: Larry Greenfield User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Hole CC: Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <3F435473.2000302@isode.com> <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hole wrote: >>>. The ABNF rule "rights = quoted" is unacceptable. We want to >>>encourage the use of literals, not create more special cases in the >>>protocol where only a subset of string representations are >>>allowed. It's not clear to me why this change was made. >> >>Now, does anybody has an argument for allowing rights to be represented >>as literals? >>If the working group thinks that, I will change the document. > > > I can see no good reason why the rights string should be a literal > The set of characters that can legally be placed in the string is > restricted and can never included anything outside of that character > set. > > Even though I (of course) understand Alexey's issue on the difficulty > of parsing literals in an asynchronous processor, I really wouldn't > consider that to be a good enough reason to reject a literal syntax. > The real issue is that this is a string of a fixed set of ascii > characters. Anything outside that set is illegal. There is no > reason to invoke the complexity of a literal string parse in that > instance. Intermingling lexical and syntactic levels of a protocol increases complexity. It is not simplifying. The more special cases the harder it is to get things right. How many clients refuse to parse literals in certain places, even though they're allowed? This mistake is made because the examples don't show literals where they're allowed and the ABNF is already extremely confusing. We should be designing protocols to have simple, analogous rules, not "oh, in this circumstance only X is allowed, but in this circumstance only Y". I strongly disagree with confining ACLs to "quoted". Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGVqqt024861 for ; Wed, 20 Aug 2003 09:31:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGVqEl024860 for ietf-imapext-bks; Wed, 20 Aug 2003 09:31:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGVpqt024855 for ; Wed, 20 Aug 2003 09:31:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7KGZbV24463; Wed, 20 Aug 2003 10:35:37 -0600 Message-ID: <3F43A26E.2090708@isode.com> Date: Wed, 20 Aug 2003 17:31:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Barry Leiba , IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? References: <3F420A9B.40406@isode.com> <004701c3668b$9200d040$40280209@watson.ibm.com> <3F4358A4.7060008@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >On Wed, 20 Aug 2003, Alexey Melnikov wrote: > > >>However we need to keep LISTEXT as a capability name. Many extensions >>will depend on LISTEXT framework, but will not be named LIST-. >> >> > >I'm saying that they should. Otherwise, we will having magic behaviors >that inevitably will be misimplemented. People can't even get the IMAP >base spec right; what makes you think that they'll realize that LISTEXT >plus ACL2 implies LIST-ACL2? > No, ACL2 requires LISTEXT support. And ACL2 has own naming scheme already. I don't want to report LIST-ACL2=UNION. >I certainly understand the motivation, and in a perfect world it's >undeniably better. But we live in a very imperfect world. > >>A good example is ACL2, which defines its own capability prefix. >>A client should have an easy way of knowing if extended LIST syntax is >>supported by the server. >> >> > >Why not LIST-ACL2? > >Alternatively, have no LIST-xxx of any type and only LISTEXT, and depend >everything upon another extension. We have a MAILBOX-REFERRALS and (I >think) a CHILDREN extension. The only problem is LIST-SUBSCRIBED. > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGAYqt024044 for ; Wed, 20 Aug 2003 09:10:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGAYv7024043 for ietf-imapext-bks; Wed, 20 Aug 2003 09:10:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGAXqt024020 for ; Wed, 20 Aug 2003 09:10:33 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KGANgG031207; Wed, 20 Aug 2003 09:10:28 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KGAMpx019272; Wed, 20 Aug 2003 09:10:22 -0700 Date: Wed, 20 Aug 2003 09:10:22 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov cc: Barry Leiba , IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? In-Reply-To: <3F4358A4.7060008@isode.com> Message-ID: References: <3F420A9B.40406@isode.com> <004701c3668b$9200d040$40280209@watson.ibm.com> <3F4358A4.7060008@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Alexey Melnikov wrote: > However we need to keep LISTEXT as a capability name. Many extensions > will depend on LISTEXT framework, but will not be named LIST-. I'm saying that they should. Otherwise, we will having magic behaviors that inevitably will be misimplemented. People can't even get the IMAP base spec right; what makes you think that they'll realize that LISTEXT plus ACL2 implies LIST-ACL2? I certainly understand the motivation, and in a perfect world it's undeniably better. But we live in a very imperfect world. > A good example is ACL2, which defines its own capability prefix. > A client should have an easy way of knowing if extended LIST syntax is > supported by the server. Why not LIST-ACL2? Alternatively, have no LIST-xxx of any type and only LISTEXT, and depend everything upon another extension. We have a MAILBOX-REFERRALS and (I think) a CHILDREN extension. The only problem is LIST-SUBSCRIBED. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KEspqt019566 for ; Wed, 20 Aug 2003 07:54:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KEsn5O019563 for ietf-imapext-bks; Wed, 20 Aug 2003 07:54:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KEshqt019550 for ; Wed, 20 Aug 2003 07:54:43 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7KEwSV11005; Wed, 20 Aug 2003 08:58:28 -0600 From: Steve Hole Date: Wed, 20 Aug 2003 08:58:28 -0700 To: Alexey Melnikov Subject: Re: acl-08: questions Cc: Lawrence Greenfield , ietf-imapext@imc.org In-Reply-To: <3F435473.2000302@isode.com> References: <3F435473.2000302@isode.com> <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7KEshqt019554 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003 11:58:59 +0100 Alexey Melnikov wrote: > > . The ABNF rule "rights = quoted" is unacceptable. We want to > > encourage the use of literals, not create more special cases in the > > protocol where only a subset of string representations are > > allowed. It's not clear to me why this change was made. > > Now, does anybody has an argument for allowing rights to be represented > as literals? > If the working group thinks that, I will change the document. I can see no good reason why the rights string should be a literal. The set of characters that can legally be placed in the string is restricted and can never included anything outside of that character set. Even though I (of course) understand Alexey's issue on the difficulty of parsing literals in an asynchronous processor, I really wouldn't consider that to be a good enough reason to reject a literal syntax. The real issue is that this is a string of a fixed set of ascii characters. Anything outside that set is illegal. There is no reason to invoke the complexity of a literal string parse in that instance. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KBGwqt003332 for ; Wed, 20 Aug 2003 04:16:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KBGwZj003331 for ietf-imapext-bks; Wed, 20 Aug 2003 04:16:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KBGvqt003326 for ; Wed, 20 Aug 2003 04:16:57 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7KBKhV21486; Wed, 20 Aug 2003 05:20:43 -0600 Message-ID: <3F4358A4.7060008@isode.com> Date: Wed, 20 Aug 2003 12:16:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Barry Leiba , IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? References: <3F420A9B.40406@isode.com> <004701c3668b$9200d040$40280209@watson.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >The ways in which the three LISTEXT options are available or not available >is ugly. SUBSCRIBED doesn't have to be implemented unless the server also >advertises LIST-SUBSCRIBED; REMOTE doesn't have to be implemented unless >the server also advertises MAILBOX-REFERRALS; CHILDREN doesn't have to be >implemented as long as it's ignored. > >Suggest that there be a capability for each LISTEXT option now and in the >future, and get rid of the LISTEXT capability. In other words, > LIST-SUBSCRIBED LIST-REMOTE LIST-CHILDREN >for a "full server". > > And most clients should be able to cope with \PlaceHolder anyway. I tend to agree with Mark on separating the base LISTEXT framework from LISTEXT extensions. However we need to keep LISTEXT as a capability name. Many extensions will depend on LISTEXT framework, but will not be named LIST-. A good example is ACL2, which defines its own capability prefix. A client should have an easy way of knowing if extended LIST syntax is supported by the server. >Reference is made to ACL for "extended set", but nothing about this >elsewhere in the document. Suggest either saying "for a possible future >LIST-ACL extension" or replacing with obviously bogus sample data, e.g.: > > (("tablecloth" (("fringe" "lacy")("color" "white")))("X-Sample" > "text")) > or... > (("tablecloth" ("fringe" "lacy"))("X-Sample" "text")) > I would prefer the latter, as this doesn't cause a confusion with ACL2. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KAx8qt002525 for ; Wed, 20 Aug 2003 03:59:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KAx8kq002524 for ietf-imapext-bks; Wed, 20 Aug 2003 03:59:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KAx3qt002519 for ; Wed, 20 Aug 2003 03:59:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7KB2oV19599; Wed, 20 Aug 2003 05:02:50 -0600 Message-ID: <3F435473.2000302@isode.com> Date: Wed, 20 Aug 2003 11:58:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lawrence Greenfield CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> In-Reply-To: <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Sorry, it took me ages to write a full reply to this message.] Lawrence Greenfield wrote: > . Why is there no 'anonymous' identifier in addition to 'anyone' and > 'authuser'? I've just added "anonymous" as a synonym for "anyone" (actually the other way around). Any objections to this? > . Do we have any experience with servers that have tied rights with > the current ACL specification? > I have no idea. Anybody? > . I don't follow how ACL2=MOST-SPECIFIC works. When there are two > groups, which is more specific? What about "authuser" versus a group > that might contain "anonymous"? > > There needs to be a formal definition of how to order two rules. > I've changed the definition of ACL to be an "ordered list" instead of a "set". All entries are added to the end (unless they replace another member). This should have no effect on ACL2=UNION. To answer your question about "authuser" versa a group containing "anonymous". "authuser" is just a special group. If it is listed before the group containing "anonymous", it will be used. > . The ABNF rule "rights = quoted" is unacceptable. We want to > encourage the use of literals, not create more special cases in the > protocol where only a subset of string representations are > allowed. It's not clear to me why this change was made. I think I've expressed my opinion on this before, but I will try to write an extended answer that should clarify my position. 1). Speaking as a server implementor, I have to say that parsing literals (excluding non-synchronizing one) in a multithreaded server that uses asynchronous or non-blocking IO is a major headache. This is caused by the fact that the data is not following "}" immediately. Our non-blocking parser works the following way: a simple high level parser reads character until it sees CR LF pair. After that it calls the lower level parser that understand details of IMAP. Each time there is a literal, you have to save the current state, which adds to code complexity. Sure, this is my implementation. There are other, probably better ways of achieving this in a multithreaded environment. 2). ACL rights consist of a set of characters that denote rights. There is no need to i18ze them. There should be never any reason for this. Control and other weird characters are not allowed. In my client I emit literals only if there are characters that are not allowed in a quoted string. So, I think that quoted strings are easier for certain servers and there is no much burden (if at all) for clients. And we don't need 8bit characters in "rights". Now, does anybody has an argument for allowing rights to be represented as literals? If the working group thinks that, I will change the document. > How a string is sent is a lexical issue. Where strings are allowed is > a grammar issue. It's unfortunate that we specify both levels in a > single ABNF, but that's no reason to allow the two levels to mix. > > Larry > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K2BGqt048842 for ; Tue, 19 Aug 2003 19:11:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7K2BGxw048841 for ietf-imapext-bks; Tue, 19 Aug 2003 19:11:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K2BAqt048834 for ; Tue, 19 Aug 2003 19:11:10 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7K2B1oa011497; Tue, 19 Aug 2003 19:11:06 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7K2B1Xa012682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Aug 2003 19:11:01 -0700 Date: Tue, 19 Aug 2003 19:11:22 -0700 (Pacific Daylight Time) From: Mark Crispin To: Barry Leiba cc: Alexey Melnikov , IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? In-Reply-To: <004701c3668b$9200d040$40280209@watson.ibm.com> Message-ID: References: <3F420A9B.40406@isode.com> <004701c3668b$9200d040$40280209@watson.ibm.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The ways in which the three LISTEXT options are available or not available is ugly. SUBSCRIBED doesn't have to be implemented unless the server also advertises LIST-SUBSCRIBED; REMOTE doesn't have to be implemented unless the server also advertises MAILBOX-REFERRALS; CHILDREN doesn't have to be implemented as long as it's ignored. Suggest that there be a capability for each LISTEXT option now and in the future, and get rid of the LISTEXT capability. In other words, LIST-SUBSCRIBED LIST-REMOTE LIST-CHILDREN for a "full server". Reference is made to ACL for "extended set", but nothing about this elsewhere in the document. Suggest either saying "for a possible future LIST-ACL extension" or replacing with obviously bogus sample data, e.g.: (("tablecloth" (("fringe" "lacy")("color" "white")))("X-Sample" "text")) or... (("tablecloth" ("fringe" "lacy"))("X-Sample" "text")) -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJtjqt021145 for ; Tue, 19 Aug 2003 12:55:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JJtjU3021144 for ietf-imapext-bks; Tue, 19 Aug 2003 12:55:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJtjqt021139 for ; Tue, 19 Aug 2003 12:55:45 -0700 (PDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 019AE206608 for ; Tue, 19 Aug 2003 15:54:08 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19pCG2-0003CJ-7F for ietf-announce-list@asgard.ietf.org; Tue, 19 Aug 2003 15:35:06 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19pCFy-0003AR-CJ for all-ietf@asgard.ietf.org; Tue, 19 Aug 2003 15:35:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03693; Tue, 19 Aug 2003 15:34:56 -0400 (EDT) Message-Id: <200308191934.PAA03693@ietf.org> To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-acl-09.txt Date: Tue, 19 Aug 2003 15:34:56 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+76459_15913104021353_48263776221" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --MIMEStream=_0+76459_15913104021353_48263776221 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 ACL extension Author(s) : A. Melnikov Filename : draft-ietf-imapext-acl-09.txt Pages : 10 Date : 2003-8-19 The ACL (Access Control List) extension of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-acl-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-acl-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+76459_15913104021353_48263776221 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+173044_765583334319_329585914397" --MIMEStream=_1+173044_765583334319_329585914397 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19155045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-acl-09.txt --MIMEStream=_1+173044_765583334319_329585914397 Content-Type: Message/External-body; name="draft-ietf-imapext-acl-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19155045.I-D@ietf.org> --MIMEStream=_1+173044_765583334319_329585914397-- --MIMEStream=_0+76459_15913104021353_48263776221-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJrfqt021057 for ; Tue, 19 Aug 2003 12:53:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JJrefZ021056 for ietf-imapext-bks; Tue, 19 Aug 2003 12:53:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJrbqt021051 for ; Tue, 19 Aug 2003 12:53:38 -0700 (PDT) (envelope-from leiba@watson.ibm.com) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [9.2.112.58]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h7JJpGj117158; Tue, 19 Aug 2003 15:51:16 -0400 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7/8.11.7) with SMTP id h7JJrXQ34530; Tue, 19 Aug 2003 15:53:33 -0400 Message-ID: <004701c3668b$9200d040$40280209@watson.ibm.com> From: "Barry Leiba" To: "Alexey Melnikov" Cc: "IMAP extensions Mailing List" References: <3F420A9B.40406@isode.com> Subject: Re: Last Calling the LISTEXT draft? Date: Tue, 19 Aug 2003 15:53:32 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0044_01C3666A.0A9BB910" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C3666A.0A9BB910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Can we Last Call the LISTEXT document? It is pretty stable for a while now. Yeah, the reason I re-posted it with the last set of minor (very minor) changes was to get it put in for last call, at Pete's request. So, Pete, are we requesting last call? > Except for horrible formatting ;-), I don't have any issues with it. The formatting is puzzling me; is it me, or is it the I-D editor? This didn't used to happen, but the last couple of submissions I've made have had that formatting problem. I checked this before I sent it. I'm attaching the text file here -- someone tell me what the problem is, please, so I can stop it from happening the next time. Barry -- Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba ------=_NextPart_000_0044_01C3666A.0A9BB910 Content-Type: text/plain; name="draft-ietf-imapext-list-extensions-04.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-imapext-list-extensions-04.txt" =0A= =0A= IMAP Extensions Working Group B. Leiba Internet Draft IBM T.J. Watson Research Center Document: draft-ietf-imapext-list-extensions-04.txt August 2003 Expires January 2004 IMAP4 LIST Command Extensions =0A= Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. A revised version of this draft document will be submitted to the RFC editor as an Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to ietf-imapext@imc.org. This document will expire before 31 January 2004. Distribution of this memo is unlimited. =0A= 1. Abstract IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. =0A= B. Leiba Expires January 2004 [Page = 1]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= =0A= 2. Conventions used in this document In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client. The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in this document as specified in RFC 2119 [Keywords]. =0A= 3. Introduction The extensions to the LIST command will be accomplished by amending the syntax to allow options to be specified. The list of options will replace the several commands that are currently used to mix and match the information requested. The new syntax is backward- compatible, with no ambiguity: if the first word after the command name begins with a parenthesis, the new syntax is being used; if it does not, it's in the original syntax. By adding options to the LIST command, we are announcing the intent to phase out and eventually to deprecate the RLIST and RLSUB commands described in [MboxRefer]. We are also defining the mechanism to request extended mailbox information, such as is described in the now-expired "Child Mailbox Extension" draft [ChildMbox]. The base LSUB command is not deprecated by this extension; rather, this extension adds a way to obtain subscription information with more options, with those server implementations that support it. Clients that simply need a list of subscribed mailboxes, as provided by the LSUB command, SHOULD continue to use that command. =0A= 4. LIST Command Options The LIST command syntax is extended by adding a parenthesized list of command options between the command name and the reference name (see the formal syntax in section 6 for specific details). Command options will be defined in this document and in approved extension documents; each option will be enabled by a capability string (one capability may enable multiple options), and a client MUST NOT send an option for which the server has not advertised support. A server MUST respond to options it does not recognize with a NO response. This extension is identified by the capability string "LISTEXT", and support for it is a prerequisite for any future extensions that require specialized forms of the LIST command. Such extensions MUST refer to this document and MUST add their function through command options as described herein. This document also defines the "LIST- =0A= B. Leiba Expires January 2004 [Page = 2]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= SUBSCRIBED" capability string; see the "SUBSCRIBED" option below. This extension also defines extensions to the LIST response, allowing a series of extended fields at the end, a parenthesized list of attriobute/value pairs. Each attribute is a string, each value may be a string or a nested parenthesized list of the same attribute/value pairs. An example of this extended set might be (("ACL" (("id" "user=3Dfred")("rights" "rwi")))("X-Sample" "text")) or... (("ACL" ("user=3Dfred" "rwi"))("X-Sample" "text")) See the formal grammar, below, for the full syntatic details. The options defined in this specification are SUBSCRIBED - causes the LIST command to list subscribed mailboxes, rather than the actual mailboxes. This will often be a subset of the actual mailboxes. It's also possible for this list to contain the names of mailboxes that don't exist. In any case, the list MUST include exactly those mailbox names that match the selection criteria and are subscribed to. This option is intended to supplement the LSUB command, and support for it is optional -- a server that supports the SUBSCRIBED option indicates so through the LIST-SUBSCRIBED capability. Of particular note are the mailbox flags as returned by this option, compared with what is returned by LSUB. With the latter, the flags returned may not reflect the actual flag status on the mailbox, and the \NoSelect flag has a special meaning (it indicates that this mailbox is not, itself, subscribed, but that it has child mailboxes that are). With the SUBSCRIBED option described here, the flags are accurate and complete, and have no special meanings. "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, and some servers must do significant extra work to respond to "LIST (SUBSCRIBED)". Because of this, clients SHOULD continue to use "LSUB" unless they specifically want the additional information offered by "LIST (SUBSCRIBED)". At the same time, servers SHOULD support the LIST-SUBSCRIBED capability even if it entails extra work, because a client that wants the information will still obtain it by using LSUB followed by a series of LIST commands, so servers might as well make it easier. This option defines a new mailbox flag, "\NonExistent", that indicates that a mailbox is subscribed to, but does not actually exist. The "\NonExistent" flag MUST be supported and MUST be accurately computed. =0A= B. Leiba Expires January 2004 [Page = 3]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= REMOTE - causes the LIST command to show remote mailboxes as well as local ones, as described in [MboxRefer]. This option is intended to replace the RLIST command and, in conjunction with the SUBSCRIBED option, the RLSUB command. This option is only available on servers that also support RFC-2193. CHILDREN - Requests mailbox child information as originally proposed in [ChildMbox]. See section 5, below, for details. Support for this is optional, but this option MUST be accepted by all servers (though it MAY be ignored). The LISTEXT capability also defines a new mailbox flag, "\PlaceHolder", that indicates that the designated mailbox does not meet the selection criteria of the given LIST command, but that it has one or more child mailboxes that do [EDITORIAL NOTE: "might"?]. The LSUB command indicates this condition by using the "\NoSelect" flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since "\NoSelect" retains its original meaning here. Further, the "\PlaceHolder" flag is more general, in that it can be used with any extended set of selection criteria. =0A= 5. The CHILDREN Option The CHILDREN option implements the Child Mailbox Extension, originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft Corporation. Most of the information in this section is taken directly from their original specification [ChildMbox]. The CHILDREN option is simply an indication that the client wants this information; a server MAY provide it even if the option is not specified, or MAY ignore the option entirely. Many IMAP4 [IMAP4] clients present to the user a hierarchical view of the mailboxes that a user has access to. Rather than initially presenting to the user the entire mailbox hierarchy, it is often preferable to show to the user a collapsed outline list of the mailbox hierarchy (particularly if there is a large number of mailboxes). The user can then expand the collapsed outline hierarchy as needed. It is common to include within the collapsed hierarchy a visual clue (such as a ''+'') to indicate that there are child mailboxes under a particular mailbox. When the visual clue is clicked the hierarchy list is expanded to show the child mailboxes. The Child Mailbox Extension provides a mechanism for a client to efficiently determine if a particular mailbox has children, without issuing a LIST '' * or a LIST '' % for each mailbox name. The Child Mailbox Extension defines two new attributes that MAY be =0A= B. Leiba Expires January 2004 [Page = 4]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= returned within a LIST response: \HasChildren and \HasNoChildren. While these attributes MAY be returned in response to any LIST command, the CHILDREN option is provided to indicate that the client particularly wants this information. If the CHILDREN option is present, the server SHOULD return these attributes even if their computation is expensive. \HasChildren - The presence of this attribute indicates that the mailbox has child mailboxes. A server SHOULD NOT set this attribute if there are child mailboxes, and the user does not have permissions to access any of them. In this case, \HasNoChildren SHOULD be used. In many cases, however, a server may not be able to efficiently compute whether a user has access to all child mailboxes. As such a client MUST be prepared to accept the \HasChildren attribute as a hint. That is, a mailbox MAY be flagged with the \HasChildren attribute, but no child mailboxes will appear in the LIST response. \HasNoChildren - The presence of this attribute indicates that the mailbox has NO child mailboxes that are accessible to the currently authenticated user. In some instances a server that supports the Child Mailbox Extension might not be able to determine whether a mailbox has children. For example it may have difficulty determining whether there are child mailboxes when LISTing mailboxes while operating in a particular namespace. In these cases, a server MAY exclude both the \HasChildren and \HasNoChildren attributes in the LIST response. As such, a client can not make any assumptions about whether a mailbox has children based upon the absence of a single attribute. In particular, some servers may not be able to combine the SUBSCRIBED and CHILDREN options. Such servers MUST honour the SUBSCRIBED option, and they will simply ignore the CHILDREN option if both are requested. It is an error for the server to return both a \HasChildren and a \HasNoChildren attribute in a LIST response. Note: the \HasNoChildren attribute should not be confused with the IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no child mailboxes exist now and none can be created in the future. =0A= 6. Examples =0A= =0A= B. Leiba Expires January 2004 [Page = 5]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= The first example shows the complete local hierarchy that will be used for the other examples. C: A01 LIST "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Apple" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: A01 OK done In the next example, we'll see the subscribed mailboxes. This is similar, but not equivalent, to . Note that the mailbox called "Fruit/Peach" is subscribed to, but does not actually exist (perhaps it was deleted while still subscribed). And the "Fruit" mailbox is not subscribed to, but it has two subscribed children. C: A02 LIST (SUBSCRIBED) "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\PlaceHolder) "/" "Fruit" S: * LIST () "/" "Fruit/Banana" S: * LIST (\NonExistent) "/" "Fruit/Peach" S: A02 OK done The next example shows the use of the CHILDREN option. The client, without having to list the second level of hierarchy, now knows which of the top-level mailboxes have sub-mailboxes (children) and which do not. Note that it's not necessary for the server to return the \HasNoChildren flag for the inbox, because the \NoInferiors flag already implies that, and has a stronger meaning. C: A03 LIST (CHILDREN) "" "%" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\HasChildren) "/" "Fruit" S: * LIST (\HasNoChildren) "/" "Tofu" S: * LIST (\HasChildren) "/" "Vegetable" S: A03 OK done In this example we see more mailboxes, which reside on another server to which we may obtain referrals. This is similar to the command . We also see the mixing of two options. Note that in the case of the remote mailboxes, the server might or might not be able to include CHILDREN information; it includes it if it can, and omits it if it can't. C: A04 LIST (REMOTE CHILDREN) "" "%" S: * LIST (\Marked \NoInferiors) "/" "inbox" =0A= B. Leiba Expires January 2004 [Page = 6]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= S: * LIST (\HasChildren) "/" "Fruit" S: * LIST (\HasNoChildren) "/" "Tofu" S: * LIST (\HasChildren) "/" "Vegetable" S: * LIST () "/" "Bread" S: * LIST (\HasChildren) "/" "Meat" S: A04 OK done =0A= 7. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in [ABNF]. Terms not defined here are taken from [IMAP4]. child-mbox-flag =3D "\HasChildren" / "\HasNoChildren" ; flags for Child Mailbox Extension, at most one ; possible per LIST response list =3D "LIST" [SP list-options] SP mailbox SP = list-mailbox list-options =3D "(" [option *(SP option)] ")" mailbox-list =3D "(" [mbx-list-flags] ")" SP (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox [SP mbox-list-extended] mbox-list-extended =3D "(" [mbox-list-extended-item *(SP mbox-list-extended-item)] ")" mbox-list-extended-item =3D "(" string SP (nstring / mbox-list- extended-item) ")" / mailbox-list-extended mbox-list-oflag :=3D child-mbox-flag / "\NonExistent" / = "\PlaceHolder" option =3D "SUBSCRIBED" / "CHILDREN" / "REMOTE" / option-extension option-extension =3D atom =0A= 8. Security Considerations This document describes syntactic changes to the specification of the IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST command has the same security considerations as those commands. They are described in [IMAP4] and [MboxRefer]. The Child Mailbox Extension provides a client a more efficient means =0A= B. Leiba Expires January 2004 [Page = 7]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= of determining whether a particular mailbox has children. If a mailbox has children, but the currently authenticated user does not have access to any of them, the server SHOULD respond with a \HasNoChildren attribute. In many cases, however, a server may not be able to efficiently compute whether a user has access to all child mailboxes. If such a server responds with a \HasChildren attribute, when in fact the currently authenticated user does not have access to any child mailboxes, potentially more information is conveyed about the mailbox than intended. In most situations this will not be a security concern, because if information regarding whether a mailbox has children is considered sensitive, a user would not be granted access to that mailbox in the first place. =0A= 9. References [IMAP4]; Crispin, M.; "Internet Message Access Protocol - Version 4rev1"; RFC 2060; University of Washington; December 1996. [MboxRefer]; Gahrns, M.; "IMAP4 Mailbox Referrals"; RFC 2193; Microsoft Corporation; September 1997. [ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox Extension"; RFC 3348; Microsoft Corporation; July 2002. [Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate Requirement Levels"; RFC 2119; Harvard University; March 1997. [ABNF]; Crocker, D., and Overell, P. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. =0A= 10. Acknowledgements Mike Gahrns and Raymond Cheng of Microsoft Corporation originally devised the Child Mailbox Extension and proposed it in 1997; the idea, as well as most of the text in section 5, is theirs. =0A= 11. Author's Address Barry Leiba IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10532 Phone: 1-914-784-7941 Email: leiba@watson.ibm.com =0A= =0A= B. Leiba Expires January 2004 [Page 8] ------=_NextPart_000_0044_01C3666A.0A9BB910-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJZ0qt019871 for ; Tue, 19 Aug 2003 12:35:00 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JJZ0mC019870 for ietf-imapext-bks; Tue, 19 Aug 2003 12:35:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJYxqt019861 for ; Tue, 19 Aug 2003 12:34:59 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03693; Tue, 19 Aug 2003 15:34:56 -0400 (EDT) Message-Id: <200308191934.PAA03693@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-acl-09.txt Date: Tue, 19 Aug 2003 15:34:56 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 ACL extension Author(s) : A. Melnikov Filename : draft-ietf-imapext-acl-09.txt Pages : 10 Date : 2003-8-19 The ACL (Access Control List) extension of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-acl-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-acl-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19155045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-acl-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-acl-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19155045.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JBVmqt085991 for ; Tue, 19 Aug 2003 04:31:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JBVmc2085990 for ietf-imapext-bks; Tue, 19 Aug 2003 04:31:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JBVfqt085984 for ; Tue, 19 Aug 2003 04:31:48 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7JBZUV20655; Tue, 19 Aug 2003 05:35:30 -0600 Message-ID: <3F420A9B.40406@isode.com> Date: Tue, 19 Aug 2003 12:31:39 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Last Calling the LISTEXT draft? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Can we Last Call the LISTEXT document? It is pretty stable for a while now. Except for horrible formatting ;-), I don't have any issues with it. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76FFIqt026626 for ; Wed, 6 Aug 2003 08:15:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h76FFIlB026625 for ietf-imapext-bks; Wed, 6 Aug 2003 08:15:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76FFHqt026615 for ; Wed, 6 Aug 2003 08:15:17 -0700 (PDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id CD32C206606 for ; Wed, 6 Aug 2003 11:13:38 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19kPWq-0004qp-UD for ietf-announce-list@asgard.ietf.org; Wed, 06 Aug 2003 10:44:40 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19kPTG-0004p0-UK for all-ietf@asgard.ietf.org; Wed, 06 Aug 2003 10:40:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18934; Wed, 6 Aug 2003 10:40:50 -0400 (EDT) Message-Id: <200308061440.KAA18934@ietf.org> To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-list-extensions-04.txt Date: Wed, 06 Aug 2003 10:40:50 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+217736_4370862858773_64755974508" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --MIMEStream=_0+217736_4370862858773_64755974508 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 LIST Command Extensions Author(s) : B. Leiba Filename : draft-ietf-imapext-list-extensions-04.txt Pages : 8 Date : 2003-8-6 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-list-extensions-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-list-extensions-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+217736_4370862858773_64755974508 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+56004_97273797717805_2791792793" --MIMEStream=_1+56004_97273797717805_2791792793 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-6095941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-04.txt --MIMEStream=_1+56004_97273797717805_2791792793 Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-6095941.I-D@ietf.org> --MIMEStream=_1+56004_97273797717805_2791792793-- --MIMEStream=_0+217736_4370862858773_64755974508-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76Eevqt021874 for ; Wed, 6 Aug 2003 07:40:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h76EevaL021873 for ietf-imapext-bks; Wed, 6 Aug 2003 07:40:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76Eeqqt021859 for ; Wed, 6 Aug 2003 07:40:55 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18934; Wed, 6 Aug 2003 10:40:50 -0400 (EDT) Message-Id: <200308061440.KAA18934@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-list-extensions-04.txt Date: Wed, 06 Aug 2003 10:40:50 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 LIST Command Extensions Author(s) : B. Leiba Filename : draft-ietf-imapext-list-extensions-04.txt Pages : 8 Date : 2003-8-6 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-list-extensions-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-list-extensions-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-6095941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-6095941.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75FARqt016245 for ; Tue, 5 Aug 2003 08:10:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75FAR5m016244 for ietf-imapext-bks; Tue, 5 Aug 2003 08:10:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75FAQqt016234 for ; Tue, 5 Aug 2003 08:10:26 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h75FECV30857; Tue, 5 Aug 2003 09:14:12 -0600 Message-ID: <3F2FC8DF.5050007@isode.com> Date: Tue, 05 Aug 2003 16:10:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-03.txt References: <200308051415.KAA12765@ietf.org> In-Reply-To: <200308051415.KAA12765@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. > > Title : IMAP Extension for Conditional STORE operation > Author(s) : A. Melnikov, S. Hole > Filename : draft-ietf-imapext-condstore-03.txt > Pages : 16 > Date : 2003-8-5 > >Often, multiple IMAP clients need to coordinate changes to a common >IMAP mailbox. Examples include different clients for the same user, >and multiple users accessing shared mailboxes. These clients >need a mechanism to synchronize state changes for messages within the >mailbox. They must be able to guarantee that only one client can change >message state (e.g., message flags or annotations) at any time. An >example of such an application is use of an IMAP mailbox as a message >queue with multiple dequeueing clients. >The Conditional Store facility provides a protected update mechanism for >message state information that can detect and resolve conflicts between >multiple writing mail clients. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-03.txt > The goal is to Last Call this document ASAP. Please send your comments. This revision adds a new concept of fetch modifier and describes one of the (CHANGEDSINCE). After discussing this offline with Timo we've agreed that there was no need for a separate extension and that this functionality would be heavily used by the clients. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75EFRqt012860 for ; Tue, 5 Aug 2003 07:15:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75EFRAV012859 for ietf-imapext-bks; Tue, 5 Aug 2003 07:15:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75EFQqt012854 for ; Tue, 5 Aug 2003 07:15:27 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12765; Tue, 5 Aug 2003 10:15:22 -0400 (EDT) Message-Id: <200308051415.KAA12765@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-condstore-03.txt Date: Tue, 05 Aug 2003 10:15:22 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP Extension for Conditional STORE operation Author(s) : A. Melnikov, S. Hole Filename : draft-ietf-imapext-condstore-03.txt Pages : 16 Date : 2003-8-5 Often, multiple IMAP clients need to coordinate changes to a common IMAP mailbox. Examples include different clients for the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-condstore-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-condstore-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-5092212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-condstore-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-condstore-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-5092212.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7U0ANgc018886 for ; Fri, 29 Aug 2003 17:10:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7U0ANwe018885 for ietf-imapext-bks; Fri, 29 Aug 2003 17:10:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7U0ALgc018878 for ; Fri, 29 Aug 2003 17:10:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-a-83.buf.adelphia.net [24.51.28.83]) (authenticated bits=0) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7U0AIX0003671 for ; Fri, 29 Aug 2003 20:10:19 -0400 (EDT) Message-ID: <3F4FEB67.3050100@oceana.com> Date: Fri, 29 Aug 2003 20:10:15 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > > On Friday, Aug 29, 2003, at 20:52 Europe/Helsinki, Mark Crispin wrote: > >> I agree with this concern. CHILDREN information should not be included >> unless the client does something to request it. I thought that we had >> agreed to do this. > > > LIST () "" % should not return it, but for backwards compatibility I > think the old style LIST should return it when it can. I agree. LIST () "" % returns no children info, but LIST "" % does return info in the presence of the (obsolete?) CHILDREN extension. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TNongc018310 for ; Fri, 29 Aug 2003 16:50:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TNontm018309 for ietf-imapext-bks; Fri, 29 Aug 2003 16:50:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TNokgc018296 for ; Fri, 29 Aug 2003 16:50:47 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id B86F923A60; Sat, 30 Aug 2003 02:50:38 +0300 (EEST) Received: from iki.fi (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id A09A7238C9; Sat, 30 Aug 2003 02:50:36 +0300 (EEST) Date: Sat, 30 Aug 2003 02:50:54 +0300 Subject: Re: Last Calling the LISTEXT draft? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Pete Maclean , IMAP extensions Mailing List To: Mark Crispin From: Timo Sirainen In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, Aug 29, 2003, at 20:52 Europe/Helsinki, Mark Crispin wrote: > I agree with this concern. CHILDREN information should not be included > unless the client does something to request it. I thought that we had > agreed to do this. LIST () "" % should not return it, but for backwards compatibility I think the old style LIST should return it when it can. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7THqngc097008 for ; Fri, 29 Aug 2003 10:52:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7THqnCd097006 for ietf-imapext-bks; Fri, 29 Aug 2003 10:52:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7THqlgc096990 for ; Fri, 29 Aug 2003 10:52:47 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.08) with ESMTP id h7THqcHE002474; Fri, 29 Aug 2003 10:52:43 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7THqcb5007754; Fri, 29 Aug 2003 10:52:38 -0700 Date: Fri, 29 Aug 2003 10:52:38 -0700 (PDT) From: Mark Crispin To: Pete Maclean cc: IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? In-Reply-To: <5.1.1.6.2.20030829133242.049f0458@pop.webcom.com> Message-ID: References: <3F420A9B.40406@isode.com> <5.1.1.6.2.20030829133242.049f0458@pop.webcom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 29 Aug 2003, Pete Maclean wrote: > As I understand it, this means that a client that wants to take advantage > of LISTEXT has to put up with a server's sending \HasChildren or > \HasNoChildren for every single mailbox LISTed, should the server choose to > do that, even if the client does not value that information and does > nothing with it. This adds an average of about 14 characters to every > listing. That is not going to add up to much in the typical case but, in a > time when we are seeing the BINARY extension introduced to reduce the > amount of data sent over slow wireless connections, is this the direction > we want to go in? I agree with this concern. CHILDREN information should not be included unless the client does something to request it. I thought that we had agreed to do this. Besides adding chatter which may be unnecessary, CHILDREN information may be expensive to obtain. There's no reason to put the server to the work if the client doesn't care. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7THiNgc096670 for ; Fri, 29 Aug 2003 10:44:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7THiNsn096669 for ietf-imapext-bks; Fri, 29 Aug 2003 10:44:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from curly.webcom.com (curly.webcom.com [192.220.116.140]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7THiNgc096664 for ; Fri, 29 Aug 2003 10:44:23 -0700 (PDT) (envelope-from aaddict@maclean.com) Received: from kigal (kigal.webcom.com [192.220.116.57]) by curly.webcom.com (8.11.6/8.9.3) with SMTP id h7THgmS30763 for ; Fri, 29 Aug 2003 10:42:59 -0700 Received: from [216.207.178.10] by banana (WebCom SMTP 2.0) with SMTP id 190082244; Fri Aug 29 10:44 PDT 2003 Message-Id: <5.1.1.6.2.20030829133242.049f0458@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 29 Aug 2003 13:44:47 -0400 To: "IMAP extensions Mailing List" From: Pete Maclean Subject: Re: Last Calling the LISTEXT draft? In-Reply-To: <004701c3668b$9200d040$40280209@watson.ibm.com> References: <3F420A9B.40406@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mimeheaders-Plugin-Info: v2.03.00 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is anyone concerned about the opportunity for the possibly undesired verbosity allowed by LISTEXT? I am specifically thinking about the statement that, "While these attributes [\HasChildren and \HasNoChildren] MAY be returned in response to any LIST command..." As I understand it, this means that a client that wants to take advantage of LISTEXT has to put up with a server's sending \HasChildren or \HasNoChildren for every single mailbox LISTed, should the server choose to do that, even if the client does not value that information and does nothing with it. This adds an average of about 14 characters to every listing. That is not going to add up to much in the typical case but, in a time when we are seeing the BINARY extension introduced to reduce the amount of data sent over slow wireless connections, is this the direction we want to go in? Pete Maclean Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P0d7qt067206 for ; Sun, 24 Aug 2003 17:39:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P0d7Nr067205 for ietf-imapext-bks; Sun, 24 Aug 2003 17:39:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P0d6qt067200 for ; Sun, 24 Aug 2003 17:39:06 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7P0d7tD040583; Sun, 24 Aug 2003 18:39:07 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Sun, 24 Aug 2003 18:39:07 -0600 From: Lyndon Nerenberg To: Paul Smith , imap@u.washington.edu cc: ietf-imapext@imc.org Subject: Designing secure protocols (or: how not to open the barn door) Message-ID: <2147483647.1061750347@[192.168.42.6]> In-Reply-To: <5.2.1.1.2.20030825001327.057c88d8@lmail.pscs.co.uk> References: <5.2.1.1.2.20030823230108.04909370@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> <5.2.1.1.2.20030823230108.04909370@lmail.pscs.co.uk> <5.2.1.1.2.20030825001327.057c88d8@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [This thread is getting far afield from imapext's charter. Let's move it to the IMAP protocol list. PLEASE remove ietf-imapext@imc.org from any replies.] [[Cyrus: why won't Mulberry let me set a Reply-To header?!?]] On Monday, August 25, 2003 12:14 AM +0100 Paul Smith wrote: >> Does LDAP permit an unauthenticated client to obtain a list of >> usernames with which it potentially could authenticate? > > Sometimes, (in a slightly roundabout way) yes - by giving a list of > email addresses which, probably 99% of the time, are directly related > to user names. Thus the requirement for friendly identifiers divorced from authentication identifiers. > Would an IMAP extension? > No - it would only give it to AUTHENTICATED users, obviously. I hope that doesn't include those authenticated as anonymous. It's still a bad idea. If I can guess one password, I can authenticate and then retrieve the list of valid authentication identifiers for my next round of attacks. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P0aOqt067135 for ; Sun, 24 Aug 2003 17:36:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P0aNH2067134 for ietf-imapext-bks; Sun, 24 Aug 2003 17:36:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P0aMqt067126 for ; Sun, 24 Aug 2003 17:36:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-a-83.buf.adelphia.net [24.51.28.83]) (authenticated bits=0) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7P0aBri007835; Sun, 24 Aug 2003 20:36:12 -0400 (EDT) Message-ID: <3F4959F9.2050202@oceana.com> Date: Sun, 24 Aug 2003 20:36:09 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Timo Sirainen CC: ietf-imapext@imc.org, cyrus-bugs@andrew.cmu.edu Subject: Re: acl-08: questions References: <86984702-D687-11D7-9D97-000393CC2E90@iki.fi> In-Reply-To: <86984702-D687-11D7-9D97-000393CC2E90@iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > Hmm. This brings to my mind, Cyrus people might want to look at their > Sieve implementation (lmtpd part I think) a bit more, it looked like > there's still some potential buffer overflows.. Burying this statement in the middle of a totally unrelated thread on a IETF WG mailing list isn't the ideal place for it. If you think you've found something, you should report it to cyrus-bugs. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Fqt066346 for ; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P00FoI066344 for ietf-imapext-bks; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Bqt066330 for ; Sun, 24 Aug 2003 17:00:11 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 32881235C7C for ; Mon, 25 Aug 2003 01:00:10 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Mon, 25 Aug 2003 00:59:32 +0100 Message-Id: <5.2.1.1.2.20030825002338.054ba6f8@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 25 Aug 2003 00:44:24 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030823232646.04d4be70@lmail.pscs.co.uk> <5.2.1.1.2.20030823010843.055d99b8@lmail.pscs.co.uk> <5.2.1.1.2.20030823232646.04d4be70@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:34 24/08/2003 -0700, you wrote: >On Sat, 23 Aug 2003, Paul Smith wrote: > > I think the problem has changed from 'RFC 2086 is not implementable on > > Unix' (which was the original statement) to 'yes, it's implementable, but > > we don't want to because a few people (including the IMAP server > > developers) like some features that we might lose if we do it that way'. > >You have made a completely false statement. I don't think so - you essentially said the same yourself 30 minutes later.. "I am perfectly capable of implementing RFC 2086 in an IMAP server which owns all the mail data." My (and others) 'argument' is that, given that that is the case, is lots of added complexity worth it? This is what should be considered, rather than 'we MUST do it this way because that's the only way it'll work on Unix' >Just because you can create a strawman mockery of another individual's >position does not make that strawman true. I'm sorry, I'm not trying to make a mockery of anything - I just think it ought to be clear that that is the case. There ARE Unix servers which implement RFC 2086. You (and others) don't want to do it that way because you believe you will lose other features which you see as important. This thread of the discussion started because there were statements saying things along the lines of 'we have to have tied rights because it won't work on Unix otherwise' (eg "IMAP ACL has stood out as something that is unimplementable in such environments"), and I responded 'there are ways of making it work on Unix without tied rights' (which you have confirmed). Now, there may be reasons why those ways aren't ideal in some situations, and I've learnt that people in 'Unix world' want to do things to their mailboxes that I'd never have anticipated - but it's still a valid counter-argument to say 'is the extra complexity (in the ACL standard) worth it?' In fact, if you have read my other messages, you'll have seen that I've been contributing to discussions on *HOW* IMAP ACL2 could be improved to allow more flexibility in it's tied rights (without being Unix specific), and considering client issues. I don't see this as trying to 'sabotage' ACL2 as you've been intimating... Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Fqt066347 for ; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P00FRB066343 for ietf-imapext-bks; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Bqt066327 for ; Sun, 24 Aug 2003 17:00:11 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id E58BA2359BB for ; Mon, 25 Aug 2003 01:00:08 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Mon, 25 Aug 2003 00:58:51 +0100 Message-Id: <5.2.1.1.2.20030825001546.0486be30@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 25 Aug 2003 00:17:49 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: LISTRIGHTS command (was Re: acl-08: questions) In-Reply-To: <3F48EB02.7010409@isode.com> References: <5.2.1.1.2.20030822235324.06329188@lmail.pscs.co.uk> <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> <5.2.1.1.2.20030822235324.06329188@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 17:42 24/08/2003 +0100, Alexey Melnikov wrote: >At one point ACL2 had LISTRIGHTS command that allowed the client to query >this information. >In March I've removed it, assuming that most clients will just try to set >a particular right and will do some action based on RIGHTS-INFO response. >Nobody objected. > >Do I see a consensus to add it back (possibly as a new LIST item)? Well, I'd vote to add it back (as either a LIST item or a LISTRIGHTS command). For a nice friendly client UI, it really would be best if it could find out what it could do first. Otherwise the user will get annoyed if he/she tries to do something and it fails. The client wouldn't have to use it if it didn't want, it could just try and change it, if that's what it preferred (eg if it was an automated change) Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Fqt066348 for ; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P00FUJ066345 for ietf-imapext-bks; Sun, 24 Aug 2003 17:00:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P00Bqt066328 for ; Sun, 24 Aug 2003 17:00:11 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id C2B9D235A02 for ; Mon, 25 Aug 2003 01:00:09 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Mon, 25 Aug 2003 00:58:48 +0100 Message-Id: <5.2.1.1.2.20030825001327.057c88d8@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 25 Aug 2003 00:14:44 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030823230108.04909370@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> <5.2.1.1.2.20030823230108.04909370@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:22 24/08/2003 +0200, you wrote: >Paul Smith writes: >>At 11:06 23/08/2003 -0600, Lyndon Nerenberg wrote: >>>The security implications are by far the most important consideration >>>here. The most valuable tool for performing a dictionary attack is a >>>list of authentication identifiers. Any protocol that serves up such a >>>list on demand doesn't stand a chance of getting past the IESG. >> >>Hmm, so LDAP won't get through either... > >Does LDAP permit an unauthenticated client to obtain a list of usernames >with which it potentially could authenticate? Sometimes, (in a slightly roundabout way) yes - by giving a list of email addresses which, probably 99% of the time, are directly related to user names. Would an IMAP extension? No - it would only give it to AUTHENTICATED users, obviously. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ON62qt065065 for ; Sun, 24 Aug 2003 16:06:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ON62pF065064 for ietf-imapext-bks; Sun, 24 Aug 2003 16:06:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ON5xqt065055 for ; Sun, 24 Aug 2003 16:06:00 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 76274238D4; Mon, 25 Aug 2003 02:05:51 +0300 (EEST) Received: from iki.fi (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 9035F238C5; Mon, 25 Aug 2003 02:05:49 +0300 (EEST) Date: Mon, 25 Aug 2003 02:05:59 +0300 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Paul Smith , ietf-imapext@imc.org To: Mark Crispin From: Timo Sirainen In-Reply-To: Message-Id: <86984702-D687-11D7-9D97-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sunday, Aug 24, 2003, at 19:02 Europe/Helsinki, Mark Crispin wrote: > The former goal, although technically possible, creates the worst of > both > worlds: > 1) If the server is not the owner of the file, it is technically > limited by what UNIX can do with group access rights Then it also means that the user doesn't have +a access to the mailbox. Not really a problem. > 2) Sharing via group access from the shell end is not possible, since > a > file can only be in one group Which is why I said server should try to use real UNIX groups whenever only one group is given access. If user wants to share the mails outside IMAP server, he just wouldn't give ACLs which can't be expressed with UNIX rights. > 3) The server has access to all mail; there is no intrinsic firewall > created by being logged in as a user. A single buffer overflow bug > gives a hacker access to all mail in the system No, server would have access to some, maybe most, shared mailboxes. That's still bad, but not nearly as bad. > (the Cyrus server > has had this security bug; as have numerous UNIX mail programs that > use setgid mail). Hmm. This brings to my mind, Cyrus people might want to look at their Sieve implementation (lmtpd part I think) a bit more, it looked like there's still some potential buffer overflows.. > A good IMAP ACL specification exports the existing ACLs of those mail > stores. I agree it would be nice. I'm just not sure how useful it would be. You're basically allowed to give rights to one group or everyone. I think it's a bit unlikely that you belong to some group which contains only the people who you want to share the mailbox with. Maybe it's manageable if you allow users to create their own new groups in some way. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OGgtqt047050 for ; Sun, 24 Aug 2003 09:42:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7OGgtqX047049 for ietf-imapext-bks; Sun, 24 Aug 2003 09:42:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OGgpqt047044 for ; Sun, 24 Aug 2003 09:42:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Sun, 24 Aug 2003 17:42:45 +0100 Message-ID: <3F48EB02.7010409@isode.com> Date: Sun, 24 Aug 2003 17:42:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Smith CC: ietf-imapext@imc.org Subject: LISTRIGHTS command (was Re: acl-08: questions) References: <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> <5.2.1.1.2.20030822235324.06329188@lmail.pscs.co.uk> In-Reply-To: <5.2.1.1.2.20030822235324.06329188@lmail.pscs.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Smith wrote: > At 18:27 22/08/2003 +0100, Alexey Melnikov wrote: > You could have > >>> ACL "FreeAndEasy" s w i t e l r p c x a g u >>> which supports anything or >>> ACL "VeryLimited" switecxa lr p u1 >>> which has a 'read' and a 'write' mode only and only supports a >>> single user and no groups >>> >>> For the Posix case, even if the client didn't understand that case >>> specifically it could tie the 'swite' checkboxes (or whatever) >>> together, and could only allow the selection of a single user, and >>> multiple groups as the identifier. >> >> >> I think I mostly like this. >> Also note, that currently RIGHTS-INFO response returns "switecxa lr >> p" part of the >> ACL "VeryLimited" switecxa lr p u1 > > > Yes, I know (that's why I chose that syntax), but (IMHO) it's too late > by then - RIGHTS-INFO only comes when an ACL-STORE command fails. It'd > be better (from the client viewpoint) to be able to ask for it without > having to come up with a failing ACL-STORE command and then undo it. At one point ACL2 had LISTRIGHTS command that allowed the client to query this information. In March I've removed it, assuming that most clients will just try to set a particular right and will do some action based on RIGHTS-INFO response. Nobody objected. Do I see a consensus to add it back (possibly as a new LIST item)? Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OGRtqt046621 for ; Sun, 24 Aug 2003 09:27:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7OGRtVf046620 for ietf-imapext-bks; Sun, 24 Aug 2003 09:27:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OGRsqt046613 for ; Sun, 24 Aug 2003 09:27:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Sun, 24 Aug 2003 17:27:38 +0100 Message-ID: <3F48E778.4030702@isode.com> Date: Sun, 24 Aug 2003 17:27:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timo Sirainen CC: ietf-imapext@imc.org Subject: Re: ACL2 negative rights References: <1061683801.19012.190.camel@hurina> In-Reply-To: <1061683801.19012.190.camel@hurina> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: >Is there a reason why user identifier is the one that's set negative, >rather than the rights themselves? Are duplicate identifiers even >allowed? > No, but a "negative rights" identifier is not the same identifier as the "normal one". >ACL SET (mailbox) user=foo lr-i group=bar i > >makes more sense to me than: > >ACL SET (mailbox) user=foo lr -user=foo i group=bar i > Probably, but to backward compatibility I would just leave this as is. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OG2wqt043196 for ; Sun, 24 Aug 2003 09:02:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7OG2w7q043195 for ietf-imapext-bks; Sun, 24 Aug 2003 09:02:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OG2uqt043176 for ; Sun, 24 Aug 2003 09:02:57 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7OG2dCK006574; Sun, 24 Aug 2003 09:02:40 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7OG2duj001571; Sun, 24 Aug 2003 09:02:39 -0700 Date: Sun, 24 Aug 2003 09:02:39 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 23 Aug 2003, Timo Sirainen wrote: > > Wouldn't > > chgrp imapgrp > > (where the imap server is in imapgrp) > > chmod 660 > > work? > Yes, assuming you can give IMAP process access to such group. This presumes that the goal is to implement ACL via UNIX security, as opposed to being able to express and manage existing mail store security (including UNIX file/directory protections as an example) with ACL. These two are completely different goals. The former goal, although technically possible, creates the worst of both worlds: 1) If the server is not the owner of the file, it is technically limited by what UNIX can do with group access rights 2) Sharing via group access from the shell end is not possible, since a file can only be in one group 3) The server has access to all mail; there is no intrinsic firewall created by being logged in as a user. A single buffer overflow bug gives a hacker access to all mail in the system (the Cyrus server has had this security bug; as have numerous UNIX mail programs that use setgid mail). 4) Most security has to be done in software in the IMAP server, thus creating two independent points (kernel and IMAP server) in which security is imposed. At least for me, the former goal is pointless. It may be of interest to other individuals, although I question its architectual soundness from a security perspective. My goal is the latter goal. First and foremost, there is no impact on existing shell users; IMAP is just another MUA in a heterogenuous world. The existing security web is maintained for shell users and IMAP users; a false pointer reference in an IMAP server won't give access to anything that a malicious user-written program run at the shell will have. I am perfectly capable of implementing RFC 2086 in an IMAP server which owns all the mail data. Some people seem to think that such IMAP servers are (or should be) the only type of IMAP servers. They aren't the only type of IMAP server. Some IMAP servers export existing mail stores which have their own rules. A good IMAP ACL specification exports the existing ACLs of those mail stores. RFC 2086 was an attempt at a good IMAP ACL specification, but it had certain design faults which -- in spite of the best efforts of its author -- caused it to fall short of that goal. It would be a shame if ACL2 fails to do a better job. It would be an even worse shame if ACL2 fails to do so out of a conscious decision not to do a better job. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OFZ0qt040768 for ; Sun, 24 Aug 2003 08:35:00 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7OFZ0Cd040767 for ietf-imapext-bks; Sun, 24 Aug 2003 08:35:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7OFYxqt040751 for ; Sun, 24 Aug 2003 08:34:59 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7OFYmgG011737; Sun, 24 Aug 2003 08:34:53 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7OFYmZX001058; Sun, 24 Aug 2003 08:34:48 -0700 Date: Sun, 24 Aug 2003 08:34:48 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030823232646.04d4be70@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030823010843.055d99b8@lmail.pscs.co.uk> <5.2.1.1.2.20030823232646.04d4be70@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 23 Aug 2003, Paul Smith wrote: > I think the problem has changed from 'RFC 2086 is not implementable on > Unix' (which was the original statement) to 'yes, it's implementable, but > we don't want to because a few people (including the IMAP server > developers) like some features that we might lose if we do it that way'. You have made a completely false statement. Just because you can create a strawman mockery of another individual's position does not make that strawman true. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O0A1qt064992 for ; Sat, 23 Aug 2003 17:10:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7O0A15L064991 for ietf-imapext-bks; Sat, 23 Aug 2003 17:10:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O09xqt064983 for ; Sat, 23 Aug 2003 17:09:59 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 89F425C65485 for ; Sun, 24 Aug 2003 03:10:01 +0300 (EEST) Subject: ACL2 negative rights From: Timo Sirainen To: ietf-imapext@imc.org Content-Type: text/plain Message-Id: <1061683801.19012.190.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 24 Aug 2003 03:10:01 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there a reason why user identifier is the one that's set negative, rather than the rights themselves? Are duplicate identifiers even allowed? ACL SET (mailbox) user=foo lr-i group=bar i makes more sense to me than: ACL SET (mailbox) user=foo lr -user=foo i group=bar i Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O02Kqt064901 for ; Sat, 23 Aug 2003 17:02:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7O02KnM064900 for ietf-imapext-bks; Sat, 23 Aug 2003 17:02:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7O02Iqt064894 for ; Sat, 23 Aug 2003 17:02:18 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 6E4715C65485; Sun, 24 Aug 2003 03:02:20 +0300 (EEST) Subject: Re: Maildir ACLs From: Timo Sirainen To: Cyrus Daboo Cc: ietf-imapext@imc.org In-Reply-To: <2147483647.1061667794@[10.0.1.10]> References: <890A53B4-D5C0-11D7-B6EB-000393CC2E90@iki.fi> <2147483647.1061667794@[10.0.1.10]> Content-Type: text/plain Message-Id: <1061683340.19011.181.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 24 Aug 2003 03:02:20 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 2003-08-24 at 02:43, Cyrus Daboo wrote: > | Courier-like shared maildirs use sticky bit in the mail directory, so > | mails are owned by the user who stored it there. That means each user has > | expunge and write access to their own mails, but not for others. > > I don't think this is an issue because its not about whether expunge will > actually do anything but rather whether the EXPUNGE command is even allowed > for a user. Thus if user A can write messages into a maildir mailbox, but > currently there are only deleted messages for user B there, EXPUNGE is > still valid for user A - of course it just does nothing. If user A did not > have the 'x' ACL, then EXPUNGE would have returned NO. The problem is that it still looks like you can give write access to the mailbox, but it actually doesn't work at least the way ACL spec says it would. You might as well say that you have write access to all mailboxes, it's just that STORE and EXPUNGE do nothing in them. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNoDqt064650 for ; Sat, 23 Aug 2003 16:50:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NNoDxT064649 for ietf-imapext-bks; Sat, 23 Aug 2003 16:50:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNoBqt064644 for ; Sat, 23 Aug 2003 16:50:12 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 95C0B5C65485; Sun, 24 Aug 2003 02:50:13 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: Cyrus Daboo Cc: Paul Smith , ietf-imapext@imc.org In-Reply-To: <2147483647.1061667346@[10.0.1.10]> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs. co.uk> <2147483647.1061667346@[10.0.1.10]> Content-Type: text/plain Message-Id: <1061682613.19009.170.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 24 Aug 2003 02:50:13 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 2003-08-24 at 02:35, Cyrus Daboo wrote: > However it would be nice (not ACL2 but something after perhaps) > if it were possible to construct a LIST command that only returned those > with the matching ACL, e.g.: > > a LIST (ACL=user=fred) "" "INBOX.*" I think this is very much related to ANNOTATEMORE. Add searching support for it and export ACLs as annotations. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNhJqt064545 for ; Sat, 23 Aug 2003 16:43:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NNhJrI064544 for ietf-imapext-bks; Sat, 23 Aug 2003 16:43:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNhIqt064539 for ; Sat, 23 Aug 2003 16:43:18 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.10] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id TAA01926; Sat, 23 Aug 2003 19:39:22 -0400 (EDT) Date: Sat, 23 Aug 2003 19:43:14 -0400 From: Cyrus Daboo To: Timo Sirainen , ietf-imapext@imc.org Subject: Re: Maildir ACLs Message-ID: <2147483647.1061667794@[10.0.1.10]> In-Reply-To: <890A53B4-D5C0-11D7-B6EB-000393CC2E90@iki.fi> References: <890A53B4-D5C0-11D7-B6EB-000393CC2E90@iki.fi> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Timo, --On Sunday, August 24, 2003 2:21 +0300 Timo Sirainen wrote: | Courier-like shared maildirs use sticky bit in the mail directory, so | mails are owned by the user who stored it there. That means each user has | expunge and write access to their own mails, but not for others. | | ACL2 doesn't really support that. Should it? Or how would I describe ACLs | for such mailboxes? Maybe add a new sticky rights attribute? I don't think this is an issue because its not about whether expunge will actually do anything but rather whether the EXPUNGE command is even allowed for a user. Thus if user A can write messages into a maildir mailbox, but currently there are only deleted messages for user B there, EXPUNGE is still valid for user A - of course it just does nothing. If user A did not have the 'x' ACL, then EXPUNGE would have returned NO. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNZtqt064407 for ; Sat, 23 Aug 2003 16:35:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NNZtHT064406 for ietf-imapext-bks; Sat, 23 Aug 2003 16:35:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNZsqt064401 for ; Sat, 23 Aug 2003 16:35:54 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.10] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id TAA01796; Sat, 23 Aug 2003 19:31:54 -0400 (EDT) Date: Sat, 23 Aug 2003 19:35:46 -0400 From: Cyrus Daboo To: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061667346@[10.0.1.10]> In-Reply-To: <5.2.1.1.2.20030823233048.05cb65e0@lmail.pscs.co.uk> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs. co.uk> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Paul, --On Saturday, August 23, 2003 23:35 +0100 Paul Smith wrote: | | In most cases, isn't the client just going to use the 'LIST (ACL)' | command when a user wants to edit the ACL for a group - so the user | presses 'Edit ACL', the client sends LIST (ACL) to the server for that | group, gets back the response and displays the relevant data for editing. | | In this case, is an extra 20 bytes going to make that much difference? | It'll be a relatively rare event. | | If you're going to set the ACL for an entire hierarchy at once, why not | just say that you only return the rights model if it's different from the | previous one returned, so the first mailbox always returns the model, and | subsequent ones only return it if it's different from the first one. This | would cut down on the extra round trip, would (ISTM) be simpler from the | client point of view, and not must harder from the server POV. One operation that is useful is 'tell me which of my mailboxes is being shared to user=fred'. Currently (ACL) the only way to do that is a GETACL command for every mailbox in the personal hierarchy - ughh! With ACL2 a single LIST will do the trick. However it would be nice (not ACL2 but something after perhaps) if it were possible to construct a LIST command that only returned those with the matching ACL, e.g.: a LIST (ACL=user=fred) "" "INBOX.*" * LIST "." INBOX.public (("ACL" "model1" ("user=fred" "rwipslextda"))) * LIST "." INBOX.public.fred (("ACL" "model1" ("user=fred" "rwipslextda"))) a OK -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNM2qt064123 for ; Sat, 23 Aug 2003 16:22:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NNM1M8064122 for ietf-imapext-bks; Sat, 23 Aug 2003 16:22:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NNLxqt064114 for ; Sat, 23 Aug 2003 16:22:00 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 08B022387F; Sun, 24 Aug 2003 02:21:54 +0300 (EEST) Received: from iki.fi (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 3E067238C9 for ; Sun, 24 Aug 2003 02:21:21 +0300 (EEST) Date: Sun, 24 Aug 2003 02:21:34 +0300 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Maildir ACLs From: Timo Sirainen To: ietf-imapext@imc.org Content-Transfer-Encoding: 7bit Message-Id: <890A53B4-D5C0-11D7-B6EB-000393CC2E90@iki.fi> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_01,USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Courier-like shared maildirs use sticky bit in the mail directory, so mails are owned by the user who stored it there. That means each user has expunge and write access to their own mails, but not for others. ACL2 doesn't really support that. Should it? Or how would I describe ACLs for such mailboxes? Maybe add a new sticky rights attribute? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMfmqt063332 for ; Sat, 23 Aug 2003 15:41:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NMfm23063331 for ietf-imapext-bks; Sat, 23 Aug 2003 15:41:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMfkqt063326 for ; Sat, 23 Aug 2003 15:41:47 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id E5765238565 for ; Sat, 23 Aug 2003 23:40:09 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 23:36:48 +0100 Message-Id: <5.2.1.1.2.20030823232646.04d4be70@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 23:28:49 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030823010843.055d99b8@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 21:30 23/08/2003 +0300, Timo Sirainen wrote: >On Saturday, Aug 23, 2003, at 03:15 Europe/Helsinki, Paul Smith wrote: > >>Wouldn't >>chgrp imapgrp >>(where the imap server is in imapgrp) >>chmod 660 >> >>work? > >Yes, assuming you can give IMAP process access to such group. I think >setgroups() is portable enough. setgid() might be enough too. >Summary: > - Client wouldn't have to think about server restrictions > - Solves about all the current protocol issues > - RFC 2086 is actually implementable with it.. > - Doesn't force users to change existing ways > - I believe it solves the needs for 99% of users > - Perhaps it's not implementable in some rare platforms that don't > provide setgroups()-like functionality. > >Too bad Mark will just shoot this down :) Yep :-( I think the problem has changed from 'RFC 2086 is not implementable on Unix' (which was the original statement) to 'yes, it's implementable, but we don't want to because a few people (including the IMAP server developers) like some features that we might lose if we do it that way'. This is a valid statement, but whether it warrants the extra complexity for everyone else is debatable. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMfFqt063316 for ; Sat, 23 Aug 2003 15:41:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NMfFdJ063315 for ietf-imapext-bks; Sat, 23 Aug 2003 15:41:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMfDqt063309 for ; Sat, 23 Aug 2003 15:41:14 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id D82A2238F5E for ; Sat, 23 Aug 2003 23:40:10 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 23:36:45 +0100 Message-Id: <5.2.1.1.2.20030823230108.04909370@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 23:24:39 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061636769@[192.168.42.6]> References: <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:06 23/08/2003 -0600, Lyndon Nerenberg wrote: >On Saturday, August 23, 2003 12:25 AM +0100 Paul Smith >wrote: > >>>There are also significant security implications to providing a >>>complete list of users. >> >>In some cases, yes, in other cases, there are big usability >>implications in not providing the list.. > >The security implications are by far the most important consideration >here. The most valuable tool for performing a dictionary attack is a list >of authentication identifiers. Any protocol that serves up such a list on >demand doesn't stand a chance of getting past the IESG. Hmm, so LDAP won't get through either... In the vast majority of email systems, the 'authentication identifier' is also the 'user' part of the email address (or in some cases the subdomain part), so the results of an LDAP search will pretty much give you a list of authentication identifiers. >This is *very* basic security design engineering practice. If you don't >understand why what you're proposing is harmful, you really need to spend >some time reading about security design. I understand why it COULD be harmful. I also understand why, in many cases, it wouldn't be harmful at all, but would be a big usability benefit. Eg, in a company of 100 people all of whom are quite happy knowing each others logins (their network OS could well makes the list of users visible in any case), the list will only be available to authenticated users, and will mean that message folder sharing is actually usable within that company rather than being complex to set up. It would obviously have to be an option that mail admins could disable if, for instance, their IMAP server was public rather than private. There is a danger of saying 'security concerns override everything', including usability. In a large number of cases, security concerns are relatively minimal, there should be an optional method of boosting usability in these cases. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMekqt063293 for ; Sat, 23 Aug 2003 15:40:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NMekcA063292 for ietf-imapext-bks; Sat, 23 Aug 2003 15:40:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NMeiqt063287 for ; Sat, 23 Aug 2003 15:40:45 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 2C85B238B02 for ; Sat, 23 Aug 2003 23:40:10 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 23:37:25 +0100 Message-Id: <5.2.1.1.2.20030823233048.05cb65e0@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 23:35:54 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061640316@[10.0.1.10]> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs. co.uk> List-ID: List-Unsubscribe: At 12:05 23/08/2003 -0400, Cyrus Daboo wrote: >I am also concerned that the proposed LIST response is going to result in >a lot of data that's going to be the same in each LIST. >How about a new ACL command to enumerate the set of ACL models that the >server currently supports and to tag those with a unique identifier that >is then used in the list response, e.g.: Is this really worth the added complexity? In most cases, isn't the client just going to use the 'LIST (ACL)' command when a user wants to edit the ACL for a group - so the user presses 'Edit ACL', the client sends LIST (ACL) to the server for that group, gets back the response and displays the relevant data for editing. In this case, is an extra 20 bytes going to make that much difference? It'll be a relatively rare event. If you're going to set the ACL for an entire hierarchy at once, why not just say that you only return the rights model if it's different from the previous one returned, so the first mailbox always returns the model, and subsequent ones only return it if it's different from the first one. This would cut down on the extra round trip, would (ISTM) be simpler from the client point of view, and not must harder from the server POV. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NLQHqt061753 for ; Sat, 23 Aug 2003 14:26:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NLQH6q061752 for ietf-imapext-bks; Sat, 23 Aug 2003 14:26:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NLQGqt061747 for ; Sat, 23 Aug 2003 14:26:16 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.10] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA29582; Sat, 23 Aug 2003 17:22:20 -0400 (EDT) Date: Sat, 23 Aug 2003 17:26:13 -0400 From: Cyrus Daboo To: Lyndon Nerenberg {VE6BBM} cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061659573@[10.0.1.10]> In-Reply-To: <2147483647.1061635436@[192.168.42.6]> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> <2147483647.1061640316@[10.0.1.10]> <2147483647.1061635436@[192.168.42.6]> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Lyndon, --On Saturday, August 23, 2003 10:43 -0600 Lyndon Nerenberg {VE6BBM} wrote: |> How about a new ACL command to enumerate the set of ACL models that the |> server currently supports and to tag those with a unique identifier |> that is then used in the list response, e.g.: | | As long as these are guaranteed to be immutable within a session, this | should be fine for the LIST case. | | I would not want to use these labels to set ACLs, though. I don't think | it's possible to guarantee they won't change over time, and if a badly | designed client decided to cache the label->ACL mapping for re-use in | later sessions, the consequences could be bad. Agreed - the labels MUST NOT be cached between sessions or presented to the user in any way. Another thing we could do is define the labels as a lightweight hash of the remainder of the response. That way they could be guaranteed to be unique and change if the model is tweaked a little by a sysadmin. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NIUHqt057531 for ; Sat, 23 Aug 2003 11:30:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NIUHJr057530 for ietf-imapext-bks; Sat, 23 Aug 2003 11:30:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NIUFqt057525 for ; Sat, 23 Aug 2003 11:30:15 -0700 (PDT) (envelope-from tss@iki.fi) Received: from iki.fi (unknown [192.168.10.209]) by oma.irssi.org (Postfix) with ESMTP id 4EE015C65485; Sat, 23 Aug 2003 21:30:10 +0300 (EEST) Date: Sat, 23 Aug 2003 21:30:23 +0300 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-imapext@imc.org To: Paul Smith From: Timo Sirainen In-Reply-To: <5.2.1.1.2.20030823010843.055d99b8@lmail.pscs.co.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Saturday, Aug 23, 2003, at 03:15 Europe/Helsinki, Paul Smith wrote: > Wouldn't > chgrp imapgrp > (where the imap server is in imapgrp) > chmod 660 > > work? Yes, assuming you can give IMAP process access to such group. I think setgroups() is portable enough. setgid() might be enough too. This is actually what I was planning to do from the beginning, although optionally and probably using multiple groups. I wouldn't really mind it if this behaviour was required for ACL. It would really take out most of the complexity. Listing existing ACLs would need to be possible always, but IMHO it's good enough restriction to require all shared mailboxes be in special imapd-group if you want to change their ACLs with IMAP. If it's not enough for you, you're probably in the minority who can just go and use chgrp directly. Nothing would prevent that. Server implementation could be smart as well. As long as the requested rights happen to be what could be expressed exactly with r/w and there's only one group given the access, server can just use that UNIX group instead of the imapd-group. This would work even better with the extended rights vs. basic rights distinction. Server would give the preferred mapping of extended rights to RO, RW, WO basic rights. As long as client used only those, server can use UNIX rights directly. Summary: - Client wouldn't have to think about server restrictions - Solves about all the current protocol issues - RFC 2086 is actually implementable with it.. - Doesn't force users to change existing ways - I believe it solves the needs for 99% of users - Perhaps it's not implementable in some rare platforms that don't provide setgroups()-like functionality. Too bad Mark will just shoot this down :) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NH6Fqt053040 for ; Sat, 23 Aug 2003 10:06:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NH6FRE053039 for ietf-imapext-bks; Sat, 23 Aug 2003 10:06:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NH6Eqt053033 for ; Sat, 23 Aug 2003 10:06:14 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7NH6963032703; Sat, 23 Aug 2003 11:06:15 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Sat, 23 Aug 2003 11:06:09 -0600 From: Lyndon Nerenberg To: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061636769@[192.168.42.6]> In-Reply-To: <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> References: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Saturday, August 23, 2003 12:25 AM +0100 Paul Smith wrote: >> There are also significant security implications to providing a >> complete list of users. > > In some cases, yes, in other cases, there are big usability > implications in not providing the list.. The security implications are by far the most important consideration here. The most valuable tool for performing a dictionary attack is a list of authentication identifiers. Any protocol that serves up such a list on demand doesn't stand a chance of getting past the IESG. This is *very* basic security design engineering practice. If you don't understand why what you're proposing is harmful, you really need to spend some time reading about security design. Steve Bellovin has written countless papers on this topic, and I strongly suggest you search them out and read them. You should also spend some time going through the minutes of the various security-related IETF WGs. There's a lot of history there that describes successful (and more importantly, unsuccessful) implementations of security in various IETF protocols. Cyrus was on the right track when he described the use of friendly identifiers that are decoupled from authentication identifiers. The difficulty with this scheme is designing a friendly identifier from which it is computationally difficult to derive the corresponding authentication identifier. We've been discussing this for years in the various IMAP WGs and discussion forums, but haven't come up with a solution that satisfies both the UI and the security requirements. And the problem is in no way unique to IMAP. Many other WGs have also wrestled with it, and to my knowledge, none of them have managed to solve it. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NGsdqt052731 for ; Sat, 23 Aug 2003 09:54:39 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NGsdts052730 for ietf-imapext-bks; Sat, 23 Aug 2003 09:54:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NGscqt052725 for ; Sat, 23 Aug 2003 09:54:38 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from UNIX45.andrew.cmu.edu (UNIX45.andrew.cmu.edu [128.2.13.175]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7NGsaI3028886; Sat, 23 Aug 2003 12:54:36 -0400 Date: Sat, 23 Aug 2003 12:54:36 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061640316@[10.0.1.10]> Message-ID: References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> <2147483647.1061640316@[10.0.1.10]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 23 Aug 2003, Cyrus Daboo wrote: > I'm concerned about the prospect of per-mailbox ACL models from the > perspective of the user wanting to manipulate multiple mailboxes at one > time, but realize that is probably going to be a reality for a lot of > implementations. The entire system is pretty complex, which is worrying me, but I don't have a good counter-proposal that will allow clients to predict how a server will behave if we want to live with all the constraints various implementations have while retaining the expressability of RFC2086. I'm also not strictly convinced that we must support more than one ACL model on a given server. We shouldn't close the door to it though. > I am also concerned that the proposed LIST response is going to result in a > lot of data that's going to be the same in each LIST. Yes, the size of list response are also concerning me. > How about a new ACL command to enumerate the set of ACL models that the > server currently supports and to tag those with a unique identifier that is > then used in the list response, e.g.: [snip] > This will greatly cut down on the LIST responses at the expense of one > extra roundtrip to list the models. The NIL for the third model implies no > tied rights. This also avoids the need to have a lengthy ACL2 capability > indicator. I don't think it's a real extra round trip though, you can pipeline the GETMODELS command with the LIST ACL command. > We could also use the models response to define what sensible R & W > synonyms might be: > > * ACLMODEL "model1" "MOST_SPECIFIC" "u g" ("lrs" "witextd" "p" "a") > ("R=lrs" "W=witextd") I would just define the last list to be ("lrs" "witextd") with the R and W being understood. This doesn't confuse the issue with a new set of rights tokens. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NGjIqt052520 for ; Sat, 23 Aug 2003 09:45:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NGjIkL052519 for ietf-imapext-bks; Sat, 23 Aug 2003 09:45:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NGjGqt052513 for ; Sat, 23 Aug 2003 09:45:17 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7NGht63032618; Sat, 23 Aug 2003 10:43:56 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Sat, 23 Aug 2003 10:43:56 -0600 From: Lyndon Nerenberg {VE6BBM} To: Cyrus Daboo cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061635436@[192.168.42.6]> In-Reply-To: <2147483647.1061640316@[10.0.1.10]> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> <2147483647.1061640316@[10.0.1.10]> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > How about a new ACL command to enumerate the set of ACL models that the > server currently supports and to tag those with a unique identifier > that is then used in the list response, e.g.: As long as these are guaranteed to be immutable within a session, this should be fine for the LIST case. I would not want to use these labels to set ACLs, though. I don't think it's possible to guarantee they won't change over time, and if a badly designed client decided to cache the label->ACL mapping for re-use in later sessions, the consequences could be bad. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NG5Nqt049195 for ; Sat, 23 Aug 2003 09:05:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7NG5NCX049194 for ietf-imapext-bks; Sat, 23 Aug 2003 09:05:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7NG5Lqt049184 for ; Sat, 23 Aug 2003 09:05:22 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.10] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA24246; Sat, 23 Aug 2003 12:01:23 -0400 (EDT) Date: Sat, 23 Aug 2003 12:05:16 -0400 From: Cyrus Daboo To: Rob Siemborski , Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061640316@[10.0.1.10]> In-Reply-To: References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Saturday, August 23, 2003 3:06 -0400 Rob Siemborski wrote: | I'd like to hear from a client author about this sort of proposal. I'm concerned about the prospect of per-mailbox ACL models from the perspective of the user wanting to manipulate multiple mailboxes at one time, but realize that is probably going to be a reality for a lot of implementations. I am also concerned that the proposed LIST response is going to result in a lot of data that's going to be the same in each LIST. How about a new ACL command to enumerate the set of ACL models that the server currently supports and to tag those with a unique identifier that is then used in the list response, e.g.: a ACL GETMODELS * ACLMODEL "model1" "MOST_SPECIFIC" "u g" ("lrs" "witextd" "p" "a") * ACLMODEL "model2" "UNION" "*u *g" ("lr" "switextd" "p" "a") * ACLMODEL "model3" "UNION" "*u *g" NIL a OK a LIST (ACL) "" * * LIST () "/" INBOX (("ACL" "model1") ("user=Fred" "rwipslextda"))) * LIST () "." #news.imap (("ACL" "model2") ("user=Fred" "rwipslextda"))) a OK This will greatly cut down on the LIST responses at the expense of one extra roundtrip to list the models. The NIL for the third model implies no tied rights. This also avoids the need to have a lengthy ACL2 capability indicator. We could also use the models response to define what sensible R & W synonyms might be: * ACLMODEL "model1" "MOST_SPECIFIC" "u g" ("lrs" "witextd" "p" "a") ("R=lrs" "W=witextd") This then allows the client to use a basic rights mode by mapping the set of extended rights to R and W. If R and W does not make sense with a particular combination of tied rights then the response could just have ("R=" "W=") or NIL to indicate that. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N8Llqt002962 for ; Sat, 23 Aug 2003 01:21:47 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N8LlV4002961 for ietf-imapext-bks; Sat, 23 Aug 2003 01:21:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N8Ljqt002956 for ; Sat, 23 Aug 2003 01:21:45 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id C8E4F2428D1 for ; Sat, 23 Aug 2003 09:20:44 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 09:15:32 +0100 Message-Id: <5.2.1.1.2.20030823090705.01f5f478@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 09:09:54 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:06 23/08/2003 -0400, Rob Siemborski wrote: > > * LIST () "/" INBOX (("ACL" "UNIX" "UNION" ("lr" "switextd" "p" "a") ("g*" > > "u") ("user=Fred" "rwipslextda"))) > > > > The bits following "ACL" are: > > - 'friendly name' for the rights scheme (in case the client wants to treat > > it specially), not sure about this, but I can't see any harm in it if > > they're registered > >I'd argue to get rid of this. Creating another registry is the last thing >we need, and such a name is really just clutter in the protocol. This >might encourage clients to glean something about the acl based on the >name, when really all the necessary information should be in the rest of >the response. No disagreement here.. If the client assumes that 'UNIX' means the rights are tied in a certain way, it could just check to see if the rights are tied that way and show a different UI if it wants - it wouldn't matter if it WAS Unix or not. > > - access calculation rule > > - rights groupings > >Your example severely penalizes the response given by a server that doesn't >tie rights. Such a server would have to respond: > >("l" "r" "s" "w" "i" "t" "e" "x" "t" "d" "p" "a" "0" "1" "2" "3" "4" "5" >"6" "7" "8" "9") > >for *every* mailbox in the LIST ACL response (remember, we need to >account for numeric rights as well). This is a huge waste of >bandwidth. > >Instead, I propose that rights that are not tied to other rights may be >omitted from the response, e.g.: > > > * LIST () "/" INBOX (("ACL" "UNION" () ("g*" "u*" "o" "a") > ("user=Fred" "rwipslextda"))) Slight proposed change to that - how about the server gives a 'tied rights' response in the ACL2= capability string, and then only reports tied rights in the LIST if it differs from the 'global' list? That would save bandwidth for tied rights servers as well. > > - EBNF style coding for groups/users etc (g? (0 or 1), g (1 exactly) g* (0 > > or more) g+ (1 or more)). Hmm, maybe it should be modified to be able to > > set a maximum number > 0 (eg 'g8' for maximum of 8 groups). You could be > > generic g0:1 g0 g1 g1:* g0:* g3:97 etc (who knows - if we're going to be > > flexible, why not be REALLY generic...) > >I think I'd prefer this to be a single string rather than a list of >strings, since nothing real is gained from the list. OK >I'd also caution being too generic, since we want to keep the ACL model as >simple as possible while preserving implementability (see also: webdav >ACLs). Having the ability for 0, 1, "0 or more", and "atleast 1" is >probably good enough. OK Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N80Oqt099646 for ; Sat, 23 Aug 2003 01:00:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N80Oie099645 for ietf-imapext-bks; Sat, 23 Aug 2003 01:00:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N80Mqt099634 for ; Sat, 23 Aug 2003 01:00:23 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id E3FD924320B for ; Sat, 23 Aug 2003 09:00:15 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 08:58:54 +0100 Message-Id: <5.2.1.1.2.20030823010843.055d99b8@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 01:15:42 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030822232937.0551e300@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <5.2.1.1.2.20030822232937.0551e300@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 16:31 22/08/2003 -0700, you wrote: > > You could look at it the other way, and say that doing it that way means > > that a bug in your server could ONLY affect the mailboxes, rather than all > > the files on the computer.. > >No. You are presuming that there is a userid which is not root but which >has access to all mail data. The only way to do that on UNIX is to make >that userid be the owner of all mail data (which is what Cyrus does); but >that precludes the shell user being the owner of his mail data. Wouldn't chgrp imapgrp (where the imap server is in imapgrp) chmod 660 work? Yes, this would stop arbitrary sharing of mailbox data, if that's an issue, which you say it is, but which surprises me. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N7X3qt092133 for ; Sat, 23 Aug 2003 00:33:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N7X1mI092121 for ietf-imapext-bks; Sat, 23 Aug 2003 00:33:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N7Wxqt092106 for ; Sat, 23 Aug 2003 00:32:59 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX1.andrew.cmu.edu (MX1.andrew.cmu.edu [128.2.10.111]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7N7WaI3028067; Sat, 23 Aug 2003 03:32:36 -0400 Date: Sat, 23 Aug 2003 03:32:36 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Mark Crispin wrote: > > We have this problem today with RFC2086 with > > knowing when to report the READ-ONLY response code to SELECT. > > IMHO, the READ-ONLY response code to SELECT means that that PERMANENTFLAGS > are per-user instead of global and EXPUNGE does nothing; that is, there is > no change that the client can make that will affect another user's SELECT > of the same mailbox. Its too bad RFC2086 says nothing about this (it definitely should be clarified in ACL2). RFC3501 does say: Read-only access through SELECT differs from the EXAMINE command in that certain read-only mailboxes MAY permit the change of permanent state on a per-user (as opposed to global) basis. Last I checked, messages and ACLs were part of the global state of the mailbox. And a user can have 'i' but not 'w'. I'm not going to argue that one interpretation is more correct than the other (I can see reading it both ways), but the semantics for READ-ONLY in the context of an ACL-aware server should be clarified in ACL2 (regardless of the existence of 'basic' ACLs). > > It needs to be > > clear exactly what 'R' and 'W' do. > > Without being able to state this on a per-mailbox basis, there is no > single definition. > > If we say that "W makes changes that another user can see", then that is > actually a separate status from other ACL bits and is useful to include. I have trouble accepting server-defined behavior for ACLs where the client can't tell in advance what is going to happen. For this reason, if 'basic rights' cannot have well-defined semantics, I don't think that they are safe to use. And if they can have well-defined semantics (a possibility that I now can understand as not being the case), then we might as well just use extended rights. > Well, why not just simplify tied rights so that a server can tie as it > pleases, and reports the results. That is, instead of refusing to give a > right until all tied rights are set, just give the additional rights for > free, and require that all tied rights be revoked in order to revoke any. > This is assuming that granting is more common than revoking, and that the > revoke situation implies knowledge of the current rights (and thus how > they are tied). Isn't this worse than the current ACL2, which will refuse to set any tied rights unless all are set at once? I definitely don't think a server should be setting rights behind the client's back. > I agree with Cyrus; most end users are concerned with things at the R > and W level. The "reasonable UI" is already going to reduce to R and W. I'd expect the "reasonable UI" to boil down to a set of checkboxes (or whatever) for groups of tied rights. Describing these tied rights is much harder if the server is free to tie them arbitrarily of course. I suspect an implementation suggestion along the lines of "If a server must tie the rights on a given mailbox, it SHOULD use one of the following groupings..." This might give the clients a chance to take a guess at what group corresponds to 'read' and which one corresponds to 'write'. Having verbatim 'R' and 'W' rights that might not do what the client is expecting (in the extended syntax) worries me though. There should only be one possible interpretation of any given ACL. > > At the minimum, anyone who uses > > shared folders in any serious way realizes that you *do* want to have > > at least separate control over manipulation of the data in the folder, and > > manipulation of the hierarchy underneath the folder (accepting, of course, > > that some mail stores do not allow folders with both contents and > > subordinates). > > I already covered that possibility. R and W for foo means manipulate the > data in the mailbox, where R and W for foo/ (or foo.) means manipulate the > hierarchy underneath. This seems pretty hackish to me, especially for servers that don't currently use this sort of syntax for folder manipulation anywhere else. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N762qt088423 for ; Sat, 23 Aug 2003 00:06:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N76255088422 for ietf-imapext-bks; Sat, 23 Aug 2003 00:06:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N760qt088416 for ; Sat, 23 Aug 2003 00:06:00 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX1.andrew.cmu.edu (MX1.andrew.cmu.edu [128.2.10.111]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7N760I3028026; Sat, 23 Aug 2003 03:06:00 -0400 Date: Sat, 23 Aug 2003 03:06:00 -0400 (EDT) From: Rob Siemborski To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> Message-ID: References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 23 Aug 2003, Paul Smith wrote: > Having both client and server tied rights will cause all sorts of problems. > They can either be at one end or the other, not really both. I don't believe you can legitimately tie rights at the client in any case. The important thing is that the client needs to know how the server functions, preferably before issuing any set-acl type commands. One possibility for this is to force tied rights to always be a certain way. Though, as Mark points out this has drawbacks. One could take something like your proposal and apply it to the capability string (e.g. ACL2=MOST-SPECIFIC=U_G_O=[rl][switextd][p][a]), which is pretty hairy looking but has all the necessary information. Another (as you propose) allows per-mailbox semantics, but requires that the client issue a LIST ACL before knowing what can be done to any mailbox. I'm not sure this is a big loss, since any client who is designing a decent UI will want to know the current contents of the ACL before presenting it anyway. Some comments on your proposal: > * LIST () "/" INBOX (("ACL" "UNIX" "UNION" ("lr" "switextd" "p" "a") ("g*" > "u") ("user=Fred" "rwipslextda"))) > > The bits following "ACL" are: > - 'friendly name' for the rights scheme (in case the client wants to treat > it specially), not sure about this, but I can't see any harm in it if > they're registered I'd argue to get rid of this. Creating another registry is the last thing we need, and such a name is really just clutter in the protocol. This might encourage clients to glean something about the acl based on the name, when really all the necessary information should be in the rest of the response. > - access calculation rule > - rights groupings Your example severely penalizes the response given by a server that doesn't tie rights. Such a server would have to respond: ("l" "r" "s" "w" "i" "t" "e" "x" "t" "d" "p" "a" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9") for *every* mailbox in the LIST ACL response (remember, we need to account for numeric rights as well). This is a huge waste of bandwidth. Instead, I propose that rights that are not tied to other rights may be omitted from the response, e.g.: > * LIST () "/" INBOX (("ACL" "UNION" () ("g*" "u*" "o" "a") ("user=Fred" "rwipslextda"))) > - EBNF style coding for groups/users etc (g? (0 or 1), g (1 exactly) g* (0 > or more) g+ (1 or more)). Hmm, maybe it should be modified to be able to > set a maximum number > 0 (eg 'g8' for maximum of 8 groups). You could be > generic g0:1 g0 g1 g1:* g0:* g3:97 etc (who knows - if we're going to be > flexible, why not be REALLY generic...) I think I'd prefer this to be a single string rather than a list of strings, since nothing real is gained from the list. I'd also caution being too generic, since we want to keep the ACL model as simple as possible while preserving implementability (see also: webdav ACLs). Having the ability for 0, 1, "0 or more", and "atleast 1" is probably good enough. I'd like to hear from a client author about this sort of proposal. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N1Shqt065512 for ; Fri, 22 Aug 2003 18:28:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N1ShiR065511 for ietf-imapext-bks; Fri, 22 Aug 2003 18:28:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N1Seqt065503 for ; Fri, 22 Aug 2003 18:28:42 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7N1S4oa027844; Fri, 22 Aug 2003 18:28:04 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7N1S4Vv021490; Fri, 22 Aug 2003 18:28:04 -0700 Date: Fri, 22 Aug 2003 18:28:04 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: Rob Siemborski , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061587367@[10.0.1.10]> Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> <2147483647.1061587367@[10.0.1.10]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Cyrus Daboo wrote: > | I already covered that possibility. R and W for foo means manipulate the > | data in the mailbox, where R and W for foo/ (or foo.) means manipulate the > | hierarchy underneath. > What if you have a dual-role mailbox - one with messages and a hierarchy > underneath? You might want to allow access to the top-level item's messages > but not allow access to the sub-hierarchy. Clearly the extended rights > model is needed for that. The dual-role mailbox possibility is precisely why you have to say "foo" vs. "foo/" (or "foo" vs. "foo."). In a single-role mailbox, the server can infer; but I think that it's probably best not to have server inference and return an error for an inappropriate operation. So, extended rights aren't needed for that. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N1Maqt065316 for ; Fri, 22 Aug 2003 18:22:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N1Mah1065315 for ietf-imapext-bks; Fri, 22 Aug 2003 18:22:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N1MYqt065310 for ; Fri, 22 Aug 2003 18:22:35 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.10] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id VAA09015; Fri, 22 Aug 2003 21:18:38 -0400 (EDT) Date: Fri, 22 Aug 2003 21:22:47 -0400 From: Cyrus Daboo To: Mark Crispin , Rob Siemborski cc: Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061587367@[10.0.1.10]> In-Reply-To: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Friday, August 22, 2003 5:46 PM -0700 Mark Crispin wrote: | I already covered that possibility. R and W for foo means manipulate the | data in the mailbox, where R and W for foo/ (or foo.) means manipulate the | hierarchy underneath. What if you have a dual-role mailbox - one with messages and a hierarchy underneath? You might want to allow access to the top-level item's messages but not allow access to the sub-hierarchy. Clearly the extended rights model is needed for that. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0wQqt064732 for ; Fri, 22 Aug 2003 17:58:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N0wQ3J064731 for ietf-imapext-bks; Fri, 22 Aug 2003 17:58:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0wPqt064726 for ; Fri, 22 Aug 2003 17:58:25 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.2b2) for ; Fri, 22 Aug 2003 19:58:27 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.0a29] Date: Fri, 22 Aug 2003 19:58:26 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: Point of order Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, let's please keep this discussion to what (if anything) *needs* to change in the current ACL2 spec. Technical discussion of that only. Whether a particular implementation or OS is holy or evil incarnate is not a necessary discussion. Thank you. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0lVqt064493 for ; Fri, 22 Aug 2003 17:47:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N0lVMB064492 for ietf-imapext-bks; Fri, 22 Aug 2003 17:47:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0lRqt064487 for ; Fri, 22 Aug 2003 17:47:27 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7N0koin003696; Fri, 22 Aug 2003 17:46:50 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7N0knFY020293; Fri, 22 Aug 2003 17:46:49 -0700 Date: Fri, 22 Aug 2003 17:46:49 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Rob Siemborski wrote: > > I'm not sure that I understand you. How does -T help you, as opposed to > > just seeing rights being tied? > Currently ACL2 allows rights to be tied in arbitrary ways. This results > in difficulty in presenting a UI and manipulating ACLs. Having only one > way of connecting rights removes this complexity. But what if the rights are in fact tied in arbitary ways, with no way to tie them any differently? Even if you say SHOULD NOT, this will still happen; having t does not necessarily mean that you have eswi. > We have this problem today with RFC2086 with > knowing when to report the READ-ONLY response code to SELECT. IMHO, the READ-ONLY response code to SELECT means that that PERMANENTFLAGS are per-user instead of global and EXPUNGE does nothing; that is, there is no change that the client can make that will affect another user's SELECT of the same mailbox. Consequently, READ-ONLY is orthogonal to ACL with the possible exception of stating that e is never part of an ACL. > If a user > has lrspa as their ACL, is it a READ-ONLY mailbox? Its totally unclear. If you accept my intepretation, then it remains unclear since the two are orthogonal. > 'R' and 'W' are just another way of expressing READ-ONLY. Not necessarily. I think that I want the dividing line to be "W makes changes that another user can see" (and thus would match READ-ONLY), but I can go along with "W means at a minimum that at least one PERMANENTFLAG is alterable." > It needs to be > clear exactly what 'R' and 'W' do. Without being able to state this on a per-mailbox basis, there is no single definition. If we say that "W makes changes that another user can see", then that is actually a separate status from other ACL bits and is useful to include. > And if you have that, you might as > well just stick to using the extended syntax (even if the client only > represents the basic syntax, and the server can only implement the > basic syntax). Well, why not just simplify tied rights so that a server can tie as it pleases, and reports the results. That is, instead of refusing to give a right until all tied rights are set, just give the additional rights for free, and require that all tied rights be revoked in order to revoke any. This is assuming that granting is more common than revoking, and that the revoke situation implies knowledge of the current rights (and thus how they are tied). > > That's a problem. There's a lot of these cases, many of which are > > situational (that is, it may tie one way in one mailbox and a different > > way in another). "s" is a great example. So is "e". > I know. But having 'R' and 'W' and allowing implementations to just pick > what they mean in the extended syntax (even with guidance from the RFC) > isn't any better. I disagree. The implementation is going to pick and choose what R and W means anyway since it's likely to be contextual. Even so, having R and W is better than having nothing at all. And if something better is needed, then use a server which has the full extended rights. > I didn't mean that. I meant that the behavior of the ACL model can be > predicted by a client trying to manipulate the ACL, and therefore be > able to present a reasonable UI. I agree with Cyrus; most end users are concerned with things at the R and W level. The "reasonable UI" is already going to reduce to R and W. It would be lovely if the client can decide what is R and what is W. But that may not be something that the client can decide. > At the minimum, anyone who uses > shared folders in any serious way realizes that you *do* want to have > at least separate control over manipulation of the data in the folder, and > manipulation of the hierarchy underneath the folder (accepting, of course, > that some mail stores do not allow folders with both contents and > subordinates). I already covered that possibility. R and W for foo means manipulate the data in the mailbox, where R and W for foo/ (or foo.) means manipulate the hierarchy underneath. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0CGqt063608 for ; Fri, 22 Aug 2003 17:12:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N0CG3E063607 for ietf-imapext-bks; Fri, 22 Aug 2003 17:12:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N0CEqt063602 for ; Fri, 22 Aug 2003 17:12:15 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX1.andrew.cmu.edu (MX1.andrew.cmu.edu [128.2.10.111]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7N0BtI3027445; Fri, 22 Aug 2003 20:11:55 -0400 Date: Fri, 22 Aug 2003 20:11:54 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Mark Crispin wrote: > On Fri, 22 Aug 2003, Rob Siemborski wrote: > > I think having R and W as separate rights could be unfortunate since it > > duplicates data representation. I'd much rather see the protocol using the > > advanced rights all the time, and using the "-T" in the ACL2 capability to > > indicate that the server forces the tying of rights. > > I'm not sure that I understand you. How does -T help you, as opposed to > just seeing rights being tied? Currently ACL2 allows rights to be tied in arbitrary ways. This results in difficulty in presenting a UI and manipulating ACLs. Having only one way of connecting rights removes this complexity. > > Offhand, it worries me because it means that we either have 2 ACL > > mechanisms 'basic' and 'extended' (bad) or we still need to be reporting > > back the extended rights that aren't set as the client expected (also > > bad). > > The only danger with having a basic mechanism is that it is very likely > that basic will become the de facto standard and nobody will do extended. This isn't the only danger. We have this problem today with RFC2086 with knowing when to report the READ-ONLY response code to SELECT. If a user has lrspa as their ACL, is it a READ-ONLY mailbox? Its totally unclear. 'R' and 'W' are just another way of expressing READ-ONLY. It needs to be clear exactly what 'R' and 'W' do. And if you have that, you might as well just stick to using the extended syntax (even if the client only represents the basic syntax, and the server can only implement the basic syntax). > That wouldn't happen if there was an competing ACL3. Lets please not talk about a third ACL mechanism until we're done with the second. > > I'd much rather say "-T" servers *always* tie "rls" and "wipcxted" (Or > > whatever semantics are agreed on, and I'm not sure how to handle 'a'), > > and have such implementations silently ignore rights [such as s] which > > they cannot accomplish (this would be a SHOULD NOT). > > That's a problem. There's a lot of these cases, many of which are > situational (that is, it may tie one way in one mailbox and a different > way in another). "s" is a great example. So is "e". I know. But having 'R' and 'W' and allowing implementations to just pick what they mean in the extended syntax (even with guidance from the RFC) isn't any better. > > This would give us a single ACL model that can be easily predicted by > > clients. > > I suspect that most clients do NOT depend upon ACL to determine if they > can do something or not. I think that most clients just try to do it. I didn't mean that. I meant that the behavior of the ACL model can be predicted by a client trying to manipulate the ACL, and therefore be able to present a reasonable UI. > I think that ACL is, and will be, used solely as a user control. And, as > Cyrus points out, the existing controls are far more complex than most > users desire, and that most users are happy with a four-way R and W > control. I don't think this is truly the case. At the minimum, anyone who uses shared folders in any serious way realizes that you *do* want to have at least separate control over manipulation of the data in the folder, and manipulation of the hierarchy underneath the folder (accepting, of course, that some mail stores do not allow folders with both contents and subordinates). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Uqt063426 for ; Fri, 22 Aug 2003 17:00:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N00UeY063425 for ietf-imapext-bks; Fri, 22 Aug 2003 17:00:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Sqt063415 for ; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id E00A5238907 for ; Sat, 23 Aug 2003 01:00:29 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 00:52:19 +0100 Message-Id: <5.2.1.1.2.20030823000040.06462740@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 00:21:25 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061560999@[10.0.1.8]> References: <3F4650A6.2020105@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 14:03 22/08/2003 -0400, Cyrus Daboo wrote: >| 1). Now to announce that the server supports a single user and/or group >| for a mailbox. > >Either this is part of the UNION/MOST-SPECIFIC profile or we have a >separate (additional) capability to announce the restriction: >ACL2=ONE-USERGROUP. Mark's suggestion (which I just saw) of using an >ABNF-style for the capability to be more flexible would be fine too. I'm not keen on the exact syntax (from an aesthetic point of view :-) ) but the idea is good (I don't like the '_'s - they don't exist anywhere else in IMAP) >| 2). "tied rights" debate and alternatives. > >Leave this as it is. In the basic case clients are not likely to expose >the entire set of rights to the user anyway. We do that now and it >confuses the hell out of anyone who is not a sysadmin. Instead clients >will likely have just a limited set of access options as the default: > >Read-Only (lrs) >Read-Write (lrswi) >Write-Only (li) 'drop-box' >No Access () This is actually the BIG problem I see with tied rights at the server. What if the client implements a set of tied rights, but the server implements an incompatible set of tied rights. Eg, if ACL2 stays at it is, but the server ties 'swite' together, That means that the example client above will not be able to set ANY rights apart from 'no access'... (Note that is just an example based on the example client tied rights above) To have arbitrary tied rights at the server the client needs to be able to give the full range of options available to the user, even if it ties them together in the UI somehow (eg by having several checkboxes tick on or off together) Having both client and server tied rights will cause all sorts of problems. They can either be at one end or the other, not really both. >| 3). Enumerating users/groups on the server > >Out-of-scope for ACL2. Should be addressed by another extension. Agreed (but I'd like to see progress on it, even if I have to get involved..) From a usability point of view, I see it as almost critical for the success of any ACL scheme. >| 4). Per-mailbox (per-hierarchy) access calculation models (as opposed to >| per-server) > >not sure... I think this is important if we're allowing tied rights at all. You could put the capabilities into the LIST command, or have a modified 'LISTRIGHTS' command (or an 'ACL-LIST' or similar) They should be per-mailbox rights, and should basically include tying groups and user/group properties, as well as the 'rule identifier' Per-hierarchy adds unnecessary complexity to the client and limitations to the server. Having the same user/group or tied rights groups limits the server. My suggestion would be: The CAPABILITY should just be 'ACL2' The LIST (ACL) command should return the ACL properties - from the client point of view, it will issue a 'LIST (ACL)' command to find what current settings to show to the user, so why not use the same command to return the properties eg * LIST () "/" INBOX (("ACL" "UNIX" "UNION" ("lr" "switextd" "p" "a") ("g*" "u") ("user=Fred" "rwipslextda"))) The bits following "ACL" are: - 'friendly name' for the rights scheme (in case the client wants to treat it specially), not sure about this, but I can't see any harm in it if they're registered - access calculation rule - rights groupings - EBNF style coding for groups/users etc (g? (0 or 1), g (1 exactly) g* (0 or more) g+ (1 or more)). Hmm, maybe it should be modified to be able to set a maximum number > 0 (eg 'g8' for maximum of 8 groups). You could be generic g0:1 g0 g1 g1:* g0:* g3:97 etc (who knows - if we're going to be flexible, why not be REALLY generic...) - current ACL setting list Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Sqt063417 for ; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N00SHB063414 for ietf-imapext-bks; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Mqt063396 for ; Fri, 22 Aug 2003 17:00:24 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 5AFFD238A91 for ; Sat, 23 Aug 2003 01:00:24 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 00:52:29 +0100 Message-Id: <5.2.1.1.2.20030823002341.062217d8@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 23 Aug 2003 00:25:34 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061550187@[192.168.42.6]> References: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:03 22/08/2003 -0600, you wrote: >On Friday, August 22, 2003 10:15 AM +0100 Paul Smith wrote: > >>The IMAP server is the only thing which KNOWS which users/groups are >>available > >Not necessarily. For example, it's (usually) not possible for an IMAP >server to enumerate all the principals in a Kerberos KDC. OK then, so maybe the IMAP server is the only thing which knows what DOES know :-) >There are also significant security implications to providing a complete >list of users. In some cases, yes, in other cases, there are big usability implications in not providing the list.. I agree it should be separate from ACL2. I also agree it should be optional, but I think it should be looked at. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Sqt063413 for ; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N00SRc063411 for ietf-imapext-bks; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Nqt063398 for ; Fri, 22 Aug 2003 17:00:24 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 81A2A238808 for ; Sat, 23 Aug 2003 01:00:25 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 00:52:08 +0100 Message-Id: <5.2.1.1.2.20030822235601.0678de70@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 23:57:33 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <3F464D58.8030501@isode.com> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:37 22/08/2003 -0500, Pete Resnick wrote: >On 8/22/03 at 6:05 PM +0100, Alexey Melnikov wrote: > >>I think there is a compelling case for working on generic ACL2 with tied >>rights (or a reasonable alternative), etc > >As I read this thread (the S/N ratio being not terribly helpful), leaving >aside all of the other issues that were already addressed, we had Larry >arguing that we should remove the tied rights stuff from the document, and >that's the only relevant part of this discussion to the WG moving forward. >Does anyone care to summarize the technical/operational argument for doing >so at this point? Do folks want to speak up in favor of such a change? I >am sticking with the presumption of leaving the document as-is unless >there is a consensus to change it. I can see a case for leaving tied rights in there. The case against it is primarily a complexity issue - having it in is more complex from a client point of view. I'd like to see another way of finding out about tied rights than the current RIGHTS-INFO response (which comes too late IMHO). I'd also like to see more info in there - eg the single/multiple user/group issue. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Sqt063416 for ; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7N00Scb063412 for ietf-imapext-bks; Fri, 22 Aug 2003 17:00:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7N00Mqt063397 for ; Fri, 22 Aug 2003 17:00:24 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id B2263238B00 for ; Sat, 23 Aug 2003 01:00:24 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Sat, 23 Aug 2003 00:52:01 +0100 Message-Id: <5.2.1.1.2.20030822235324.06329188@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 23:55:21 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <3F465277.90603@isode.com> References: <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 18:27 22/08/2003 +0100, Alexey Melnikov wrote: You could have >>ACL "FreeAndEasy" s w i t e l r p c x a g u >>which supports anything or >>ACL "VeryLimited" switecxa lr p u1 >>which has a 'read' and a 'write' mode only and only supports a single >>user and no groups >> >>For the Posix case, even if the client didn't understand that case >>specifically it could tie the 'swite' checkboxes (or whatever) together, >>and could only allow the selection of a single user, and multiple groups >>as the identifier. > >I think I mostly like this. >Also note, that currently RIGHTS-INFO response returns "switecxa lr p" >part of the >ACL "VeryLimited" switecxa lr p u1 Yes, I know (that's why I chose that syntax), but (IMHO) it's too late by then - RIGHTS-INFO only comes when an ACL-STORE command fails. It'd be better (from the client viewpoint) to be able to ask for it without having to come up with a failing ACL-STORE command and then undo it. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNigqt063022 for ; Fri, 22 Aug 2003 16:44:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MNigIp063021 for ietf-imapext-bks; Fri, 22 Aug 2003 16:44:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNieqt063016 for ; Fri, 22 Aug 2003 16:44:40 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNi3in030859; Fri, 22 Aug 2003 16:44:04 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNi35n016626; Fri, 22 Aug 2003 16:44:03 -0700 Date: Fri, 22 Aug 2003 16:44:03 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Rob Siemborski wrote: > I think having R and W as separate rights could be unfortunate since it > duplicates data representation. I'd much rather see the protocol using the > advanced rights all the time, and using the "-T" in the ACL2 capability to > indicate that the server forces the tying of rights. I'm not sure that I understand you. How does -T help you, as opposed to just seeing rights being tied? > Offhand, it worries me because it means that we either have 2 ACL > mechanisms 'basic' and 'extended' (bad) or we still need to be reporting > back the extended rights that aren't set as the client expected (also > bad). The only danger with having a basic mechanism is that it is very likely that basic will become the de facto standard and nobody will do extended. This prospect does not frighten me in the least. I suspect that it frightens you. The only answer/consolation that I can offer is that if we solve the problem in ACL2, extended capabilities will still be there. That wouldn't happen if there was an competing ACL3. > I'd much rather say "-T" servers *always* tie "rls" and "wipcxted" (Or > whatever semantics are agreed on, and I'm not sure how to handle 'a'), > and have such implementations silently ignore rights [such as s] which > they cannot accomplish (this would be a SHOULD NOT). That's a problem. There's a lot of these cases, many of which are situational (that is, it may tie one way in one mailbox and a different way in another). "s" is a great example. So is "e". > This would give us a single ACL model that can be easily predicted by > clients. I suspect that most clients do NOT depend upon ACL to determine if they can do something or not. I think that most clients just try to do it. I think that ACL is, and will be, used solely as a user control. And, as Cyrus points out, the existing controls are far more complex than most users desire, and that most users are happy with a four-way R and W control. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNVFqt062798 for ; Fri, 22 Aug 2003 16:31:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MNVFD1062797 for ietf-imapext-bks; Fri, 22 Aug 2003 16:31:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNVEqt062786 for ; Fri, 22 Aug 2003 16:31:14 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNV5in029384; Fri, 22 Aug 2003 16:31:11 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNV5S6015785; Fri, 22 Aug 2003 16:31:05 -0700 Date: Fri, 22 Aug 2003 16:31:05 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822232937.0551e300@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <5.2.1.1.2.20030822232937.0551e300@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > > > Or, Unix developers have to come to terms with having to do something > > > relatively simple such as running the IMAP server in its own account with > > > full access to the mailboxes and implementing their own (straightforward) > > > ACL system on top. > >That's about the worst idea from security point of view. A single bug in > >your server could mean that the attacker got full access to everyone's > >mail. Such a bug has already happened in the Cyrus server. I don't know if the exploit is still secret or not. > You could look at it the other way, and say that doing it that way means > that a bug in your server could ONLY affect the mailboxes, rather than all > the files on the computer.. No. You are presuming that there is a userid which is not root but which has access to all mail data. The only way to do that on UNIX is to make that userid be the owner of all mail data (which is what Cyrus does); but that precludes the shell user being the owner of his mail data. How much do you know about UNIX? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNRUqt062718 for ; Fri, 22 Aug 2003 16:27:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MNRUoW062717 for ietf-imapext-bks; Fri, 22 Aug 2003 16:27:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNRSqt062709 for ; Fri, 22 Aug 2003 16:27:29 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNRKCK018851; Fri, 22 Aug 2003 16:27:25 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MNRKi0015613; Fri, 22 Aug 2003 16:27:20 -0700 Date: Fri, 22 Aug 2003 16:27:20 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822172856.03cb4008@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> <5.2.1.1.2.20030822172856.03cb4008@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > > > Do people share the data using non-IMAP methods? > >Yes. Have you ever heard of something called "file sharing"? > With mailbox data? Yes. There is quite a bit of that. > >Oh? So you want the IMAP server to run as root? > No, as 'imapdaemon' or whatever, which has access to the mailbox > directories, but nothing else. There is no way to give user "imapdaemon" special rights over and above some other user or group, other than to make "imapdaemon" be root. What "mailbox directories" are you talking about? Are you still thinking about a black box type world in which mail is stored on a dedicated filesystem or other mechanism separate from the user's home directories? You can't presume that. > I could say 'only because that's what Unix developers give them'. In the > Windows world (and probably many others) people would find it very odd if > they COULD access mailbox files from other programs without causing > problems. Fortunately, UNIX and Windows are two different animals. My UNIX systems are deliciously immune from Sobig.F, other than receiving all the crap that is coming from infected Windows systems. I respectfully suggest that Windows is not making a particularly splendid case for emulation. > However, I think that if you're talking about needing to use the > full Unix command set on things like mailbox files, you're probably talking > about techie usage, rather than the average end-user. Wrong. Even ordinary UNIX users commonly use UNIX tools. UNIX is a different environment from Windows, and I strongly suggest that you read some books about the UNIX environment is used before making such statements. > That's valid, but > should techies restrict the features available to everyone else? Nobody is saying anything at all about *restricting*. Rather, the problem is that RFC 2086 type ACLs, for all their complexity, are too restricted to express UNIX semantics. > I never started off 'whacking' anyone - I was just commenting to messages > seemingly saying that any ACL standard had to bend over backwards to work > with Unix That's a straw man. Nobody has said that. > But, I think the client complexity issue has to be considered. Cyrus Daboo has already stated that for most users, RFC 2086 is much too complex and all that is needed are: read-only, read-write, write-only, and no access. I have no problem with that. I have a problem with the enforced complexity of RFC 2086 that simultaneously (because of its complex rules of inheritance) does not permit the simple setting of "read-only, read-write, write-only, and no access" for the owner, group members, and world. I also have a problem with the way that RFC 2086 overloaded identifiers (e.g. there is no way to distinguish a userid of "anyone" from world access). The current ACL2 document seems to fix these problems. That is a good thing. It would not be a good thing to turn around and create a new problem that was not in RFC 2086. Specifically, tied rights (which are in RFC 2086) can not be removed without a satisfactory substitute. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNBYqt062139 for ; Fri, 22 Aug 2003 16:11:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MNBYNa062138 for ietf-imapext-bks; Fri, 22 Aug 2003 16:11:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MNBWqt062133 for ; Fri, 22 Aug 2003 16:11:32 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GEL-FRAME.andrew.cmu.edu (GEL-FRAME.andrew.cmu.edu [128.2.120.180]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7MNBDI3027360; Fri, 22 Aug 2003 19:11:13 -0400 Date: Fri, 22 Aug 2003 19:11:13 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Mark Crispin wrote: > On Fri, 22 Aug 2003, Rob Siemborski wrote: > > How about another suggestion that takes this a step further. Add to > > Mark's ABNF the following (a trailing -T to indicate that the above 4 sets > > of rights are tied together, or alternatively something to indicate that > > all rights may be manipulated separately) > > How about using this as a mechanism for my "basic rights" suggestion, and > leave enough weasel-room via SHOULD to cover up any discrepancies caused > by an implementation that requires tying in a slightly different way. I was about to compose a message suggesting something similar (the two proposals do seem very close to me). I think having R and W as separate rights could be unfortunate since it duplicates data representation. I'd much rather see the protocol using the advanced rights all the time, and using the "-T" in the ACL2 capability to indicate that the server forces the tying of rights. > For example, I don't know if extended right "s" is really part of basic > right "R" or not, but I think that it should be. Someone else may have > reason to disagree. I can envision such circumstances myself. So, we say > SHOULD instead of MUST. This is, of course, the problem with the above solution. Offhand, it worries me because it means that we either have 2 ACL mechanisms 'basic' and 'extended' (bad) or we still need to be reporting back the extended rights that aren't set as the client expected (also bad). I'd much rather say "-T" servers *always* tie "rls" and "wipcxted" (Or whatever semantics are agreed on, and I'm not sure how to handle 'a'), and have such implementations silently ignore rights [such as s] which they cannot accomplish (this would be a SHOULD NOT). If implementations want more control, they should implement a server that doesn't advertise "-T". This would give us a single ACL model that can be easily predicted by clients. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMsKqt061728 for ; Fri, 22 Aug 2003 15:54:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMsKMA061727 for ietf-imapext-bks; Fri, 22 Aug 2003 15:54:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMsJqt061720 for ; Fri, 22 Aug 2003 15:54:19 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MMrfgG019571; Fri, 22 Aug 2003 15:53:41 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MMrfZS014043; Fri, 22 Aug 2003 15:53:41 -0700 Date: Fri, 22 Aug 2003 15:53:41 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Rob Siemborski wrote: > How about another suggestion that takes this a step further. Add to > Mark's ABNF the following (a trailing -T to indicate that the above 4 sets > of rights are tied together, or alternatively something to indicate that > all rights may be manipulated separately) How about using this as a mechanism for my "basic rights" suggestion, and leave enough weasel-room via SHOULD to cover up any discrepancies caused by an implementation that requires tying in a slightly different way. For example, I don't know if extended right "s" is really part of basic right "R" or not, but I think that it should be. Someone else may have reason to disagree. I can envision such circumstances myself. So, we say SHOULD instead of MUST. This also helps with read-only vs. read-write vs. write-only. Although I would normally say that basic right W includes extended rights w and i, perhaps it only includes extended right i if basic right R isn't present. But that's an implementation detail; for the user, a server which has just basic rights only has "read" and "write". We can call it a quality of implementation issue if it makes you happier. If the user really cares one way or another about "s" or "wi" vs "i", then he will demand a server implementation that supports extended rights. If a user just wants to set or clear "read access", a server that only has basic rights will be good enough. For those of you who claim that basic rights aren't good enough, I think that millions of UNIX users the world over who don't have POSIX ACLs (or have but don't use) will disagree. Basic rights may not be good enough for you, but control over basic rights are better than no control at all. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMrMqt061689 for ; Fri, 22 Aug 2003 15:53:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMrM3k061688 for ietf-imapext-bks; Fri, 22 Aug 2003 15:53:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMrKqt061683 for ; Fri, 22 Aug 2003 15:53:20 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 07C122449FF for ; Fri, 22 Aug 2003 23:50:18 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 23:42:05 +0100 Message-Id: <5.2.1.1.2.20030822172856.03cb4008@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 23:27:34 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:56 22/08/2003 -0700, you wrote: >On Fri, 22 Aug 2003, Paul Smith wrote: > > Do people share the data using non-IMAP methods? > >Yes. Have you ever heard of something called "file sharing"? With mailbox data? > > > 1) that all IMAP servers operate on dedicated IMAP-only boxes > > I didn't make that assumption at all. If access restrictions are strong (as > > they are on Unix) then the IMAP Server can run under one account which has > > full access to the mailbox. > >Oh? So you want the IMAP server to run as root? No, as 'imapdaemon' or whatever, which has access to the mailbox directories, but nothing else. > > > 4) that there is no need for non-IMAP type access (e.g. grep, sed, > > > editors) to mail files > > Hmm, I'd see that as a good assumption... I'd see it as bad to allow people > > to be able to edit raw message files... > >Too bad. This is what is there today. It can't be changed. >Basically, nothing shy of the full UNIX command language will do. I could say 'only because that's what Unix developers give them'. In the Windows world (and probably many others) people would find it very odd if they COULD access mailbox files from other programs without causing problems.. I don't want to get into an OS war, because I have no gripe with any OS. However, I think that if you're talking about needing to use the full Unix command set on things like mailbox files, you're probably talking about techie usage, rather than the average end-user. That's valid, but should techies restrict the features available to everyone else? Maybe that's one of the reasons Windows (which probably goes too far the OTHER way) is generally considered more usable. > > I would have less problem with being able to advertise an arbitrarily > > reduced ACL feature-set for those unable/unwilling to implement the full > > feature-set. > >This is exactly what I am talking about. Why then are you whacking me >with a strawman that is not my position? I never started off 'whacking' anyone - I was just commenting to messages seemingly saying that any ACL standard had to bend over backwards to work with Unix - which I disagree with. I said - come up with something that does what is needed (ACL2 seems to meet that criteria) then see if there's ways of tweaking it that will make it work with OSes, but without weakening the original design. But, I think the client complexity issue has to be considered. I've seen comments such as 'it makes things easier for server developers, the 'only thing that client developers have to worry about is to understand every server platform' which are not realistic. (I still think that a Unix IMAP server which was written to get around the filesystem restrictions (even if it imposed other restrictions for a few people - eg no file sharing of raw mailbox directories) would have a very strong USP) Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMqfqt061668 for ; Fri, 22 Aug 2003 15:52:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMqfCg061667 for ietf-imapext-bks; Fri, 22 Aug 2003 15:52:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMqeqt061662 for ; Fri, 22 Aug 2003 15:52:40 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 54783244786 for ; Fri, 22 Aug 2003 23:50:09 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 23:43:41 +0100 Message-Id: <5.2.1.1.2.20030822232937.0551e300@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 23:31:56 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <1061564263.24982.166.camel@hurina> References: <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 17:57 22/08/2003 +0300, you wrote: >On Fri, 2003-08-22 at 11:50, Paul Smith wrote: > > > Or, Unix developers have to come to terms with having to do something > > relatively simple such as running the IMAP server in its own account with > > full access to the mailboxes and implementing their own (straightforward) > > ACL system on top. > >That's about the worst idea from security point of view. A single bug in >your server could mean that the attacker got full access to everyone's >mail. You could look at it the other way, and say that doing it that way means that a bug in your server could ONLY affect the mailboxes, rather than all the files on the computer.. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMdcqt061373 for ; Fri, 22 Aug 2003 15:39:38 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMdcRt061372 for ietf-imapext-bks; Fri, 22 Aug 2003 15:39:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMdbqt061365 for ; Fri, 22 Aug 2003 15:39:37 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MMd5oa012420; Fri, 22 Aug 2003 15:39:05 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MMd5cK013198; Fri, 22 Aug 2003 15:39:05 -0700 Date: Fri, 22 Aug 2003 15:39:05 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> <2147483647.1061558528@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Rob Siemborski wrote: > This is more along the lines of what I was going for when I suggested > ACL2=UNIX (the suggested name, of course, bearing unintended > connotations). Mark's later ABNF example is also okay with me. Are we moving toward concensus here? I think that it would be a terrible mistake to have something that is specific to UNIX. However, anything that tells the client how rights work on the server is good. > Of course, this doesn't solve the complexity issue with tied rights. RFC 2086 had tied rights; it isn't as if this is something new. Strawman solution: I would be happy to see a set of "basic rights" defined in addition to the "advanced rights". Following Cyrus' four-way list: read-only read-write write-only ("drop-box") no access we have just two basic rights: R and W (are rights case-dependent? If not, then other names are needed). Basic rights can also be applied to a level of hierarchy, by appending the hierarchy delimiter to the name ala CREATE. In this case, R means "can list inferiors" and W means "can create inferiors". This is more or less trivial to implement almost anywhere. On systems such as TOPS-20 which support per-mailbox invisible status, I'd have a problem, but I'm willing to swallow that pill. Basic rights are simple. Perhaps too simple, but they get rid of tied rights and let us move forward. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMQiqt060647 for ; Fri, 22 Aug 2003 15:26:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMQifY060646 for ietf-imapext-bks; Fri, 22 Aug 2003 15:26:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMQgqt060641 for ; Fri, 22 Aug 2003 15:26:42 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7MMQLI3027289; Fri, 22 Aug 2003 18:26:21 -0400 Date: Fri, 22 Aug 2003 18:26:22 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Alexey Melnikov , Mark Crispin , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061560999@[10.0.1.8]> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Cyrus Daboo wrote: > | 2). "tied rights" debate and alternatives. > > Leave this as it is. In the basic case clients are not likely to expose the > entire set of rights to the user anyway. We do that now and it confuses the > hell out of anyone who is not a sysadmin. Instead clients will likely have > just a limited set of access options as the default: > > Read-Only (lrs) > Read-Write (lrswi) > Write-Only (li) 'drop-box' > No Access () You probably want 'p' in Read-Write and Write-Only. Leaving this as it is still complicates the protocol unnecessarily. > i.e. the client effectively implements its own set of tied rights. > > The client can offer a more advanced UI for admins if the need arises. And > in that case it can find a way to express the server's tied-rights > capability in the more complex UI. How about another suggestion that takes this a step further. Add to Mark's ABNF the following (a trailing -T to indicate that the above 4 sets of rights are tied together, or alternatively something to indicate that all rights may be manipulated separately): A UNIX server: ACL2=MOST-SPECIFIC=U_G_O-T A fancier UNIX server with authuser vs. anyone (anonymous) support: ACL2=MOST-SPECIFIC=U_G_O_A-T A Cyrus server: ACL2=UNION=*U_*G_O A Cyrus server with authuser vs. anymous (anonymous) support: ACL2=UNION=*U_*G_O_A A TOPS-20 server [I'm not personally sure, but guessing]: ACL2=UNION=U_*G_O-T This removes the protocol and interface complications of arbitrary tied rights. The client knows in advance *exactly* what rights need to be set and removed together, and can present an appropriate UI. Of course, someone will now point out some implementation that requires tying the rights together in a different way... > NB I would find it useful if this document could actually specify what set > of rights should appear in the basic set I outlined above because I think a > lot of clients will present it that way. In particular what set of rights > should be used for 'Read-Write' - should they include 't' and/or 'e'? This > could appear in an 'implementation guide' section in the document. This needs to be done in any case. > | 4). Per-mailbox (per-hierarchy) access calculation models (as opposed to > | per-server) > > not sure... If this isn't addressed by ACL2, we need to leave a way for it to be extended without bringing up ACL3. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMDaqt060072 for ; Fri, 22 Aug 2003 15:13:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MMDYLo060071 for ietf-imapext-bks; Fri, 22 Aug 2003 15:13:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MMDWqt060064 for ; Fri, 22 Aug 2003 15:13:33 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7MMCsI3027270; Fri, 22 Aug 2003 18:12:54 -0400 Date: Fri, 22 Aug 2003 18:12:55 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Mark Crispin , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061558528@[10.0.1.8]> Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> <2147483647.1061558528@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Cyrus Daboo wrote: > ACL2=UNION > user= no limit > group= no limit > > ACL2=MOST-SPECIFIC > user= 1 always present > group= 1 always present > > Or if needs be we add another ACL2= capability that expresses the > restricted user=/group= model: ACL2=UGO (for user/group/others model) - > that would be added to the capabilities along with either of UNION or > MOST-SPECIFIC. This is more along the lines of what I was going for when I suggested ACL2=UNIX (the suggested name, of course, bearing unintended connotations). Mark's later ABNF example is also okay with me. Of course, this doesn't solve the complexity issue with tied rights. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MIOYqt051839 for ; Fri, 22 Aug 2003 11:24:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MIOYM2051838 for ietf-imapext-bks; Fri, 22 Aug 2003 11:24:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MIOSqt051824 for ; Fri, 22 Aug 2003 11:24:28 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MINmgG014449; Fri, 22 Aug 2003 11:23:48 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MINmY0023300; Fri, 22 Aug 2003 11:23:48 -0700 Date: Fri, 22 Aug 2003 11:23:48 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061560999@[10.0.1.8]> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> <2147483647.1061560999@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Cyrus Daboo wrote: > | 1). Now to announce that the server supports a single user and/or group > | for a mailbox. > Either this is part of the UNION/MOST-SPECIFIC profile or we have a > separate (additional) capability to announce the restriction: > ACL2=ONE-USERGROUP. Mark's suggestion (which I just saw) of using an > ABNF-style for the capability to be more flexible would be fine too. Mind you, that was just a strawman to show that this isn't an intractable problem. I'm fine with any other solution, although being more flexible seems to be a good idea in general > | 2). "tied rights" debate and alternatives. > Leave this as it is. In the basic case clients are not likely to expose the > entire set of rights to the user anyway. We do that now and it confuses the > hell out of anyone who is not a sysadmin. Instead clients will likely have > just a limited set of access options as the default: > Read-Only (lrs) > Read-Write (lrswi) > Write-Only (li) 'drop-box' > No Access () Golly gee. That's the precise 99% case that I'm talking about!! If I were to do an ACL3, I would have just those four rights. Also, a "dual-use" name would have its "mailbox rights" and its "inferior rights", which would take care of list and create; there is a need for invisible mailboxes especially with drop-boxes. Everything else is fluff for most users. > | 3). Enumerating users/groups on the server > Out-of-scope for ACL2. Should be addressed by another extension. Agreed. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MI3Eqt051199 for ; Fri, 22 Aug 2003 11:03:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MI3EHi051198 for ietf-imapext-bks; Fri, 22 Aug 2003 11:03:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MI3Cqt051192 for ; Fri, 22 Aug 2003 11:03:13 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA01724; Fri, 22 Aug 2003 13:59:12 -0400 (EDT) Date: Fri, 22 Aug 2003 14:03:19 -0400 From: Cyrus Daboo To: Alexey Melnikov , Mark Crispin cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061560999@[10.0.1.8]> In-Reply-To: <3F4650A6.2020105@isode.com> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> <3F4650A6.2020105@isode.com> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Friday, August 22, 2003 6:19 PM +0100 Alexey Melnikov wrote: | 1). Now to announce that the server supports a single user and/or group | for a mailbox. Either this is part of the UNION/MOST-SPECIFIC profile or we have a separate (additional) capability to announce the restriction: ACL2=ONE-USERGROUP. Mark's suggestion (which I just saw) of using an ABNF-style for the capability to be more flexible would be fine too. | 2). "tied rights" debate and alternatives. Leave this as it is. In the basic case clients are not likely to expose the entire set of rights to the user anyway. We do that now and it confuses the hell out of anyone who is not a sysadmin. Instead clients will likely have just a limited set of access options as the default: Read-Only (lrs) Read-Write (lrswi) Write-Only (li) 'drop-box' No Access () i.e. the client effectively implements its own set of tied rights. The client can offer a more advanced UI for admins if the need arises. And in that case it can find a way to express the server's tied-rights capability in the more complex UI. NB I would find it useful if this document could actually specify what set of rights should appear in the basic set I outlined above because I think a lot of clients will present it that way. In particular what set of rights should be used for 'Read-Write' - should they include 't' and/or 'e'? This could appear in an 'implementation guide' section in the document. | 3). Enumerating users/groups on the server Out-of-scope for ACL2. Should be addressed by another extension. | 4). Per-mailbox (per-hierarchy) access calculation models (as opposed to | per-server) not sure... -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHp4qt050845 for ; Fri, 22 Aug 2003 10:51:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHp4m2050844 for ietf-imapext-bks; Fri, 22 Aug 2003 10:51:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHp3qt050836 for ; Fri, 22 Aug 2003 10:51:03 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHovgG009045; Fri, 22 Aug 2003 10:50:58 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHovhY019105; Fri, 22 Aug 2003 10:50:57 -0700 Date: Fri, 22 Aug 2003 10:50:57 -0700 (PDT) From: Mark Crispin To: Pete Resnick cc: Alexey Melnikov , Steve Hole , Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Pete Resnick wrote: > we > had Larry arguing that we should remove the tied rights stuff from > the document, and that's the only relevant part of this discussion to > the WG moving forward. Does anyone care to summarize the > technical/operational argument for doing so at this point? Do folks > want to speak up in favor of such a change? I speak up against it. It is harmful. Tied rights were in RFC 2086. The effect of removing tied rights from ACL2 (or at least doing so without an acceptable alternative) would have the effect of rendering the other changes of ACL2 moot from my perspective. An example of an acceptable alternative would be to make r, w, and a the only mandatory-to-implement rights; meaning that s and t are implicitly part of the w right. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHnFqt050782 for ; Fri, 22 Aug 2003 10:49:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHnF6i050781 for ietf-imapext-bks; Fri, 22 Aug 2003 10:49:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHnEqt050775 for ; Fri, 22 Aug 2003 10:49:14 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7MHnC63027063; Fri, 22 Aug 2003 11:49:12 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Fri, 22 Aug 2003 11:49:12 -0600 From: Lyndon Nerenberg To: Timo Sirainen cc: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061552952@[192.168.42.6]> In-Reply-To: <54ED396C-D4C5-11D7-8B96-000393CC2E90@iki.fi> References: <54ED396C-D4C5-11D7-8B96-000393CC2E90@iki.fi> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7MHnEqt050777 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The problem with this is that you most likely want to see the full > message, or at least the message headers. After that grep you'd have to > use less and search the pattern again to see the full message. [We're really getting off topic here, but ...] Thanks for making my point: # display full (raw) text of matching messages grep -r -l -i pattern ~/Mail | xargs less # display just the headers of matching messages grep -r -l -i pattern ~/Mail | xargs sed -e '1,/^$/xGpq' | less > echo "1 list * | search from someone body hello | fetch > body.peek[header.fields (subject)] body.peek[text]<0.1000>" | imap > | less The RTTs associated with the several hundred SELECTS (one per folder searched) are what will kill you. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHl9qt050685 for ; Fri, 22 Aug 2003 10:47:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHl9q1050684 for ietf-imapext-bks; Fri, 22 Aug 2003 10:47:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHl7qt050679 for ; Fri, 22 Aug 2003 10:47:08 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA01405; Fri, 22 Aug 2003 13:43:03 -0400 (EDT) Date: Fri, 22 Aug 2003 13:47:11 -0400 From: Cyrus Daboo To: Lyndon Nerenberg , Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061560031@[10.0.1.8]> In-Reply-To: <2147483647.1061550187@[192.168.42.6]> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <2147483647.1061550187@[192.168.42.6]> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Lyndon, --On Friday, August 22, 2003 11:03 AM -0600 Lyndon Nerenberg wrote: |> The IMAP server is the only thing which KNOWS which users/groups are |> available | | Not necessarily. For example, it's (usually) not possible for an IMAP | server to enumerate all the principals in a Kerberos KDC. | | There are also significant security implications to providing a complete | list of users. Agreed. I think all the client needs to be able to do is map an ACL uid into some type of 'friendly name'. That could easily be done by providing a mapping between an email address (which will likely have the 'friendly name' associated with it via an address book/directory service in the client) and the ACL uid. Whether that is done through IMAP or via some other route is open for debate. I think one proposal was to simply have the IMAP server return a uri indicating the appropriate way to do that mapping. That could point to an LDAP server and include a search spec/schema etc for doing the mapping in each direction, or it could indicate the presence of an IMAP command that would do the mapping via IMP itself. In any case this is not for ACL2 but some other extension... -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHgGqt050318 for ; Fri, 22 Aug 2003 10:42:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHgGMu050317 for ietf-imapext-bks; Fri, 22 Aug 2003 10:42:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHgFqt050312 for ; Fri, 22 Aug 2003 10:42:15 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 18:41:35 +0100 Message-ID: <3F4655CC.50408@isode.com> Date: Fri, 22 Aug 2003 18:41:32 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: Mark Crispin , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> <2147483647.1061558528@[10.0.1.8]> In-Reply-To: <2147483647.1061558528@[10.0.1.8]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > > Hi Mark, > > --On Friday, August 22, 2003 9:58 AM -0700 Mark Crispin > wrote: > > |> > Mark, do you have a strawman for such a proposal? Since each of the > |> > proposals served up by the "RFC 2086 camp" are getting volleyed > back, > |> > perhaps its time for a proposal from the "UNIX ACL camp". ;) > |> For better or worse, the current ACL2 document seems to address the > |> problem. We could simply sign off on ACL2, declare victory, and go > home. > | > | In case it wasn't clear, that *is* my proposal. > | > | Put another way: end the Byzantine argument, sign off on the current > ACL2 > | document as-is, declare victory, and go home. > > I am almost OK with ACL2, but my big concern is still translating this > into something that will be useable in a client. I don't want to > present a UI to a user that allows them to do something the server > does not support - i.e. try and set ACLs for multiple user='s when the > server only allows one user/group etc. Right now ACL2 is not specific > enough in pinning down the allowed behaviour of identifiers - > specifically how many user/group identifiers are allowed in any one > ACL. If we can simply address that I will be happy. This could simply > be done by stating the maximum number of allowed user= or group= > identifiers for each profile, i.e.: > > ACL2=UNION > user= no limit > group= no limit > > ACL2=MOST-SPECIFIC > user= 1 always present > group= 1 always present > > Or if needs be we add another ACL2= capability that expresses the > restricted user=/group= model: ACL2=UGO (for user/group/others model) > - that would be added to the capabilities along with either of UNION > or MOST-SPECIFIC. > I've just replied to Paul that I like his suggestion. What you propose (the latter, as I think the number of users/groups allowed is actually orthogonal to access calculation model. Of course just having one user/group make it simpler) will work for me too. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHeLqt050246 for ; Fri, 22 Aug 2003 10:40:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHeL3X050245 for ietf-imapext-bks; Fri, 22 Aug 2003 10:40:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHeKqt050234 for ; Fri, 22 Aug 2003 10:40:20 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHdcCK002469; Fri, 22 Aug 2003 10:39:38 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHdcEj018412; Fri, 22 Aug 2003 10:39:38 -0700 Date: Fri, 22 Aug 2003 10:39:37 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061558528@[10.0.1.8]> Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> <2147483647.1061558528@[10.0.1.8]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Cyrus Daboo wrote: > Right now ACL2 is not specific enough in pinning down the > allowed behaviour of identifiers - specifically how many user/group > identifiers are allowed in any one ACL. If we can simply address that I > will be happy. Sounds good to me. > This could simply be done by stating the maximum number of > allowed user= or group= identifiers for each profile Is it really true that all ACL2=UNION will have no limit and all ACL2=MOST-SPECIFIC will be fixed at 1? Suggest some way that the server can indicate this. After all, ABNF has foo always one foo *foo zero or more foo's 1*foo one or more foo's so it isn't as if we don't know how to express this concept in a concise way. > Or if needs be we add another ACL2= capability that expresses the > restricted user=/group= model: ACL2=UGO (for user/group/others model) - > that would be added to the capabilities along with either of UNION or > MOST-SPECIFIC. What about just one user, but zero or more groups? Using ABNF, maybe we could have something like: A UNIX server: ACL2=MOST-SPECIFIC=U_G_O A fancier UNIX server with authuser vs. anyone (anonymous) support: ACL2=MOST-SPECIFIC=U_G_O_A A Cyrus server: ACL2=UNION=*U_*G_O A Cyrus server with authuser vs. anymous (anonymous) support: ACL2=UNION=*U_*G_O_A A TOPS-20 server: ACL2=UNION=U_*G_O -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHbMqt050143 for ; Fri, 22 Aug 2003 10:37:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHbMuU050142 for ietf-imapext-bks; Fri, 22 Aug 2003 10:37:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHbLqt050136 for ; Fri, 22 Aug 2003 10:37:21 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.2b2); Fri, 22 Aug 2003 12:37:22 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <3F464D58.8030501@isode.com> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> X-Mailer: Eudora [Macintosh version 6.0a29] Date: Fri, 22 Aug 2003 12:37:19 -0500 To: Alexey Melnikov From: Pete Resnick Subject: Re: acl-08: questions Cc: Mark Crispin , Steve Hole , Paul Smith , ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 8/22/03 at 6:05 PM +0100, Alexey Melnikov wrote: >I think there is a compelling case for working on generic ACL2 with >tied rights (or a reasonable alternative), etc As I read this thread (the S/N ratio being not terribly helpful), leaving aside all of the other issues that were already addressed, we had Larry arguing that we should remove the tied rights stuff from the document, and that's the only relevant part of this discussion to the WG moving forward. Does anyone care to summarize the technical/operational argument for doing so at this point? Do folks want to speak up in favor of such a change? I am sticking with the presumption of leaving the document as-is unless there is a consensus to change it. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHRbqt049617 for ; Fri, 22 Aug 2003 10:27:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHRbQM049616 for ietf-imapext-bks; Fri, 22 Aug 2003 10:27:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHRaqt049610 for ; Fri, 22 Aug 2003 10:27:36 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 18:27:25 +0100 Message-ID: <3F465277.90603@isode.com> Date: Fri, 22 Aug 2003 18:27:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Smith CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> In-Reply-To: <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Smith wrote: > > At 14:42 22/08/2003 +0100, Alexey Melnikov wrote: > >> Paul Smith wrote: >> >>> Maybe the server should be able to say exactly what rights it >>> allows, eg 'I support xyz rights', and if server developers want to >>> be restricted by the 'one user/one group/anyone' Unix problem, maybe >>> that could be another limit that the server could advertise, in a >>> general way that can be designed. That wouldn't be too bad - but >>> don't make it OS specific. >> >> >> I agree. >> >> My own position on this that a client should be able to >> a). Implement a basic UI for showing/modifying ACLs without a >> knowledge of the access calculation model being used by the server. >> We should be aiming to add all required commands/responses to achieve >> this. >> b). Implement an advanced UI for particular model(s) that the client >> recognizes. > > > How about, in either the LIST responses or a separate 'ACL-CAPA' > response having something like > ACL "Posix" swite lr p cx a g u1 > This could indicate that this mailbox is 'Unix' (in case someone wants > to have an advanced UI for that type) , and the 'swite' 'lr' 'p' 'cx' > 'a' rights are tied together, it supports multiple groups and a single > user > > You could have > ACL "FreeAndEasy" s w i t e l r p c x a g u > which supports anything or > ACL "VeryLimited" switecxa lr p u1 > which has a 'read' and a 'write' mode only and only supports a single > user and no groups > > For the Posix case, even if the client didn't understand that case > specifically it could tie the 'swite' checkboxes (or whatever) > together, and could only allow the selection of a single user, and > multiple groups as the identifier. I think I mostly like this. Also note, that currently RIGHTS-INFO response returns "switecxa lr p" part of the ACL "VeryLimited" switecxa lr p u1 Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHNoqt049458 for ; Fri, 22 Aug 2003 10:23:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHNoc1049457 for ietf-imapext-bks; Fri, 22 Aug 2003 10:23:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHNnqt049447 for ; Fri, 22 Aug 2003 10:23:49 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 515E7238CB; Fri, 22 Aug 2003 20:23:42 +0300 (EEST) Received: from iki.fi (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 5CA0423994; Fri, 22 Aug 2003 20:23:10 +0300 (EEST) Date: Fri, 22 Aug 2003 20:23:22 +0300 Subject: Re: acl-08: questions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Paul Smith , ietf-imapext@imc.org To: Lyndon Nerenberg From: Timo Sirainen In-Reply-To: <2147483647.1061549681@[192.168.42.6]> Message-Id: <54ED396C-D4C5-11D7-8B96-000393CC2E90@iki.fi> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7MHNnqt049452 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, Aug 22, 2003, at 19:54 Europe/Helsinki, Lyndon Nerenberg wrote: > Time has shown that monolithic tools just don't scale or provide the > power that a group of ad hoc simple tools can provide. This is the > power of UNIX. MH has this philosophy at its core. This again brings to my mind mail selection / action separation. I'm not sure how reasonably IMAP could be extended to do it, or if anyone else actually even would like to do it, but I've often wanted it when searching mails. > grep -r -i 'pattern' ${HOME}/Mail > > There is absolutely no way doing this search through IMAP will be even > close to as fast as that grep command. The problem with this is that you most likely want to see the full message, or at least the message headers. After that grep you'd have to use less and search the pattern again to see the full message. I'd much rather do something like this: echo "1 list * | search from someone body hello | fetch body.peek[header.fields (subject)] body.peek[text]<0.1000>" | imap | less I think it should even be possible to implement this in backwards compatible way. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHLwqt049391 for ; Fri, 22 Aug 2003 10:21:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHLwOV049390 for ietf-imapext-bks; Fri, 22 Aug 2003 10:21:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHLvqt049383 for ; Fri, 22 Aug 2003 10:21:57 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA00935; Fri, 22 Aug 2003 13:18:00 -0400 (EDT) Date: Fri, 22 Aug 2003 13:22:08 -0400 From: Cyrus Daboo To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061558528@[10.0.1.8]> In-Reply-To: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Friday, August 22, 2003 9:58 AM -0700 Mark Crispin wrote: |> > Mark, do you have a strawman for such a proposal? Since each of the |> > proposals served up by the "RFC 2086 camp" are getting volleyed back, |> > perhaps its time for a proposal from the "UNIX ACL camp". ;) |> For better or worse, the current ACL2 document seems to address the |> problem. We could simply sign off on ACL2, declare victory, and go home. | | In case it wasn't clear, that *is* my proposal. | | Put another way: end the Byzantine argument, sign off on the current ACL2 | document as-is, declare victory, and go home. I am almost OK with ACL2, but my big concern is still translating this into something that will be useable in a client. I don't want to present a UI to a user that allows them to do something the server does not support - i.e. try and set ACLs for multiple user='s when the server only allows one user/group etc. Right now ACL2 is not specific enough in pinning down the allowed behaviour of identifiers - specifically how many user/group identifiers are allowed in any one ACL. If we can simply address that I will be happy. This could simply be done by stating the maximum number of allowed user= or group= identifiers for each profile, i.e.: ACL2=UNION user= no limit group= no limit ACL2=MOST-SPECIFIC user= 1 always present group= 1 always present Or if needs be we add another ACL2= capability that expresses the restricted user=/group= model: ACL2=UGO (for user/group/others model) - that would be added to the capabilities along with either of UNION or MOST-SPECIFIC. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHK3qt049317 for ; Fri, 22 Aug 2003 10:20:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHK3d3049316 for ietf-imapext-bks; Fri, 22 Aug 2003 10:20:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHK2qt049307 for ; Fri, 22 Aug 2003 10:20:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 18:19:38 +0100 Message-ID: <3F4650A6.2020105@isode.com> Date: Fri, 22 Aug 2003 18:19:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Let's now talk about the list of open issues: 1). Now to announce that the server supports a single user and/or group for a mailbox. 2). "tied rights" debate and alternatives. 3). Enumerating users/groups on the server 4). Per-mailbox (per-hierarchy) access calculation models (as opposed to per-server) Have I forgotten anything? Mark Crispin wrote: >On Fri, 22 Aug 2003, Alexey Melnikov wrote: > > >>I think there is a compelling case for working on generic ACL2 with tied >>rights (or a reasonable alternative), etc even if we disagree whether >>using a filesystem ACL implementation is a good idea. >> >> > >Agreed. > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHFaqt049191 for ; Fri, 22 Aug 2003 10:15:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHFagV049190 for ietf-imapext-bks; Fri, 22 Aug 2003 10:15:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHFYqt049174 for ; Fri, 22 Aug 2003 10:15:35 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7MHFQri007765; Fri, 22 Aug 2003 13:15:28 -0400 (EDT) Message-ID: <3F465025.30703@oceana.com> Date: Fri, 22 Aug 2003 13:17:25 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Fri, 22 Aug 2003, Mark Crispin wrote: > >>>Mark, do you have a strawman for such a proposal? Since each of the >>>proposals served up by the "RFC 2086 camp" are getting volleyed back, >>>perhaps its time for a proposal from the "UNIX ACL camp". ;) >> >>For better or worse, the current ACL2 document seems to address the >>problem. We could simply sign off on ACL2, declare victory, and go home. > > > In case it wasn't clear, that *is* my proposal. Got it. For some reason I thought you weren't happy with the current ACL2. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHCuqt049038 for ; Fri, 22 Aug 2003 10:12:56 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHCtno049037 for ietf-imapext-bks; Fri, 22 Aug 2003 10:12:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHCrqt049027 for ; Fri, 22 Aug 2003 10:12:53 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHCnoa029019; Fri, 22 Aug 2003 10:12:49 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHCn1i017038; Fri, 22 Aug 2003 10:12:49 -0700 Date: Fri, 22 Aug 2003 10:12:49 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov cc: Steve Hole , Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F464D58.8030501@isode.com> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <3F464D58.8030501@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Alexey Melnikov wrote: > I think there is a compelling case for working on generic ACL2 with tied > rights (or a reasonable alternative), etc even if we disagree whether > using a filesystem ACL implementation is a good idea. Agreed. I don't seek to convince anyone that a filesystem ACL implementation is a good idea. I just seek to have a generic ACL2 which does not preclude implementation through the filesystem. The current ACL2 document seems to fufill that requirement. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHAFqt048927 for ; Fri, 22 Aug 2003 10:10:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHAFBE048926 for ietf-imapext-bks; Fri, 22 Aug 2003 10:10:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHACqt048917 for ; Fri, 22 Aug 2003 10:10:13 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHA7oa028605; Fri, 22 Aug 2003 10:10:07 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MHA737016988; Fri, 22 Aug 2003 10:10:07 -0700 Date: Fri, 22 Aug 2003 10:10:07 -0700 (PDT) From: Mark Crispin To: Lyndon Nerenberg cc: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061549681@[192.168.42.6]> Message-ID: References: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> <2147483647.1061549681@[192.168.42.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Lyndon Nerenberg wrote: > Time has shown that monolithic tools just don't scale or provide the > power that a group of ad hoc simple tools can provide. This is the power > of UNIX. Amen to that. > If all you do is read and delete your e-mail, it's hard to understand why > this matters. If you use e-mail to the n'th degree, you quickly come to > appreciate the power and flexibility of having an arsenal of tools, and > you will use whichever tool is appropriate to solving a specific problem. Amen once again. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MH67qt048815 for ; Fri, 22 Aug 2003 10:06:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MH67qX048814 for ietf-imapext-bks; Fri, 22 Aug 2003 10:06:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MH65qt048808 for ; Fri, 22 Aug 2003 10:06:06 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 18:05:33 +0100 Message-ID: <3F464D58.8030501@isode.com> Date: Fri, 22 Aug 2003 18:05:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Steve Hole , Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: May I suggest that we stop this particular debate, as this is not productive. I think there is a compelling case for working on generic ACL2 with tied rights (or a reasonable alternative), etc even if we disagree whether using a filesystem ACL implementation is a good idea. Mark Crispin wrote: >On Fri, 22 Aug 2003, Steve Hole wrote: > > >>In fact, I would claim that what you are >>attempting is to use IMAP as a backdoor access control management protocol >>for regular UNIX files. >> >> > >That is true, just as IMAP is a backdoor file access mechanism for regular >files that just happen to contain messages. > >If you wish to change IMAP into something else, such as an operating >system, then you should realize that you are changing IMAP in a >fundamental way from what its creator intended. > >And by changing IMAP into something that it was never intended to be, it >will suck. It will cease to be the useful thing that it was intended to >be at its creation, and it will never be as good as something like >Exchange (note the recent Microsoft quote) which was intended to be the >other thing from its inception. > > > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MH38qt048715 for ; Fri, 22 Aug 2003 10:03:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MH38ix048714 for ietf-imapext-bks; Fri, 22 Aug 2003 10:03:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MH36qt048709 for ; Fri, 22 Aug 2003 10:03:06 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7MH3763026782; Fri, 22 Aug 2003 11:03:07 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Fri, 22 Aug 2003 11:03:07 -0600 From: Lyndon Nerenberg To: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061550187@[192.168.42.6]> In-Reply-To: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, August 22, 2003 10:15 AM +0100 Paul Smith wrote: > The IMAP server is the only thing which KNOWS which users/groups are > available Not necessarily. For example, it's (usually) not possible for an IMAP server to enumerate all the principals in a Kerberos KDC. There are also significant security implications to providing a complete list of users. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGxDqt048560 for ; Fri, 22 Aug 2003 09:59:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MGxDOj048559 for ietf-imapext-bks; Fri, 22 Aug 2003 09:59:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGxCqt048554 for ; Fri, 22 Aug 2003 09:59:12 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7MGxD63026748; Fri, 22 Aug 2003 10:59:13 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Fri, 22 Aug 2003 10:59:13 -0600 From: Lyndon Nerenberg To: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061549953@[192.168.42.6]> In-Reply-To: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thursday, August 21, 2003 5:26 PM +0100 Paul Smith wrote: > What other INTERNET protocol can you think of that requires clients to > behave differently depending on what OS their server is running on? FTP. (The TYPE and STRU commands.) --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGwtqt048550 for ; Fri, 22 Aug 2003 09:58:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MGwtZ1048549 for ietf-imapext-bks; Fri, 22 Aug 2003 09:58:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGwsqt048534 for ; Fri, 22 Aug 2003 09:58:54 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MGwnxu019340; Fri, 22 Aug 2003 09:58:49 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MGwnda016538; Fri, 22 Aug 2003 09:58:49 -0700 Date: Fri, 22 Aug 2003 09:58:49 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Mark Crispin wrote: > > Mark, do you have a strawman for such a proposal? Since each of the > > proposals served up by the "RFC 2086 camp" are getting volleyed back, > > perhaps its time for a proposal from the "UNIX ACL camp". ;) > For better or worse, the current ACL2 document seems to address the > problem. We could simply sign off on ACL2, declare victory, and go home. In case it wasn't clear, that *is* my proposal. Put another way: end the Byzantine argument, sign off on the current ACL2 document as-is, declare victory, and go home. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGsgqt048434 for ; Fri, 22 Aug 2003 09:54:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MGsgA6048433 for ietf-imapext-bks; Fri, 22 Aug 2003 09:54:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGsfqt048428 for ; Fri, 22 Aug 2003 09:54:41 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7MGsf63026705; Fri, 22 Aug 2003 10:54:41 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Fri, 22 Aug 2003 10:54:41 -0600 From: Lyndon Nerenberg To: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061549681@[192.168.42.6]> In-Reply-To: <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> References: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> X-Mailer: Mulberry/3.1.0b5 (Mac OS X Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, August 22, 2003 3:42 PM +0100 Paul Smith wrote: > Do people share the data using non-IMAP methods? Yes. MH provides support for shared folders in it's toolset. And at least one IMAP server can provide an IMAP view of MH message stores. > If not, then make the mailbox data accessible to the user (owner) and > to a group containing the IMAP Server (and NNTP server, POP3 server etc > if you want) > >> > Am I missing something obvious? I must be, because it seems so >> > simple. > If people want to have shell access to an IMAP message store, then > maybe we should be looking into why they don't feel that IMAP clients > will do what they want. Eg, do people want a regex search facility in > IMAP? Time has shown that monolithic tools just don't scale or provide the power that a group of ad hoc simple tools can provide. This is the power of UNIX. MH has this philosophy at its core. If all you do is read and delete your e-mail, it's hard to understand why this matters. If you use e-mail to the n'th degree, you quickly come to appreciate the power and flexibility of having an arsenal of tools, and you will use whichever tool is appropriate to solving a specific problem. One example illustrates this. I have archives of my email going back to around 1987. This consists of tens of thousands of messages spread across hundreds of folders, all stored in MH format. If I want to search the entire archive for a string I can do two things: for i in folders ; do SELECT $i SEARCH .... done or grep -r -i 'pattern' ${HOME}/Mail There is absolutely no way doing this search through IMAP will be even close to as fast as that grep command. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGhNqt048164 for ; Fri, 22 Aug 2003 09:43:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MGhNXc048159 for ietf-imapext-bks; Fri, 22 Aug 2003 09:43:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGhMqt048136 for ; Fri, 22 Aug 2003 09:43:22 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MGhDoa024147; Fri, 22 Aug 2003 09:43:19 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MGhD7T014663; Fri, 22 Aug 2003 09:43:13 -0700 Date: Fri, 22 Aug 2003 09:43:13 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F4625C4.3040800@oceana.com> Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> <3F4625C4.3040800@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Ken Murchison wrote: > > Fortunately, there is another alternative: create an ACL mechanism which > > expresses relatively simple access control (such as UNIX) in a simple way, > > and allows for additional facilities as options. > Mark, do you have a strawman for such a proposal? Since each of the > proposals served up by the "RFC 2086 camp" are getting volleyed back, > perhaps its time for a proposal from the "UNIX ACL camp". ;) I've made such proposals numerous times. First of all, it is not "UNIX ACL camp". That label is a calculated straw man designed to descredit the position. This issue is reminiscent of a Byzantine debate. The Turks are at the gates, yet the entire focus is whether angels are male or female. For the 99% case, a user only needs to be able to control whether other users can read and/or tamper with a mailbox. "Other users" are split into "everybody" and "subset of everybody". For the most part, ACL2 does this. All other semantics, including such esoteric concepts as inheritance from less specific rights to more specific rights, negative rights, etc. should be optional. Their availability should be announced, but not made mandatory. For the most part, ACL2 fixes this flaw in RFC 2086. There needs to be a better identifier naming scheme than RFC 2086; I don't think that anyone disputs that RFC 2086's naming was broken. For the most part, ACL2 fixes this as well. For better or worse, the current ACL2 document seems to address the problem. We could simply sign off on ACL2, declare victory, and go home. Yes, it's hairy, but if it gets the hold-out servers on board and prevents a competiting ACL3 from happening it will be a good thing. Suppose we fail to agree? The outcome will be that IMAP ACLs will continue to languish in poorly-implemented obscurity because major servers and clients do not implement it. And the possibility of ACL3 always looms. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGKPqt047323 for ; Fri, 22 Aug 2003 09:20:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MGKPM9047322 for ietf-imapext-bks; Fri, 22 Aug 2003 09:20:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MGKOqt047316 for ; Fri, 22 Aug 2003 09:20:24 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 2BA732869E0 for ; Fri, 22 Aug 2003 17:20:21 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 17:18:51 +0100 Message-Id: <5.2.1.1.2.20030822160111.05413d40@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 16:07:56 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:02 22/08/2003 -0400, you wrote: >On Fri, 22 Aug 2003, Paul Smith wrote: > > > Thinking of it from a CLIENT end, if the IMAP client can't obtain a list of > > users/groups that can be set, then ACL2 is going to be moderately unusable > > (even less so than ACL, because now the client needs to specify 'group=' or > > 'user=' correctly) > >If we were going to do this it should almost certainly be a separate >extention. OK, as I expected > > The IMAP server is the only thing which KNOWS which users/groups are > > available - so maybe the ACL standard should define a way of getting a list > > of users/groups, or there should be an accompanying IMAP extension to > do so. > >There are cases where the IMAP server may not, in fact, be able to >efficiently enumerate all of the users/groups it has available (though >verification/lookup may be cheap). Adding this additional requirement to >ACL2 is unaccepable. Okey dokey - it'd be a nice extra extension though, usability-wise. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MG2uqt046083 for ; Fri, 22 Aug 2003 09:02:56 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MG2ugE046082 for ietf-imapext-bks; Fri, 22 Aug 2003 09:02:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MG2sqt046067 for ; Fri, 22 Aug 2003 09:02:55 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MG2nin029866; Fri, 22 Aug 2003 09:02:50 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MG2njX012592; Fri, 22 Aug 2003 09:02:49 -0700 Date: Fri, 22 Aug 2003 09:02:49 -0700 (PDT) From: Mark Crispin To: Steve Hole cc: Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Steve Hole wrote: > In fact, I would claim that what you are > attempting is to use IMAP as a backdoor access control management protocol > for regular UNIX files. That is true, just as IMAP is a backdoor file access mechanism for regular files that just happen to contain messages. If you wish to change IMAP into something else, such as an operating system, then you should realize that you are changing IMAP in a fundamental way from what its creator intended. And by changing IMAP into something that it was never intended to be, it will suck. It will cease to be the useful thing that it was intended to be at its creation, and it will never be as good as something like Exchange (note the recent Microsoft quote) which was intended to be the other thing from its inception. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFuUqt045218 for ; Fri, 22 Aug 2003 08:56:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MFuUkE045216 for ietf-imapext-bks; Fri, 22 Aug 2003 08:56:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFuTqt045206 for ; Fri, 22 Aug 2003 08:56:29 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MFuOgG023245; Fri, 22 Aug 2003 08:56:24 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MFuOoI012204; Fri, 22 Aug 2003 08:56:24 -0700 Date: Fri, 22 Aug 2003 08:56:24 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > Do people share the data using non-IMAP methods? Yes. Have you ever heard of something called "file sharing"? > > 1) that all IMAP servers operate on dedicated IMAP-only boxes > I didn't make that assumption at all. If access restrictions are strong (as > they are on Unix) then the IMAP Server can run under one account which has > full access to the mailbox. Oh? So you want the IMAP server to run as root? > I'd be wary of allowing shell access users full access to their mailbox > directories in any case (maybe I'm being naive again..) Yes, you are. There is 30 years of history in which people who have done just that. > If the IMAP server > uses a certain directory as its mailbox, what happens if the user goes and > dumps lots of raw MPG files into that directory with similar filenames as > files that the IMAP server expects to be message or mailbox files? Arbitrary file export works fine in UW imapd. > > 4) that there is no need for non-IMAP type access (e.g. grep, sed, > > editors) to mail files > Hmm, I'd see that as a good assumption... I'd see it as bad to allow people > to be able to edit raw message files... Too bad. This is what is there today. It can't be changed. Experience teaches that the world sometimes isn't as perfect and wonderful as you would like it to be. Sometimes you have to accomodate truly > If people want to have shell access to an IMAP message store, then maybe we > should be looking into why they don't feel that IMAP clients will do what > they want. Eg, do people want a regex search facility in IMAP? Yes, indeed, some people would like regex search in IMAP. But adding regex searches to IMAP won't make the problem go away (and it's not as easy to add regex search as you may think -- the problem being that there is no clear definition of what regex is). They also want to be able to use all their other tools. Basically, nothing shy of the full UNIX command language will do. > >No matter how contemptuously you may want to dismiss such environments, > >they are out there, and they represent the majority of IMAP servers. > But those IMAP servers don't support ACL, and no one's forcing them to. That's the problem. These IMAP servers don't support ACL, and want to because of client demand, but can't because RFC 2086 sucks so badly. The whole point of the IMAPEXT exercise with ACL was to fix this. Now, when it seems that we have a hard-fought fix, there is an aggressive effort to sabotage the fix and to preserve the status quo of IMAP ACL that can't be implemented in the majority of deployed IMAP servers. > My view is that people seem to have been saying 'lets have a unix variant > of ACL', which I would strongly oppose. I haven't been saying that. What I am saying is IMAP ACL should be fixed so that: 1) it can express UNIX access control (RFC 2086 is too weak to do so) 2) UNIX access control is a compliant subset of IMAP ACL (there are mandatory to implement aspects of RFC 2086 that conflict with this) > I would have less problem with being able to advertise an arbitrarily > reduced ACL feature-set for those unable/unwilling to implement the full > feature-set. This is exactly what I am talking about. Why then are you whacking me with a strawman that is not my position? Of course it is absurd to have a special ACL2=unix mode. The entire reason why I started discussing all the ACL2=tops-20, ACL2=NTFS, etc. modes was to demonstrate that ACL2=unix leads to madness. > I would see it as better to advertise the > feature-set available at the start of the session than only when someone > tries to do something that breaks it. Once again, this is what we are talking about. > But, if I was a Unix developer looking to implement an ACL-aware IMAP > server, I'd certainly be looking into ways of trying to get more > functionality than the Unix filesystem can offer, eg it can't be uncommon > for users to want to give both themselves and their PA full access to their > mailbox, but their associates read-only access and other people no access. The same desire applies to files. For better or worse, people have worked out ways of doing this with files. The problem is that RFC 2086 precludes this from being managed or queried from the IMAP end. RFC 2086 imposes an AFS model upon the world, whether or not AFS translates well to what is there. So people are forced to log in to a shell to do chmod/chgrp. And while they are there, they get into the habit of doing other shell operations instead of using IMAP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFm4qt044724 for ; Fri, 22 Aug 2003 08:48:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MFm4kQ044723 for ietf-imapext-bks; Fri, 22 Aug 2003 08:48:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFlwqt044716 for ; Fri, 22 Aug 2003 08:48:02 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7MFpNn07601; Fri, 22 Aug 2003 09:51:23 -0600 From: Steve Hole Date: Fri, 22 Aug 2003 09:51:23 -0700 To: Mark Crispin Subject: Re: acl-08: questions Cc: Paul Smith , ietf-imapext@imc.org In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7MFm2qt044718 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003 05:43:19 -0700 (PDT) Mark Crispin wrote: > > On Thu, 21 Aug 2003, Paul Smith wrote: > > But, why does the IMAP4 server have to rely solely on UNIX rights? Can't it > > implement its own on top? > > The answer is no. Yes, it can! > Some of the world is servers that co-exist with shell accounts. It is > meaningless for an IMAP server to implement ACL rights that are trivially > evaded by anyone who has shell (or FTP) access. It is not meaningless at all. In fact, I would claim that what you are attempting is to use IMAP as a backdoor access control management protocol for regular UNIX files. It absoutely is possible to (1) restrict access to mailbox files in traditional UNIX format such that shells and ftp have no more or less rights than they have today and (2) provide a richer, more granular access to mailboxes in the IMAP context. You will have to provide external IMAP-only metadata. > An ACL mechanism which is unable to express the rights of the existing > underlying mail store is worse than useless in environments in which the > underlying mail store is exposed in other ways. I strongly disagree. I believe that others do as well. I think that we are trading server implementation difficulty on one platform and format into protocol complexity, and thus client implementation difficulty. I think that is just full on wrong. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFDdqt042255 for ; Fri, 22 Aug 2003 08:13:39 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MFDdbY042254 for ietf-imapext-bks; Fri, 22 Aug 2003 08:13:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFDZqt042229 for ; Fri, 22 Aug 2003 08:13:37 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7MFH9n07087; Fri, 22 Aug 2003 09:17:09 -0600 From: Steve Hole Date: Fri, 22 Aug 2003 09:17:08 -0700 To: Paul Smith Subject: Re: acl-08: questions Cc: ietf-imapext@imc.org In-Reply-To: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> References: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7MFDcqt042246 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003 17:26:57 +0100 Paul Smith wrote: > What other INTERNET protocol can you think of that requires clients to > behave differently depending on what OS their server is running on? > > The whole point of INTERNET STANDARDS is that they aren't OS dependent. Precisely. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MF08qt040087 for ; Fri, 22 Aug 2003 08:00:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MF08VF040086 for ietf-imapext-bks; Fri, 22 Aug 2003 08:00:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MF06qt040076 for ; Fri, 22 Aug 2003 08:00:06 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 5765528632C for ; Fri, 22 Aug 2003 16:00:02 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 15:58:09 +0100 Message-Id: <5.2.1.1.2.20030822150112.03582838@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 15:42:18 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:45 22/08/2003 -0700, you wrote: > > Where's the flaw with that? > >We have terabytes (at least I think that it's still just terabytes) of >mail file data that people access both with IMAP and non-IMAP methods. Do people share the data using non-IMAP methods? If not, then make the mailbox data accessible to the user (owner) and to a group containing the IMAP Server (and NNTP server, POP3 server etc if you want) > > Am I missing something obvious? I must be, because it seems so simple. > >Yes, you are missing something obvious. You are making many false >presumptions: > 1) that all IMAP servers operate on dedicated IMAP-only boxes I didn't make that assumption at all. If access restrictions are strong (as they are on Unix) then the IMAP Server can run under one account which has full access to the mailbox. Other users can run on their own accounts on the same box without access to the mailbox directories. I'd be wary of allowing shell access users full access to their mailbox directories in any case (maybe I'm being naive again..) If the IMAP server uses a certain directory as its mailbox, what happens if the user goes and dumps lots of raw MPG files into that directory with similar filenames as files that the IMAP server expects to be message or mailbox files? By allowing (and 'encouraging') this type of free access to the mailbox files, then you're potentially asking for trouble with naive or malicious users. If you still want users to have access to their own mailbox, you could still give them access (see above) > 2) that all IMAP servers should operate only on dedicated IMAP-only boxes see above > 3) that it is alright to prohibit non-IMAP type access to mail files OK, maybe I made that assumption incorrectly, but there are ways around that, see above. > 4) that there is no need for non-IMAP type access (e.g. grep, sed, > editors) to mail files Hmm, I'd see that as a good assumption... I'd see it as bad to allow people to be able to edit raw message files... If people want to have shell access to an IMAP message store, then maybe we should be looking into why they don't feel that IMAP clients will do what they want. Eg, do people want a regex search facility in IMAP? But, see my responses above. >No matter how contemptuously you may want to dismiss such environments, >they are out there, and they represent the majority of IMAP servers. But those IMAP servers don't support ACL, and no one's forcing them to. >But, on the other hand, the repeated efforts to sabotage any attempt to >make IMAP ACLs be implementable in a UNIX filesystem environment are >equally non-constructive. My view is that people seem to have been saying 'lets have a unix variant of ACL', which I would strongly oppose. If you are going to support that, then you need Windows, Posix, DOS, VMS, MS SQL etc variants of ACL as well - and it becomes unworkable. I would have less problem with being able to advertise an arbitrarily reduced ACL feature-set for those unable/unwilling to implement the full feature-set. The only problem I have with this is that it will make life harder than ever for IMAP client developers who want to implement it - which isn't a good thing. I would see it as better to advertise the feature-set available at the start of the session than only when someone tries to do something that breaks it. (FWIW I have no problem with the draft-ietf-imapext-acl-09.txt document, except for the client implementation complexity issue) But, if I was a Unix developer looking to implement an ACL-aware IMAP server, I'd certainly be looking into ways of trying to get more functionality than the Unix filesystem can offer, eg it can't be uncommon for users to want to give both themselves and their PA full access to their mailbox, but their associates read-only access and other people no access. That wouldn't be possible if you limit yourselves to the Unix filesystem's capabilities. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MF05qt040073 for ; Fri, 22 Aug 2003 08:00:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MF05Qa040072 for ietf-imapext-bks; Fri, 22 Aug 2003 08:00:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MF04qt040066 for ; Fri, 22 Aug 2003 08:00:04 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 0452B284829 for ; Fri, 22 Aug 2003 16:00:00 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 15:58:12 +0100 Message-Id: <5.2.1.1.2.20030822154341.0370fe58@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 15:57:28 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <3F461DC0.1000805@isode.com> References: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 14:42 22/08/2003 +0100, Alexey Melnikov wrote: >Paul Smith wrote: >>Maybe the server should be able to say exactly what rights it allows, eg >>'I support xyz rights', and if server developers want to be restricted by >>the 'one user/one group/anyone' Unix problem, maybe that could be another >>limit that the server could advertise, in a general way that can be >>designed. That wouldn't be too bad - but don't make it OS specific. > >I agree. > >My own position on this that a client should be able to >a). Implement a basic UI for showing/modifying ACLs without a knowledge of >the access calculation model being used by the server. We should be aiming >to add all required commands/responses to achieve this. >b). Implement an advanced UI for particular model(s) that the client >recognizes. How about, in either the LIST responses or a separate 'ACL-CAPA' response having something like ACL "Posix" swite lr p cx a g u1 This could indicate that this mailbox is 'Unix' (in case someone wants to have an advanced UI for that type) , and the 'swite' 'lr' 'p' 'cx' 'a' rights are tied together, it supports multiple groups and a single user You could have ACL "FreeAndEasy" s w i t e l r p c x a g u which supports anything or ACL "VeryLimited" switecxa lr p u1 which has a 'read' and a 'write' mode only and only supports a single user and no groups For the Posix case, even if the client didn't understand that case specifically it could tie the 'swite' checkboxes (or whatever) together, and could only allow the selection of a single user, and multiple groups as the identifier. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEwxqt039865 for ; Fri, 22 Aug 2003 07:58:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MEwxPk039864 for ietf-imapext-bks; Fri, 22 Aug 2003 07:58:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org ([213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEwwqt039672 for ; Fri, 22 Aug 2003 07:58:58 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 65E255C65485 for ; Fri, 22 Aug 2003 17:57:43 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> Content-Type: text/plain Message-Id: <1061564263.24982.166.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 22 Aug 2003 17:57:43 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 2003-08-22 at 11:50, Paul Smith wrote: > Or, Unix developers have to come to terms with having to do something > relatively simple such as running the IMAP server in its own account with > full access to the mailboxes and implementing their own (straightforward) > ACL system on top. That's about the worst idea from security point of view. A single bug in your server could mean that the attacker got full access to everyone's mail. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEV5qt037076 for ; Fri, 22 Aug 2003 07:31:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MEV5fo037075 for ietf-imapext-bks; Fri, 22 Aug 2003 07:31:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEV4qt037068 for ; Fri, 22 Aug 2003 07:31:04 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 15:28:39 +0100 Message-ID: <3F462894.1060609@isode.com> Date: Fri, 22 Aug 2003 15:28:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Cyrus Daboo , Rob Siemborski , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >>, and >>the core set of rights. Then separate ACL2=AFS and ACL2=UNIX documents that >>implement the real extensions that provide specific implementations of this >>wrt identifiers etc. Rob already described what ACL2=UNIX would look like, >>and ACL2=AFS is pretty much already covered by the original ACL. >> > >Half-agree. > >I suggest something a bit different: > >Define a set of rights, not as protocol items, but as "operations". Then >define a means by which a server announces the rights that it exports and >what the operations are. For example, a UNIX server may says "I have a W >right which permits operations wisd." In a Cyrus type server, it would >have a one right/one operation export. > >Now, instead of defining ACL2=AFS, ACL2=UNIX, ACL2=BLURDYBLOOP, we have a >general means by which the server announces how its access control model >works. > >There would be no tied rights in the ACL commands themselves. They'll >just use the server-announced rights, which on a UNIX server would >probably be R and W. > >Since there are no tied rights, there is no longer any magic about how >rights get set and cleared. Furthermore, the client has perfect knowledge >about the impact of what it does. > Although, this seems like an interesting idea, I don't think this is going to work. The client will have to present these server-announced rights in UI. You will either have to create an IANA registry for them, or the server has to send a description of what it is. This will require i18n... So I am not sure I would like to go this way. >The only wart is that we have to define what to do with operations which >either can not be granted or can not be revoked as a right. ACL's "a" >comes immediately to mind. Perhaps a template of such "fixed" items? > > > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MENiqt036568 for ; Fri, 22 Aug 2003 07:23:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MENi1O036567 for ietf-imapext-bks; Fri, 22 Aug 2003 07:23:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MENhqt036562 for ; Fri, 22 Aug 2003 07:23:43 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 15:23:22 +0100 Message-ID: <3F462757.6020804@isode.com> Date: Fri, 22 Aug 2003 15:23:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Newman CC: Rob Siemborski , Paul Smith , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: >On Fri, 22 Aug 2003, Paul Smith wrote: > > >>Thinking of it from a CLIENT end, if the IMAP client can't obtain a list of >>users/groups that can be set, then ACL2 is going to be moderately unusable >>(even less so than ACL, because now the client needs to specify 'group=' or >>'user=' correctly) >> >> > >If we were going to do this it should almost certainly be a separate >extention. > > >>The IMAP server is the only thing which KNOWS which users/groups are >>available - so maybe the ACL standard should define a way of getting a list >>of users/groups, or there should be an accompanying IMAP extension to do so. >> >> > >There are cases where the IMAP server may not, in fact, be able to >efficiently enumerate all of the users/groups it has available (though >verification/lookup may be cheap). Adding this additional requirement to >ACL2 is unaccepable. > I agree to both. If I remember correctly Chris Newman was planning to do a draft on this. Chris, are you going to do this, or should we solicit for a volunteer? Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEEpqt035959 for ; Fri, 22 Aug 2003 07:14:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MEEp5u035958 for ietf-imapext-bks; Fri, 22 Aug 2003 07:14:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MEEnqt035953 for ; Fri, 22 Aug 2003 07:14:50 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7MEEbri030385; Fri, 22 Aug 2003 10:14:38 -0400 (EDT) Message-ID: <3F4625C4.3040800@oceana.com> Date: Fri, 22 Aug 2003 10:16:36 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > Fortunately, there is another alternative: create an ACL mechanism which > expresses relatively simple access control (such as UNIX) in a simple way, > and allows for additional facilities as options. Mark, do you have a strawman for such a proposal? Since each of the proposals served up by the "RFC 2086 camp" are getting volleyed back, perhaps its time for a proposal from the "UNIX ACL camp". ;) -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ME2qqt035571 for ; Fri, 22 Aug 2003 07:02:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ME2qDJ035570 for ietf-imapext-bks; Fri, 22 Aug 2003 07:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ME2pqt035560 for ; Fri, 22 Aug 2003 07:02:51 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX1.andrew.cmu.edu (MX1.andrew.cmu.edu [128.2.10.111]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7ME2oI3025851; Fri, 22 Aug 2003 10:02:50 -0400 Date: Fri, 22 Aug 2003 10:02:50 -0400 (EDT) From: Rob Siemborski To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > Thinking of it from a CLIENT end, if the IMAP client can't obtain a list of > users/groups that can be set, then ACL2 is going to be moderately unusable > (even less so than ACL, because now the client needs to specify 'group=' or > 'user=' correctly) If we were going to do this it should almost certainly be a separate extention. > The IMAP server is the only thing which KNOWS which users/groups are > available - so maybe the ACL standard should define a way of getting a list > of users/groups, or there should be an accompanying IMAP extension to do so. There are cases where the IMAP server may not, in fact, be able to efficiently enumerate all of the users/groups it has available (though verification/lookup may be cheap). Adding this additional requirement to ACL2 is unaccepable. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDoXqt035040 for ; Fri, 22 Aug 2003 06:50:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MDoXbC035039 for ietf-imapext-bks; Fri, 22 Aug 2003 06:50:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDoVqt035033 for ; Fri, 22 Aug 2003 06:50:32 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1) with ESMTP-TLS id 418398 for ietf-imapext@imc.org; Fri, 22 Aug 2003 08:50:34 -0500 Message-ID: <3F461FA5.7040106@ehsco.com> Date: Fri, 22 Aug 2003 08:50:29 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IMAP Extensions WG Subject: acl2=os-fs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just a comment that filesystem acls are a function of the OS plus the filesystem, so any declaration would need to allow both to be declared. EG, Win32+FAT is different from Win32+NTFS is different from UNIX+NTFS is different from UNIX+XFS is different from ... -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDkBqt034791 for ; Fri, 22 Aug 2003 06:46:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MDkBc9034789 for ietf-imapext-bks; Fri, 22 Aug 2003 06:46:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDkAqt034782 for ; Fri, 22 Aug 2003 06:46:10 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MDjxgG011562; Fri, 22 Aug 2003 06:46:05 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MDjxJC009271; Fri, 22 Aug 2003 06:45:59 -0700 Date: Fri, 22 Aug 2003 06:45:59 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > Didn't you see my possible 'solution' to the problem? I saw it. It isn't a solution. > Make the IMAP mailboxes *only* accessible to the 'imapdaemon' user account, > not to *anyone* else. Then the IMAP server has full access to all > accounts, and can control it as necessary, but no one else (except root) has. > Where's the flaw with that? We have terabytes (at least I think that it's still just terabytes) of mail file data that people access both with IMAP and non-IMAP methods. > Am I missing something obvious? I must be, because it seems so simple. Yes, you are missing something obvious. You are making many false presumptions: 1) that all IMAP servers operate on dedicated IMAP-only boxes 2) that all IMAP servers should operate only on dedicated IMAP-only boxes 3) that it is alright to prohibit non-IMAP type access to mail files 4) that there is no need for non-IMAP type access (e.g. grep, sed, editors) to mail files If you were to decree to our users that IMAP would henceforth be the only permitted access to mail data, you would get some rather forceful pushback. There are many many sites which still use (shudder) the traditional UNIX mailbox format, with INBOX on /var/spool/mail and all other mailboxes in a subdirectory of a shell account home directory. No matter how contemptuously you may want to dismiss such environments, they are out there, and they represent the majority of IMAP servers. IMAP ACL has stood out as something that is unimplementable in such environments; and yes I have had multiple requests to provide a means to manipulate UNIX access control via IMAP. I have resisted this, in the hope that RFC 2086 will be fixed. It seems that this was a mistake. Perhaps I should just specify CHMOD, CHGRP, CHOWN commands in IMAP. And get this so widely distributed that clients will feel compelled to implement it; and thus force all other servers to implement it too because everybody uses CHMOD/CHGRP/CHOWN and nobody uses RFC 2086. And, of course, IESG will halt all advancement of any form of IMAP ACL because there are now two competing IMAP ACL specifications. I do not think that this is constructive. I have not done this. But, on the other hand, the repeated efforts to sabotage any attempt to make IMAP ACLs be implementable in a UNIX filesystem environment are equally non-constructive. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDgvqt034683 for ; Fri, 22 Aug 2003 06:42:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MDgvZu034682 for ietf-imapext-bks; Fri, 22 Aug 2003 06:42:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDguqt034676 for ; Fri, 22 Aug 2003 06:42:56 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 14:42:27 +0100 Message-ID: <3F461DC0.1000805@isode.com> Date: Fri, 22 Aug 2003 14:42:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Smith CC: ietf-imapext@imc.org, Cyrus Daboo Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> In-Reply-To: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Smith wrote: > > At 11:37 21/08/2003 -0400, Cyrus Daboo wrote: > >> wrt identifiers etc. Rob already described what ACL2=UNIX would look >> like, and ACL2=AFS is pretty much already covered by the original ACL. >> >> The benefit of this is that server vendors only need concern >> themselves with coding to the particular model that is specific to >> them. The disadvantage is that clients have to implement multiple >> extensions. However, the UIs for those can be specifically tailored >> to each and can have safety checks etc to aid users in setting things >> up. > > > Sorry, but I think that's silly, and would quickly become a nightmare. > > What other INTERNET protocol can you think of that requires clients to > behave differently depending on what OS their server is running on? > > The whole point of INTERNET STANDARDS is that they aren't OS dependent. > > What happens if another platform comes along and wants another > 'ACL2=MYFABOS' identifier - either they'll have to do what everyone > else should have done and produce their own rights system to emulate > an existing one, or you'll have to force all IMAP client developers to > produce a new version of their software. > > That isn't workable. > > > Maybe the server should be able to say exactly what rights it allows, > eg 'I support xyz rights', and if server developers want to be > restricted by the 'one user/one group/anyone' Unix problem, maybe that > could be another limit that the server could advertise, in a general > way that can be designed. That wouldn't be too bad - but don't make it > OS specific. I agree. My own position on this that a client should be able to a). Implement a basic UI for showing/modifying ACLs without a knowledge of the access calculation model being used by the server. We should be aiming to add all required commands/responses to achieve this. b). Implement an advanced UI for particular model(s) that the client recognizes. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDTSqt034255 for ; Fri, 22 Aug 2003 06:29:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MDTSKt034254 for ietf-imapext-bks; Fri, 22 Aug 2003 06:29:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDTRqt034247 for ; Fri, 22 Aug 2003 06:29:27 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MDTMxu030055; Fri, 22 Aug 2003 06:29:22 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MDTL4I009011; Fri, 22 Aug 2003 06:29:22 -0700 Date: Fri, 22 Aug 2003 06:29:21 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> Message-ID: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 22 Aug 2003, Paul Smith wrote: > The file system is irrelevant IMHO... This is essentially a software issue. > IMAP isn't a unix protocol. Nonsense, and as the inventor of IMAP I deeply resent being lectured to in this way. IMAP is not a UNIX protocol, but it does not disregard (and has never disregarded) the requirements of the underlying mail store. The purpose of IMAP is to smooth out the various differences between mail stores, and to create a common framework in which they all interoperate. Note that word "interoperate". IMAP does not -- MUST NOT -- mandate something which is non-implementable and non-interoperable in a particular mail store. Making compromises in order to create interoperability is what the Internet protocols are all about. If you don't want to work on interoperable protocols, then go to work for AOL or Microsoft or one of the other vendors of proprietary protocols that go to great efforts to lock out other vendors. > >For all the ranting and raving about how ACL should be "good" or "ideal", > >RFC 2086 is a very limited design that can not express valid UNIX ACLs. > But why should it?? Because RFC 2086 is useless when what has to be expressed and maintained are UNIX ACLs, that's why. > RFC 2086 (for all its faults) is not about expressing > OS ACLs, it's about expressing IMAP mailbox ACLs. They're two totally > different things. They should not be, and in any environment other than a black box they must not be. > Our IMAP server is written for Windows, it totally ignores the Windows > ACLs, and implements its own RFC 2086 compliant ACLs - no problem. You don't have any users who access message data from non-IMAP applications, do you? In fact, you go to great efforts to document that the IMAP data files have to be protected from other Windows applications, since none of your access control works against those other applications, right? > a) Make it so that neither mary, nor harry, nor joe THEMSELVES have access > to the mail folders, but only the 'imapdaemon' account which is the > account which the IMAP server runs under which has full access to the > mailbox files and nothing else (this is what we do on Windows). That's a black box. Black boxes are not the entire world. > I don't see > how this is a problem. This sort of comment usually comes from a novice who has only been exposed to a limited number of environments and can't conceive of anything else. Experience generally cures this. > b) Encrypt the message files. This also suggest inexperience; you're thinking of read access while disregarding write, delete, rename access which encryption does nothing to address. > >There seems to be a false idea wedged inside the heads of certain > >individuals that an operating system is just an annoyance and that every > >Internet service can and should be its own operating system unto itself. > Yes, it should. Otherwise - why have Java? (just pass around raw binaries) > Why have HTML? (use .DOC, .PS etc). Etc, etc. The whole point of Internet > standards is that they are Platform/OS independent. You are comparing apples and oranges. Java is a programming language; HTML/Word/Postscript are document representations. These are not data access protocols; nor do they make any attempt to deal with a legacy. > >Once upon a time, the Internet development community understood this. > >That is what gave us interoperable protocols such as TELNET, FTP, and > >SMTP. > Yes, none of which (except for FTP, slightly (which cause quite a few > problems IME)) have platform specific features. They all work exactly the > same regardless of which platform the server is running on. Wrong. TELNET is very platform specific. As an example, for many years, a mandatory part of the TELNET protocol had no purpose other than to unlock the keyboard on an IBM 2741. TELNET went to great efforts to smooth out these details to the client and the end user, but it certainly did not ignore platform requirements. > To have the same platform independence allowing for file systems to be used > as the ACL system you MUST go for the lowest common denominator. Yes. The lowest common denominator must be supported and supportable. > So to allow for Unix developers to use the file system as their access > control system, the ACLs should be limited to 'read' or 'write' or > 'read/write' access, with one user (mailbox owner - presumably with full > rights), one group and anyone. Period. There should be no possibility of > being more granular with access, or by allowing multiple users different > rights etc. Wrong. Do not confuse "mandatory to implement" with "mandatory not to implement". Do not confuse "compliant implementation" with "implementation of all options." It is not required to limit IMAP ACLs to what UNIX can provide. It is simply required that UNIX access control be compliant with IMAP ACLs, and that UNIX access control must be expressible in IMAP ACLs. This means that IMAP ACLs must be rich enough to express UNIX access control (RFC 2086 is not -- it is inferior in certain ways), and that UNIX access control expressed in IMAP ACLs should be a compliant subset (not omit required attributes) of IMAP ACLs (RFC 2086 does not do this either). > However, that wouldn't be acceptable for many other developers who WANT > those other features (eg we have users who want to be able to STORE flags > on messages, but not be able to delete them or insert messages, and people > want to be able to give different rights to different people) RFC 2086 is not widely implemented by clients or deployed servers. Most users do not have any access control features today, much less fancy ones. > So, a platform independent (given Unix developers' wish to use their file > system as their access control system) method won't work. Non-sequitor. In effect, you are saying, "RFC 2086 is not widely implemented, therefore making it implementable on UNIX won't make it more widely implemented." > Either we have to make it vastly more complex and have different servers > providing different access methods That is not the only possibility. > Or, Unix developers have to come to terms with having to do something > relatively simple such as running the IMAP server in its own account with > full access to the mailboxes and implementing their own (straightforward) > ACL system on top. This is completely unacceptable. I think that you would be very unhappy if I dictated to you how a Windows server would work. Fortunately, there is another alternative: create an ACL mechanism which expresses relatively simple access control (such as UNIX) in a simple way, and allows for additional facilities as options. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDG8qt033412 for ; Fri, 22 Aug 2003 06:16:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MDG8Vc033410 for ietf-imapext-bks; Fri, 22 Aug 2003 06:16:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDG6qt033396 for ; Fri, 22 Aug 2003 06:16:07 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Fri, 22 Aug 2003 14:15:31 +0100 Message-ID: <3F461771.6090600@isode.com> Date: Fri, 22 Aug 2003 14:15:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> In-Reply-To: <2147483647.1061465831@[10.0.1.6]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > This may be out of scope at this stage in the proceedings, but what I > would like to see is an ACL2 framework document that defines a basic > set of commands (ACL STORE/DELETE/SET, LISTRIGHTS) without explicit > syntax, and the core set of rights. Then separate ACL2=AFS and > ACL2=UNIX documents that implement the real extensions that provide > specific implementations of this wrt identifiers etc. I was trying to structure the document in the way that keeps this separation. Whether I was successful or not is of course a separate question. If the WG prefer to have separate documents, I can do that. > Rob already described what ACL2=UNIX would look like, and ACL2=AFS is > pretty much already covered by the original ACL. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MD1Gqt032007 for ; Fri, 22 Aug 2003 06:01:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MD1G4l032006 for ietf-imapext-bks; Fri, 22 Aug 2003 06:01:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MD1Fqt032000 for ; Fri, 22 Aug 2003 06:01:15 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id B578D237812 for ; Fri, 22 Aug 2003 14:00:07 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 13:57:43 +0100 Message-Id: <5.2.1.1.2.20030822135413.03bcc7d0@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 13:56:33 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:43 22/08/2003 -0700, you wrote: >On Thu, 21 Aug 2003, Paul Smith wrote: > > But, why does the IMAP4 server have to rely solely on UNIX rights? Can't it > > implement its own on top? > >The answer is no. > >Some of the world is servers that co-exist with shell accounts. It is >meaningless for an IMAP server to implement ACL rights that are trivially >evaded by anyone who has shell (or FTP) access. Didn't you see my possible 'solution' to the problem? Make the IMAP mailboxes *only* accessible to the 'imapdaemon' user account, not to *anyone* else. Then the IMAP server has full access to all accounts, and can control it as necessary, but no one else (except root) has. Where's the flaw with that? Am I missing something obvious? I must be, because it seems so simple. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MChQqt031636 for ; Fri, 22 Aug 2003 05:43:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MChQTe031635 for ietf-imapext-bks; Fri, 22 Aug 2003 05:43:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MChOqt031629 for ; Fri, 22 Aug 2003 05:43:25 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MChJCK005054; Fri, 22 Aug 2003 05:43:19 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7MChJDp008311; Fri, 22 Aug 2003 05:43:19 -0700 Date: Fri, 22 Aug 2003 05:43:19 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Paul Smith wrote: > But, why does the IMAP4 server have to rely solely on UNIX rights? Can't it > implement its own on top? The answer is no. Some of the world is servers that co-exist with shell accounts. It is meaningless for an IMAP server to implement ACL rights that are trivially evaded by anyone who has shell (or FTP) access. An ACL mechanism which is unable to express the rights of the existing underlying mail store is worse than useless in environments in which the underlying mail store is exposed in other ways. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KHqt014534 for ; Fri, 22 Aug 2003 02:20:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M9KHhm014533 for ietf-imapext-bks; Fri, 22 Aug 2003 02:20:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KFqt014520 for ; Fri, 22 Aug 2003 02:20:16 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id 7643425C17F for ; Fri, 22 Aug 2003 10:20:12 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 10:16:20 +0100 Message-Id: <5.2.1.1.2.20030822092103.03ceb738@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 09:50:17 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:54 21/08/2003 -0700, Mark Crispin wrote: >On Thu, 21 Aug 2003, Paul Smith wrote: > > Exactly. (not being a Unix developer) I can't see why Unix should have > > special treatment and force an Internet standard to behave specially just > > because Unix does it that way. > >I am not asking for UNIX to have special treatment. I am asking for the >IMAP ACL specification to be well-designed enough that it can be >implemented with the underlying store being a UNIX filesystem. The file system is irrelevant IMHO... This is essentially a software issue. IMAP isn't a unix protocol. >For all the ranting and raving about how ACL should be "good" or "ideal", >RFC 2086 is a very limited design that can not express valid UNIX ACLs. But why should it?? RFC 2086 (for all its faults) is not about expressing OS ACLs, it's about expressing IMAP mailbox ACLs. They're two totally different things. Our IMAP server is written for Windows, it totally ignores the Windows ACLs, and implements its own RFC 2086 compliant ACLs - no problem. > > Exactly (again). The IMAP4 server can implement *any* scheme of rights on > > top of a file system. Forcing everyone into a non-ideal scheme just because > > 'it'll be easier for Unix developers' is a bad idea. > >Please explain how an IMAP server, logged in as user joe and with user >joe's filesystem access rights, can access a file on user mary's protected >directory. > >If your answer is "user mary's directory should not be protected against >joe", Yep - see below > that's the whole point -- how is this to happen given that joe and >mary only have IMAP access? Note that we do not want mary's directory to >be accessible to her ex-boyfriend harry who has shell access to that >system. a) Make it so that neither mary, nor harry, nor joe THEMSELVES have access to the mail folders, but only the 'imapdaemon' account which is the account which the IMAP server runs under which has full access to the mailbox files and nothing else (this is what we do on Windows). I don't see how this is a problem. or b) Encrypt the message files. >There seems to be a false idea wedged inside the heads of certain >individuals that an operating system is just an annoyance and that every >Internet service can and should be its own operating system unto itself. Yes, it should. Otherwise - why have Java? (just pass around raw binaries) Why have HTML? (use .DOC, .PS etc). Etc, etc. The whole point of Internet standards is that they are Platform/OS independent. >In the real world, you can't just go off and design your own universe unto >yourself. You have to work and interoperate with what is already there. >That means making compromises, and going the extra mile because some other >implementor is faced with a problem otherwise. See my earlier section with possible solutions to the Unix problem. Maybe Unix developers could make compromises like that... >Once upon a time, the Internet development community understood this. >That is what gave us interoperable protocols such as TELNET, FTP, and >SMTP. Yes, none of which (except for FTP, slightly (which cause quite a few problems IME)) have platform specific features. They all work exactly the same regardless of which platform the server is running on. To have the same platform independence allowing for file systems to be used as the ACL system you MUST go for the lowest common denominator. So to allow for Unix developers to use the file system as their access control system, the ACLs should be limited to 'read' or 'write' or 'read/write' access, with one user (mailbox owner - presumably with full rights), one group and anyone. Period. There should be no possibility of being more granular with access, or by allowing multiple users different rights etc. (Actually, there should probably just be a 'read-only' status that applies to everyone, so every mailbox is readable by everyone, but may be made not writable to everyone - we need to support Windows 95 'ACL's after all...) However, that wouldn't be acceptable for many other developers who WANT those other features (eg we have users who want to be able to STORE flags on messages, but not be able to delete them or insert messages, and people want to be able to give different rights to different people) So, a platform independent (given Unix developers' wish to use their file system as their access control system) method won't work. So, we need a compromise. Either we have to make it vastly more complex and have different servers providing different access methods (in a non-platform-specific way - ACL2=Unix won't work. ACL2=w:swid,r:lr would work), but this will make it MUCH more complex for client authors - and given the low take up that RFC 2086 has had in clients, I wouldn't want to make it even more difficult.. Or, Unix developers have to come to terms with having to do something relatively simple such as running the IMAP server in its own account with full access to the mailboxes and implementing their own (straightforward) ACL system on top. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KGqt014523 for ; Fri, 22 Aug 2003 02:20:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M9KGQ1014522 for ietf-imapext-bks; Fri, 22 Aug 2003 02:20:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KEqt014511 for ; Fri, 22 Aug 2003 02:20:14 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id EAC2525C16F for ; Fri, 22 Aug 2003 10:20:08 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 10:17:27 +0100 Message-Id: <5.2.1.1.2.20030822100749.035957c0@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 10:15:43 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:53 21/08/2003 -0400, Rob Siemborski wrote: >There is still magic about identifiers, however (e.g. you can only have >one user, one group, and anyone in the UNIX model). Sort of related to that. Is there any way, in IMAP, of a client getting hold of a list of users/groups that are available. Thinking of it from a CLIENT end, if the IMAP client can't obtain a list of users/groups that can be set, then ACL2 is going to be moderately unusable (even less so than ACL, because now the client needs to specify 'group=' or 'user=' correctly) You may say, that's an OS issue, but what if the client is on a different network from the server (or is, say, a Windows client talking to a Unix server) - it won't have access to the OS group/user lists It could potentially be an LDAP issue, but, say, on Windows, LDAP will generally be to an Active Directory Server, which may have different groupings and users from the IMAP server, and, for instance, many users on the LDAP server may not be users on the same IMAP server as you. The IMAP server is the only thing which KNOWS which users/groups are available - so maybe the ACL standard should define a way of getting a list of users/groups, or there should be an accompanying IMAP extension to do so. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KBqt014498 for ; Fri, 22 Aug 2003 02:20:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M9KB2H014496 for ietf-imapext-bks; Fri, 22 Aug 2003 02:20:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9K9qt014481 for ; Fri, 22 Aug 2003 02:20:10 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id C6AA225C059 for ; Fri, 22 Aug 2003 10:20:06 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 10:17:10 +0100 Message-Id: <5.2.1.1.2.20030822100237.03595020@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 10:03:23 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061471207@[10.0.1.6]> References: <1061484126.19011.119.camel@hurina> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 13:06 21/08/2003 -0400, you wrote: >|> It is probably also necessary to say that only one ACL2= can be in >|> the CAPABILITY line. >| >| My server supports multiple mailbox formats in same session. For example >| UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability >| wouldn't work. > >If that's going to be the case then there has to be a way for the client >to discover which ACL mode is being used on any one particular mailbox. >The current spec does not address that. This could be solved by having the >ACL response in LIST return the mode if more than one is present in capability: > >C: A002 LIST (ACL) "" * >S: * LIST () "/" INBOX (("ACL=UNIX" (("user=Fred" "rwipslextda")))) >S: * LIST () "." #news (("ACL=AFS" (("user=Fred" "rwipslextda")))) >S: A002 OK List with acl info completed Doesn't this start to look over complex... Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KCqt014503 for ; Fri, 22 Aug 2003 02:20:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M9KCmk014501 for ietf-imapext-bks; Fri, 22 Aug 2003 02:20:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9KAqt014488 for ; Fri, 22 Aug 2003 02:20:10 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id B5E7025C12F for ; Fri, 22 Aug 2003 10:20:07 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 10:16:44 +0100 Message-Id: <5.2.1.1.2.20030822095735.04a5f238@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 10:02:22 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <2147483647.1061465831@[10.0.1.6]> <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:19 21/08/2003 -0500, you wrote: >Before we get much further with this entire conversation: > >1. Who on this list has can and intends to implement ACL2 if it stays in >its current form? Yes, if and when it is implemented by a reasonable number of clients. We have implemented ACL because *some* form of ACL is required to allow usable mailbox sharing. Most of our users don't use ACL enabled IMAP clients (ie they use Eudora, Outlook, Outlook Express, Opera etc), so they actually need to set rights using our servers own UI. We've had no complaints from users that ACL isn't adequate for requirements, so we won't implement ACL2 'just for the sake of it' (it seems a lot more complex), but we will implement it if IMAP clients (that people use) start supporting it. >2. Who on this list cannot implement ACL2 in its current form? Not a problem. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M8AAqt007275 for ; Fri, 22 Aug 2003 01:10:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M8AA0O007274 for ietf-imapext-bks; Fri, 22 Aug 2003 01:10:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M8A9qt007258 for ; Fri, 22 Aug 2003 01:10:09 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id B30EC2597EB for ; Fri, 22 Aug 2003 09:10:05 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 09:00:53 +0100 Message-Id: <5.2.1.1.2.20030821172527.05339418@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 21 Aug 2003 17:26:57 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061465831@[10.0.1.6]> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:37 21/08/2003 -0400, Cyrus Daboo wrote: >wrt identifiers etc. Rob already described what ACL2=UNIX would look like, >and ACL2=AFS is pretty much already covered by the original ACL. > >The benefit of this is that server vendors only need concern themselves >with coding to the particular model that is specific to them. The >disadvantage is that clients have to implement multiple extensions. >However, the UIs for those can be specifically tailored to each and can >have safety checks etc to aid users in setting things up. Sorry, but I think that's silly, and would quickly become a nightmare. What other INTERNET protocol can you think of that requires clients to behave differently depending on what OS their server is running on? The whole point of INTERNET STANDARDS is that they aren't OS dependent. What happens if another platform comes along and wants another 'ACL2=MYFABOS' identifier - either they'll have to do what everyone else should have done and produce their own rights system to emulate an existing one, or you'll have to force all IMAP client developers to produce a new version of their software. That isn't workable. Maybe the server should be able to say exactly what rights it allows, eg 'I support xyz rights', and if server developers want to be restricted by the 'one user/one group/anyone' Unix problem, maybe that could be another limit that the server could advertise, in a general way that can be designed. That wouldn't be too bad - but don't make it OS specific. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M8A6qt007239 for ; Fri, 22 Aug 2003 01:10:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M8A6YZ007236 for ietf-imapext-bks; Fri, 22 Aug 2003 01:10:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M8A4qt007217 for ; Fri, 22 Aug 2003 01:10:04 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id A15722596E3 for ; Fri, 22 Aug 2003 09:10:01 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Fri, 22 Aug 2003 09:02:36 +0100 Message-Id: <5.2.1.1.2.20030821172827.05eaad68@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 21 Aug 2003 17:30:36 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:53 21/08/2003 -0400, Rob Siemborski wrote: >There is still magic about identifiers, however (e.g. you can only have >one user, one group, and anyone in the UNIX model). But, why does the IMAP4 server have to rely solely on UNIX rights? Can't it implement its own on top? By saying that you want IMAP4 ACLs to only allow 'one user, one group and anyone' you are placing a BIG restriction on everyone else who can allow anything because they implement their own rights model. Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI8Oqt045717 for ; Thu, 21 Aug 2003 11:08:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LI8OPZ045716 for ietf-imapext-bks; Thu, 21 Aug 2003 11:08:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI8Mqt045711 for ; Thu, 21 Aug 2003 11:08:23 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI7Yxu006450; Thu, 21 Aug 2003 11:07:34 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI7YTF024262; Thu, 21 Aug 2003 11:07:34 -0700 Date: Thu, 21 Aug 2003 11:07:34 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: Rob Siemborski , Cyrus Daboo , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <1061486469.24980.124.camel@hurina> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> <2147483647.1061471207@[10.0.1.6]> <1061486469.24980.124.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Timo Sirainen wrote: > Since MOST-SPECIFIC is more limited and mostly useful only for UNIX > filesystems Is that true? Don't most other filesystems implement MOST-SPECIFIC? TOPS-20 implemented UNION, but since there were no negative rights there wasn't the complexity associated with that. Actually, I misspoke earlier about TOPS-20. I just remembered that in TOPS-20 release 7, the ability exists to have an arbitrary site-written ACL mechanism. The way this is done is that if access is denied via the traditional access control mechanism, a daemon is queried if it will grant the access. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI2kqt045576 for ; Thu, 21 Aug 2003 11:02:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LI2kTL045575 for ietf-imapext-bks; Thu, 21 Aug 2003 11:02:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI2jqt045567 for ; Thu, 21 Aug 2003 11:02:45 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI2din024161; Thu, 21 Aug 2003 11:02:39 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI2dXh024035; Thu, 21 Aug 2003 11:02:39 -0700 Date: Thu, 21 Aug 2003 11:02:39 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Rob Siemborski wrote: > We're certainly not going to implement it until its clear that the spec > has stabilized I agree that this is a concern. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI0Hqt045496 for ; Thu, 21 Aug 2003 11:00:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LI0HJE045495 for ietf-imapext-bks; Thu, 21 Aug 2003 11:00:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LI0Gqt045490 for ; Thu, 21 Aug 2003 11:00:16 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI0CCK013319 for ; Thu, 21 Aug 2003 11:00:12 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LI0C51023898 for ; Thu, 21 Aug 2003 11:00:12 -0700 Date: Thu, 21 Aug 2003 11:00:12 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: ACL2=TOPS-20 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Like UNIX, TOPS-20 has three fields for both files and directories: owner, group, and world. There are two major differences from UNIX in the interpretation of these fields: 1) The owner of a home directory is the associated user name (guaranteed one to one); this includes directories on other domestic filesystems with the same directory name. Directories on foreign filesystems, and non-home directories, do not have an owner. The owner name can not be changed. 2) Multiple groups are possible; the list is associated with the containing directory (so all files in the directory get the same group list). All groups get the same access. The owner of a directory can alter a directory's group list but only a sysadmin can grant a user's membership in a group. TOPS-20 files have the following independent access bits which are relevant: read, write, append, list in directory. TOPS-20 directories have the following independent access bits: contained files can be accessed (if their access bits permit), administer, create new files in directory. Unlike UNIX, rights are inherited from least to most specific. Unlike AFS, inheritance is cumulative; there are no negative rights. So if world has a right, that right goes to group and owner; and if group has a right, that right goes to owner. I'll look into the details of ACL2=NTFS, ACL2=SQL, ACL2=POSIX, ACL2=VMS, ACL2=VM370, etc. shortly. Get ready to implement all of these in your clients. Who knows, maybe in a little while we'll have as many ACL2=xxx types as we have valid MIME charsets; and we all know how wonderful that experience has been for all of us. Of course, the current ACL2 draft expresses (or at least tries to do so) all of this now, without making the client know about all these different types of filesystems. Perhaps we ought to give the current ACL2 draft a try before talking further about undoing the years of work put into it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHVmqt044505 for ; Thu, 21 Aug 2003 10:31:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LHVm3T044504 for ietf-imapext-bks; Thu, 21 Aug 2003 10:31:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHVlqt044499 for ; Thu, 21 Aug 2003 10:31:47 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7LHVlI3023589 for ; Thu, 21 Aug 2003 13:31:47 -0400 Date: Thu, 21 Aug 2003 13:31:47 -0400 (EDT) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Pete Resnick wrote: > 1. Who on this list has can and intends to implement ACL2 if it stays > in its current form? There is nothing preventing us from implementing ACL2 in its current form. I'm not sure we'd be in a big rush to do it unless a number of clients implemented the feature and we saw demand for it. We're certainly not going to implement it until its clear that the spec has stabilized (We're having enough fun tracking ANNOTATEMORE). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHLAqt044233 for ; Thu, 21 Aug 2003 10:21:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LHLAeL044232 for ietf-imapext-bks; Thu, 21 Aug 2003 10:21:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHL8qt044214 for ; Thu, 21 Aug 2003 10:21:09 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id B5D875EBF9AE; Thu, 21 Aug 2003 20:21:09 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: Rob Siemborski Cc: Cyrus Daboo , ietf-imapext@imc.org In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> <2147483647.1061471207@[10.0.1.6]> Content-Type: text/plain Message-Id: <1061486469.24980.124.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 21 Aug 2003 20:21:09 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-08-21 at 20:11, Rob Siemborski wrote: > This is only the case in the current model if there is some reason that a > server will *interpret* any ACL differently (so it would be possible for > Timo's server to get away with always using MOST-SPECIFIC, for example). > > If he wants some mailboxes to be UNION and some to be MOST-SPECIFIC, then > the current spec is in trouble of course. Since MOST-SPECIFIC is more limited and mostly useful only for UNIX filesystems, of course I'll want to implement UNION for stores which allow it. If there really will be multiple rules, I would probably add support for all of them in all stores which can be made to support them, and let the administrator choose which one to use. This is to make sure people don't start complaining "but it worked this way in the other server and we already got used to it, why doesn't yours work like that?". Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHHSqt044061 for ; Thu, 21 Aug 2003 10:17:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LHHSxn044056 for ietf-imapext-bks; Thu, 21 Aug 2003 10:17:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHHOqt043984 for ; Thu, 21 Aug 2003 10:17:24 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7LHHGI3023558; Thu, 21 Aug 2003 13:17:16 -0400 Date: Thu, 21 Aug 2003 13:17:16 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Timo Sirainen , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Mark Crispin wrote: > On Thu, 21 Aug 2003, Timo Sirainen wrote: > > My server supports multiple mailbox formats in same session. For example > > UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability > > wouldn't work. > > SQL mailboxes, eh? OK, we need an eighth (or was it ninth?) ACL2=type > model. Looks like that way won't scale. It is totally unclear that one of ACL2=UNIX, ACL2=MOST-SPECIFIC, or ACL2=UNION would not work for an SQL mailbox. The problem Timo is demonstrating is that the spec wouldn't allow for different ACL types on different mailboxes on the same server. One that the current ACL2 draft shares. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHBsqt043644 for ; Thu, 21 Aug 2003 10:11:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LHBrL3043643 for ietf-imapext-bks; Thu, 21 Aug 2003 10:11:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LHBpqt043635 for ; Thu, 21 Aug 2003 10:11:52 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from LIN1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7LHBkI3023551; Thu, 21 Aug 2003 13:11:46 -0400 Date: Thu, 21 Aug 2003 13:11:46 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Timo Sirainen , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061471207@[10.0.1.6]> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> <2147483647.1061471207@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Cyrus Daboo wrote: > | My server supports multiple mailbox formats in same session. For example > | UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability > | wouldn't work. > > If that's going to be the case then there has to be a way for the client to > discover which ACL mode is being used on any one particular mailbox. The > current spec does not address that. This could be solved by having the ACL > response in LIST return the mode if more than one is present in capability: This is only the case in the current model if there is some reason that a server will *interpret* any ACL differently (so it would be possible for Timo's server to get away with always using MOST-SPECIFIC, for example). If he wants some mailboxes to be UNION and some to be MOST-SPECIFIC, then the current spec is in trouble of course. > S: * LIST () "." #news (("ACL=AFS" (("user=Fred" "rwipslextda")))) Note that ACL=AFS is a misnomer, it should be UNION. Though both would be interpreted the same way when authorization happened, the mere fact that we are using UNION semantics does not imply AFS is in use. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LH6iqt043447 for ; Thu, 21 Aug 2003 10:06:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LH6iqT043446 for ietf-imapext-bks; Thu, 21 Aug 2003 10:06:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LH6hqt043440 for ; Thu, 21 Aug 2003 10:06:43 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA04909; Thu, 21 Aug 2003 13:02:45 -0400 (EDT) Date: Thu, 21 Aug 2003 13:06:47 -0400 From: Cyrus Daboo To: Timo Sirainen , Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061471207@[10.0.1.6]> In-Reply-To: <1061484126.19011.119.camel@hurina> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Timo, --On Thursday, August 21, 2003 7:42 PM +0300 Timo Sirainen wrote: |> It is probably also necessary to say that only one ACL2= can be in |> the CAPABILITY line. | | My server supports multiple mailbox formats in same session. For example | UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability | wouldn't work. If that's going to be the case then there has to be a way for the client to discover which ACL mode is being used on any one particular mailbox. The current spec does not address that. This could be solved by having the ACL response in LIST return the mode if more than one is present in capability: C: A002 LIST (ACL) "" * S: * LIST () "/" INBOX (("ACL=UNIX" (("user=Fred" "rwipslextda")))) S: * LIST () "." #news (("ACL=AFS" (("user=Fred" "rwipslextda")))) S: A002 OK List with acl info completed -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LH11qt043227 for ; Thu, 21 Aug 2003 10:01:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LH11eo043226 for ietf-imapext-bks; Thu, 21 Aug 2003 10:01:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LH10qt043209 for ; Thu, 21 Aug 2003 10:01:00 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LH0kCK002311; Thu, 21 Aug 2003 10:00:46 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LH0kj8019416; Thu, 21 Aug 2003 10:00:46 -0700 Date: Thu, 21 Aug 2003 10:00:46 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: Rob Siemborski , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <1061484126.19011.119.camel@hurina> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061484126.19011.119.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Timo Sirainen wrote: > My server supports multiple mailbox formats in same session. For example > UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability > wouldn't work. SQL mailboxes, eh? OK, we need an eighth (or was it ninth?) ACL2=type model. Looks like that way won't scale. If we have some way to fetch a prototype that expresses how the server does access control, we wouldn't be in this situation. RFC 2086 LISTRIGHTS sort-of did this, but fell short of what is needed. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGsnqt042957 for ; Thu, 21 Aug 2003 09:54:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGsnsP042956 for ietf-imapext-bks; Thu, 21 Aug 2003 09:54:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGsmqt042951 for ; Thu, 21 Aug 2003 09:54:48 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGshoa031454; Thu, 21 Aug 2003 09:54:43 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGsgnN019105; Thu, 21 Aug 2003 09:54:43 -0700 Date: Thu, 21 Aug 2003 09:54:42 -0700 (PDT) From: Mark Crispin To: Paul Smith cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Paul Smith wrote: > Exactly. (not being a Unix developer) I can't see why Unix should have > special treatment and force an Internet standard to behave specially just > because Unix does it that way. I am not asking for UNIX to have special treatment. I am asking for the IMAP ACL specification to be well-designed enough that it can be implemented with the underlying store being a UNIX filesystem. For all the ranting and raving about how ACL should be "good" or "ideal", RFC 2086 is a very limited design that can not express valid UNIX ACLs. > Exactly (again). The IMAP4 server can implement *any* scheme of rights on > top of a file system. Forcing everyone into a non-ideal scheme just because > 'it'll be easier for Unix developers' is a bad idea. Please explain how an IMAP server, logged in as user joe and with user joe's filesystem access rights, can access a file on user mary's protected directory. If your answer is "user mary's directory should not be protected against joe", that's the whole point -- how is this to happen given that joe and mary only have IMAP access? Note that we do not want mary's directory to be accessible to her ex-boyfriend harry who has shell access to that system. There seems to be a false idea wedged inside the heads of certain individuals that an operating system is just an annoyance and that every Internet service can and should be its own operating system unto itself. In the real world, you can't just go off and design your own universe unto yourself. You have to work and interoperate with what is already there. That means making compromises, and going the extra mile because some other implementor is faced with a problem otherwise. Once upon a time, the Internet development community understood this. That is what gave us interoperable protocols such as TELNET, FTP, and SMTP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGgDqt042380 for ; Thu, 21 Aug 2003 09:42:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGgDGw042379 for ietf-imapext-bks; Thu, 21 Aug 2003 09:42:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGgBqt042373 for ; Thu, 21 Aug 2003 09:42:11 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id ACC7E5EBF9AE; Thu, 21 Aug 2003 19:42:06 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: Rob Siemborski Cc: ietf-imapext@imc.org In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Content-Type: text/plain Message-Id: <1061484126.19011.119.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 21 Aug 2003 19:42:06 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-08-21 at 17:54, Rob Siemborski wrote: > One way to do this would be to define an ACL2=UNIX, with a description > like the following (I suspect Mark could supply better text/requirements): Remember also that there's POSIX ACLs which want tied rights, but don't have the user/group count restriction. > It is probably also necessary to say that only one ACL2= can be in > the CAPABILITY line. My server supports multiple mailbox formats in same session. For example UNIX mailboxes and (in future) SQL mailboxes. A single ACL2 capability wouldn't work. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGeaqt042304 for ; Thu, 21 Aug 2003 09:40:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGeaNM042303 for ietf-imapext-bks; Thu, 21 Aug 2003 09:40:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGeZqt042297 for ; Thu, 21 Aug 2003 09:40:35 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGdnxu023101; Thu, 21 Aug 2003 09:39:49 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGdnjH018405; Thu, 21 Aug 2003 09:39:49 -0700 Date: Thu, 21 Aug 2003 09:39:49 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Cyrus Daboo , Larry Greenfield , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Rob Siemborski wrote: > There is still magic about identifiers, however (e.g. you can only have > one user, one group, and anyone in the UNIX model). ACL2's way of fixing the broken RFC 2086 model of identifers is one way of doing it. I can envision others, including some which may be cleaner. The only "magic" is that defining a group's right can remove another group's right; and this could be resolved with a means that makes it clear that there is only (and always) one group. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGYcqt042073 for ; Thu, 21 Aug 2003 09:34:38 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGYcPX042072 for ietf-imapext-bks; Thu, 21 Aug 2003 09:34:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGYbqt042066 for ; Thu, 21 Aug 2003 09:34:37 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGYXoa028052; Thu, 21 Aug 2003 09:34:33 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LGYXkn018282; Thu, 21 Aug 2003 09:34:33 -0700 Date: Thu, 21 Aug 2003 09:34:33 -0700 (PDT) From: Mark Crispin To: Pete Resnick cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Pete Resnick wrote: > 1. Who on this list has can and intends to implement ACL2 if it stays > in its current form? I intend to implement ACL2, as long as ACL2 does not preclude a compliant *and* useful implementation on UNIX the way that RFC 2086 did. I believe that ACL2 in its current form can be implemented in a compliant and useful way on UNIX. This is not to say that it is certain that I will not discover an unpleasant surprise in the process of implementing it; but I do not anticipate any such surprises. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGU8qt041944 for ; Thu, 21 Aug 2003 09:30:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGU8AD041943 for ietf-imapext-bks; Thu, 21 Aug 2003 09:30:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGU6qt041938 for ; Thu, 21 Aug 2003 09:30:06 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [195.149.15.4]) by smithers.nildram.co.uk (Postfix) with ESMTP id CCA11243218 for ; Thu, 21 Aug 2003 17:29:58 +0100 (BST) Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Thu, 21 Aug 2003 17:24:23 +0100 Message-Id: <5.2.1.1.2.20030821171215.05511eb0@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 21 Aug 2003 17:24:09 +0100 To: ietf-imapext@imc.org From: Paul Smith Subject: Re: acl-08: questions In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:38 21/08/2003 -0700, Mark Crispin wrote: >This horror will be inflicted >the IMAP world if the IMAP world refuses to bite the bullet and create a >general ACL model. Exactly. (not being a Unix developer) I can't see why Unix should have special treatment and force an Internet standard to behave specially just because Unix does it that way. IMAP4 isn't a Unix protocol, it's a platform independent Internet protocol. When designing an ACL standard, you should primarily design it to do its job, regardless of platform - ie be able to define access rights for various actions to various people/groups on various objects. Once you've got an ACL design that works well, then, if you want, you can look at the WHOLE RANGE of platforms it may be run on, to see if there's any minor changes that could be made to the design to make it easier to implement, but, if there's any hint of conflict, the 'good' design should obviously be preferred over the 'easy on one platform' design. >Tied rights aren't the problem. It's RFC 2086's broken design of >identifiers that were the problem. Exactly (again). The IMAP4 server can implement *any* scheme of rights on top of a file system. Forcing everyone into a non-ideal scheme just because 'it'll be easier for Unix developers' is a bad idea. When designing an ACL standard, the platforms it's going to run on should be the last thing to consider. It's possible to implement any ACL system I can think of using software, so come up with one that makes sense and then everyone can implement it that way (unless Unix developers aren't as resourceful as developers on other platforms ;-) ) Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGJKqt041677 for ; Thu, 21 Aug 2003 09:19:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LGJKbL041676 for ietf-imapext-bks; Thu, 21 Aug 2003 09:19:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LGJIqt041670 for ; Thu, 21 Aug 2003 09:19:19 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.2b2) for ; Thu, 21 Aug 2003 11:19:16 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <2147483647.1061465831@[10.0.1.6]> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> X-Mailer: Eudora [Macintosh version 6.0a29] Date: Thu, 21 Aug 2003 11:19:14 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: Re: acl-08: questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 8/21/03 at 11:37 AM -0400, Cyrus Daboo wrote: >This may be out of scope at this stage in the proceedings... I'm not picking on Cyrus; it was just a good line to quote. Before we get much further with this entire conversation: 1. Who on this list has can and intends to implement ACL2 if it stays in its current form? 2. Who on this list cannot implement ACL2 in its current form? It is way late in the game to be revisiting this topic yet again and I want to get a sense of where we are before we start down any sort of new path. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFrCqt040650 for ; Thu, 21 Aug 2003 08:53:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LFrCO1040649 for ietf-imapext-bks; Thu, 21 Aug 2003 08:53:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFrAqt040641 for ; Thu, 21 Aug 2003 08:53:10 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7LFr14w022814; Thu, 21 Aug 2003 11:53:01 -0400 Date: Thu, 21 Aug 2003 11:53:00 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Cyrus Daboo , Larry Greenfield , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Mark Crispin wrote: > Since there are no tied rights, there is no longer any magic about how > rights get set and cleared. Furthermore, the client has perfect knowledge > about the impact of what it does. > > The only wart is that we have to define what to do with operations which > either can not be granted or can not be revoked as a right. ACL's "a" > comes immediately to mind. Perhaps a template of such "fixed" items? There is still magic about identifiers, however (e.g. you can only have one user, one group, and anyone in the UNIX model). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFpBqt040489 for ; Thu, 21 Aug 2003 08:51:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LFpBIm040488 for ietf-imapext-bks; Thu, 21 Aug 2003 08:51:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFpAqt040479 for ; Thu, 21 Aug 2003 08:51:10 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LFoQoa020950; Thu, 21 Aug 2003 08:50:26 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LFoPQf015718; Thu, 21 Aug 2003 08:50:25 -0700 Date: Thu, 21 Aug 2003 08:50:25 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: Rob Siemborski , Larry Greenfield , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <2147483647.1061465831@[10.0.1.6]> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <2147483647.1061465831@[10.0.1.6]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Cyrus Daboo wrote: > This may be out of scope at this stage in the proceedings, but what I would > like to see is an ACL2 framework document that defines a basic set of > commands (ACL STORE/DELETE/SET, LISTRIGHTS) without explicit syntax Agreed. >, and > the core set of rights. Then separate ACL2=AFS and ACL2=UNIX documents that > implement the real extensions that provide specific implementations of this > wrt identifiers etc. Rob already described what ACL2=UNIX would look like, > and ACL2=AFS is pretty much already covered by the original ACL. Half-agree. I suggest something a bit different: Define a set of rights, not as protocol items, but as "operations". Then define a means by which a server announces the rights that it exports and what the operations are. For example, a UNIX server may says "I have a W right which permits operations wisd." In a Cyrus type server, it would have a one right/one operation export. Now, instead of defining ACL2=AFS, ACL2=UNIX, ACL2=BLURDYBLOOP, we have a general means by which the server announces how its access control model works. There would be no tied rights in the ACL commands themselves. They'll just use the server-announced rights, which on a UNIX server would probably be R and W. Since there are no tied rights, there is no longer any magic about how rights get set and cleared. Furthermore, the client has perfect knowledge about the impact of what it does. The only wart is that we have to define what to do with operations which either can not be granted or can not be revoked as a right. ACL's "a" comes immediately to mind. Perhaps a template of such "fixed" items? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFd6qt039667 for ; Thu, 21 Aug 2003 08:39:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LFd6g7039666 for ietf-imapext-bks; Thu, 21 Aug 2003 08:39:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFd5qt039651 for ; Thu, 21 Aug 2003 08:39:05 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LFcxoa019223; Thu, 21 Aug 2003 08:38:59 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7LFcwEW015312; Thu, 21 Aug 2003 08:38:58 -0700 Date: Thu, 21 Aug 2003 08:38:58 -0700 (PDT) From: Mark Crispin To: Rob Siemborski cc: Larry Greenfield , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003, Rob Siemborski wrote: > However, we keep coming back to this problem *only* because of the > specific case of the UNIX filesystem. I want to implement the specific case of the TOPS-20 filesystem as well. In my copious free time, I am upgrading the TOPS-20 IMAP server to talk IMAP4rev1 (currently it is at RFC 1176 state). This is becoming especially important since TOPS-20's mailer seems to be much more spam/virus-resistant than UNIX; apparently most spamware sends LF-only newlines which TOPS-20's SMTP server rejects. I can guess that perhaps some people may want to implement the specific case of the VMS filesystem. On a more serious vein, I am also working on the specific case of the Windows filesystem. You can't wish this problem away by saying that it is "just UNIX". > One way to do this would be to define an ACL2=UNIX I don't object to this, but be prepared for ACL2=TOPS-20, ACL2=VMS, ACL2=WINDOWS. Probably also ACL2=POSIX. This horror will be inflicted the IMAP world if the IMAP world refuses to bite the bullet and create a general ACL model. > This, of course, has the disadvantage of adding a third ACL model Fourth, fifth, sixth, and seventh. > I think there are less general implementation questions with this than > there are with arbitrary tied rights. If we do want to go forward with > the possibility of arbitrary tied rights, I would very much like to hear > about implementation experience. Tied rights aren't the problem. It's RFC 2086's broken design of identifiers that were the problem. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFbYqt039485 for ; Thu, 21 Aug 2003 08:37:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LFbYKC039483 for ietf-imapext-bks; Thu, 21 Aug 2003 08:37:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LFbWqt039474 for ; Thu, 21 Aug 2003 08:37:32 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA03333; Thu, 21 Aug 2003 11:33:06 -0400 (EDT) Date: Thu, 21 Aug 2003 11:37:11 -0400 From: Cyrus Daboo To: Rob Siemborski , Larry Greenfield cc: Mark Crispin , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions Message-ID: <2147483647.1061465831@[10.0.1.6]> In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Thursday, August 21, 2003 10:54 AM -0400 Rob Siemborski wrote: | This, of course, has the disadvantage of adding a third ACL model, and | extending what the model controls (instead of specifying just how access | is calculated, it also specifies what an ACL can look like). It also | probably requires client authors to do a little more work to support the | wildly different ACL model, though I think this is mitigated by avoiding | the need to deal with arbitrary tied rights. I was actually composing a message to propose something similar. Right now I think the current ACL2 is too complex from an implementation point of view. Frankly, if the client UI is any more complicated than the OS's UI for setting file system permissions, the ordinary users are not going to be able to cope - or even worse do something stupid and expose themselves to security breaches. I think the whole union vs most-specific bit is way out of scope for ordinary users - its fine if we're only targeting ACL at admins though. This may be out of scope at this stage in the proceedings, but what I would like to see is an ACL2 framework document that defines a basic set of commands (ACL STORE/DELETE/SET, LISTRIGHTS) without explicit syntax, and the core set of rights. Then separate ACL2=AFS and ACL2=UNIX documents that implement the real extensions that provide specific implementations of this wrt identifiers etc. Rob already described what ACL2=UNIX would look like, and ACL2=AFS is pretty much already covered by the original ACL. The benefit of this is that server vendors only need concern themselves with coding to the particular model that is specific to them. The disadvantage is that clients have to implement multiple extensions. However, the UIs for those can be specifically tailored to each and can have safety checks etc to aid users in setting things up. The ACL2 framework document should explicitly state that a client will be expected to support the official multiple variants of ACL2. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LEt8qt036786 for ; Thu, 21 Aug 2003 07:55:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LEt8OM036784 for ietf-imapext-bks; Thu, 21 Aug 2003 07:55:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LEt1qt036766 for ; Thu, 21 Aug 2003 07:55:02 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7LEsx4w022689; Thu, 21 Aug 2003 10:54:59 -0400 Date: Thu, 21 Aug 2003 10:54:59 -0400 (EDT) From: Rob Siemborski To: Larry Greenfield cc: Mark Crispin , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F43EF41.1060307@andrew.cmu.edu> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Larry Greenfield wrote: > > This argument has been made over and over again for years now, and has > > been rejected every time. > > > > If the IMAPEXT Working Group is unable to create an ACL mechanism that > > will support UNIX filesystem permissions, then it should declare > > defeat. > > The reason this keeps coming up is that UNIX filesystem permissions are > not ACLs. The insistence to force them into an ACL model is ungainly and > shows the problems with drastically increased complexity. > > RFC 2086 isn't implementable on top of AFS, either. While it is nice to > be able to export legacy mail stores via IMAP, it should not be a > requirement for every IMAP feature to support every legacy mail store. The constraints that the UNIX filesystem are currently placing on ACL2 cause several warts to appear in the design and usability of the specification. a) Arbitrary tied rights cause clients a problem in that it is hard to predict what a given command will do, even if we report what actually happened afterwards. This makes UI hard to design. b) Restrictions placed on identifiers also don't fit very well (as evidenced by Mark's 'ACL RENAME' proposal earlier this year) Dealing with this sort of thing in a general way is bound to cause interoperability problems, and make designing a reasonable client interface hard. However, we keep coming back to this problem *only* because of the specific case of the UNIX filesystem. It is unclear to me that there is a demand for arbitrary tied rights. What does appear to be demanded is the ability to use the UNIX filesystem mode bits. We shouldn't twist the entire protocol just to force ACL semantics onto the UNIX filesystem. However, it may be possible to just solve the UNIX filesystem case (within ACL2) without the above problems. One way to do this would be to define an ACL2=UNIX, with a description like the following (I suspect Mark could supply better text/requirements): a) an ACL must always have entries for 'user=(owner)' 'group=(a group)' and 'anyone'/'anonymous' - if the group or user is changed, than the current group or user is removed from the ACL. b) only the owner of the mailbox may have the 'a' rights c) the following rights for a given identifier must always be set or cleared together: 'swite' 'lr' (I'm not personally sure what happens to d, x, p, and c) d) negative rights are not allowed If a client violates any of these (say, buy setting rights separately, or by setting two groups in one command), simply return NO (and fail the entire command-- no ACL changes). This is a significant improvement because now a client knows *in advance* *exactly* how the server will react to a given ACL command. It can also provide an appropriate UI for each of UNIX, MOST-SPECIFIC, and UNION. The complexity of arbitrary tied rights can be removed, along with the desire for ACL RENAME, and the extra responses generated by tied rights commands which don't set all of the appropriate bits. This, of course, has the disadvantage of adding a third ACL model, and extending what the model controls (instead of specifying just how access is calculated, it also specifies what an ACL can look like). It also probably requires client authors to do a little more work to support the wildly different ACL model, though I think this is mitigated by avoiding the need to deal with arbitrary tied rights. It is probably also necessary to say that only one ACL2= can be in the CAPABILITY line. I think there are less general implementation questions with this than there are with arbitrary tied rights. If we do want to go forward with the possibility of arbitrary tied rights, I would very much like to hear about implementation experience. Comments? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L9e5qt012962 for ; Thu, 21 Aug 2003 02:40:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7L9e5jB012961 for ietf-imapext-bks; Thu, 21 Aug 2003 02:40:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L9e0qt012952 for ; Thu, 21 Aug 2003 02:40:05 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7L9hiV26562; Thu, 21 Aug 2003 03:43:45 -0600 Message-ID: <3F449368.3050706@isode.com> Date: Thu, 21 Aug 2003 10:39:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061419465.19010.110.camel@hurina> <200308202327.h7KNRSf16708@katroo.Sendmail.COM> In-Reply-To: <200308202327.h7KNRSf16708@katroo.Sendmail.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Timo Sirainen writes: > > >>On Thu, 2003-08-21 at 01:17, Mark Crispin wrote: >> >> >>>While we're at it, since you keep on asking to remove the reference >>>argument in LIST, we will also need to add CWD and PWD commands to replace >>>this functionality. >>> >>> >>I never really understood this. What exactly do you gain from the >>reference argument? Isn't LIST ref/ box exactly the same as >>LIST "" ref/box? >> >> > >There are at least two differences: >1) if the mailbox name argument starts with a namespace prefix, > then the reference argument is ignored (consider the last two rows > in the table on page 41 of rfc3051) >2) % and * should not be treated specially when present in the reference > argument > I am not sure that the 2 is true? Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KNRXqt064442 for ; Wed, 20 Aug 2003 16:27:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KNRXZY064441 for ietf-imapext-bks; Wed, 20 Aug 2003 16:27:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KNRWqt064435 for ; Wed, 20 Aug 2003 16:27:33 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.sendmail.com [63.211.143.38]) by spork.sendmail.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h7KNRQU2009000; Wed, 20 Aug 2003 16:27:26 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.7) with ESMTP id h7KNRSf16708; Wed, 20 Aug 2003 16:27:28 -0700 (PDT) Message-Id: <200308202327.h7KNRSf16708@katroo.Sendmail.COM> To: Timo Sirainen Cc: ietf-imapext@imc.org From: Philip Guenther Subject: Re: acl-08: questions In-reply-to: <1061419465.19010.110.camel@hurina> References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061419465.19010.110.camel@hurina> Date: Wed, 20 Aug 2003 16:21:24 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen writes: > >On Thu, 2003-08-21 at 01:17, Mark Crispin wrote: >> While we're at it, since you keep on asking to remove the reference >> argument in LIST, we will also need to add CWD and PWD commands to replace >> this functionality. > >I never really understood this. What exactly do you gain from the >reference argument? Isn't LIST ref/ box exactly the same as >LIST "" ref/box? There are at least two differences: 1) if the mailbox name argument starts with a namespace prefix, then the reference argument is ignored (consider the last two rows in the table on page 41 of rfc3051) 2) % and * should not be treated specially when present in the reference argument Philip Guenther guenther@sendmail.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KNFmqt064211 for ; Wed, 20 Aug 2003 16:15:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KNFmrf064210 for ietf-imapext-bks; Wed, 20 Aug 2003 16:15:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KNFlqt064205 for ; Wed, 20 Aug 2003 16:15:47 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KNFeCK004036; Wed, 20 Aug 2003 16:15:40 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KNFeXa028369 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 16:15:40 -0700 Date: Wed, 20 Aug 2003 16:16:02 -0700 (Pacific Daylight Time) From: Mark Crispin To: Timo Sirainen cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <1061419465.19010.110.camel@hurina> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> <1061419465.19010.110.camel@hurina> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 21 Aug 2003, Timo Sirainen wrote: > > While we're at it, since you keep on asking to remove the reference > > argument in LIST, we will also need to add CWD and PWD commands to replace > > this functionality. > I never really understood this. What exactly do you gain from the > reference argument? Isn't LIST ref/ box exactly the same as > LIST "" ref/box? No, those two are most certainly not the same. LIST ref/ box is equivalent to CWD ref/ LIST "" box This *may* be the equivalent of LIST "" ref/box or it may be something completely different. Consider LIST mail/ ~fred/box on a UNIX system. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMiVqt063496 for ; Wed, 20 Aug 2003 15:44:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KMiVN6063495 for ietf-imapext-bks; Wed, 20 Aug 2003 15:44:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMiTqt063489 for ; Wed, 20 Aug 2003 15:44:29 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 299105EBF9AE; Thu, 21 Aug 2003 01:44:26 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: Mark Crispin Cc: ietf-imapext@imc.org In-Reply-To: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Content-Type: text/plain Message-Id: <1061419465.19010.110.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 21 Aug 2003 01:44:26 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-08-21 at 01:17, Mark Crispin wrote: > While we're at it, since you keep on asking to remove the reference > argument in LIST, we will also need to add CWD and PWD commands to replace > this functionality. I never really understood this. What exactly do you gain from the reference argument? Isn't LIST ref/ box exactly the same as LIST "" ref/box? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMHGqt061860 for ; Wed, 20 Aug 2003 15:17:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KMHGlc061859 for ietf-imapext-bks; Wed, 20 Aug 2003 15:17:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KMHEqt061848 for ; Wed, 20 Aug 2003 15:17:15 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KMH9oa023532; Wed, 20 Aug 2003 15:17:09 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KMH9Xa024121 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 15:17:09 -0700 Date: Wed, 20 Aug 2003 15:17:30 -0700 (Pacific Daylight Time) From: Mark Crispin To: Larry Greenfield cc: Rob Siemborski , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F43EF41.1060307@andrew.cmu.edu> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> <3F43EF41.1060307@andrew.cmu.edu> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Larry Greenfield wrote: > The reason this keeps coming up is that UNIX filesystem permissions are > not ACLs. The insistence to force them into an ACL model is ungainly and > shows the problems with drastically increased complexity. IMHO, this is a flaw in the design of ACL; that is, RFC 2086 has certain unnecessary attributes which created the problem. > While it is nice to > be able to export legacy mail stores via IMAP, it should not be a > requirement for every IMAP feature to support every legacy mail store. ACL stands out as the one IMAP feature that (1) does not support legacy mail stores and (2) can not be addressed in some other way. Here is a possible alternative to having UNIX filesystem permissions in ACL2: 1) add UNIXACL extension 2) add UNIXCHMOD, UNIXCHOWN, UNIXCHGRP commands 3) add \UNIXMOD=xxx \UNIXGROUP=xxx \UNIXOWNER=xxx attributes to LIST While we're at it, since you keep on asking to remove the reference argument in LIST, we will also need to add CWD and PWD commands to replace this functionality. A successor to RFC 2683 will state that due since UNIX filesystems are so common, that all client and server implementations SHOULD implement UNIXACL in addition to ACL or ACL2. CWD/PWD will be mandatory to implement. Or.... We can stop this bickering and work together on a common specification that is suitable for all of us. I know which choice I prefer. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLxfqt060694 for ; Wed, 20 Aug 2003 14:59:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLxfRR060693 for ietf-imapext-bks; Wed, 20 Aug 2003 14:59:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLxeqt060652 for ; Wed, 20 Aug 2003 14:59:40 -0700 (PDT) (envelope-from leg@andrew.cmu.edu) Received: from mirapoint.corp.google.com (IDENT:mirapoint@mirapoint.corp.google.com [10.32.0.80]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h7KLxZ3d007608; Wed, 20 Aug 2003 14:59:35 -0700 Received: from andrew.cmu.edu (dunbar.corp.google.com [10.2.2.110]) by mirapoint.corp.google.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACN83917 (AUTH leg); Wed, 20 Aug 2003 14:59:30 -0700 (PDT) Message-ID: <3F43EF41.1060307@andrew.cmu.edu> Date: Wed, 20 Aug 2003 17:59:29 -0400 From: Larry Greenfield User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , Lyndon Nerenberg {VE6BBM} , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Wed, 20 Aug 2003, Rob Siemborski wrote: > >>It has been become clear that the ACL2 specification is made >>substantially more complex by the requirement that it be implemented >>on top of Unix filesystem permissions with tied rights. It is time to >>accept the fact that this may not be a reasonable requirement that can >>be satisfied in a simple and interoperable way. > > This argument has been made over and over again for years now, and has > been rejected every time. > > If the IMAPEXT Working Group is unable to create an ACL mechanism that > will support UNIX filesystem permissions, then it should declare > defeat. The reason this keeps coming up is that UNIX filesystem permissions are not ACLs. The insistence to force them into an ACL model is ungainly and shows the problems with drastically increased complexity. RFC 2086 isn't implementable on top of AFS, either. While it is nice to be able to export legacy mail stores via IMAP, it should not be a requirement for every IMAP feature to support every legacy mail store. Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLsaqt058708 for ; Wed, 20 Aug 2003 14:54:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLsaX1058707 for ietf-imapext-bks; Wed, 20 Aug 2003 14:54:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLsZqt058671 for ; Wed, 20 Aug 2003 14:54:35 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLsVgG026573; Wed, 20 Aug 2003 14:54:31 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLsVXa022434 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 14:54:31 -0700 Date: Wed, 20 Aug 2003 14:54:52 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lyndon Nerenberg {VE6BBM} cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <7B6BE881-D357-11D7-A887-000393D34A62@orthanc.ab.ca> Message-ID: References: <7B6BE881-D357-11D7-A887-000393D34A62@orthanc.ab.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: > > If you examine that code carefully, you will see that there is no > > requirement that it be used. > And ditto for POSIX ACLs. If you don't have them, you don't support > ACL2. There is a growing requirement to have ACLs in a traditional UNIX filesystem based IMAP environment. If ACL2 does not provide this, this requirement will mandate the creation of ACL3. It is bad enough that we will need ACL2. Please, let's solve the problem and avoid ACL3. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLn8qt056788 for ; Wed, 20 Aug 2003 14:49:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLn85V056787 for ietf-imapext-bks; Wed, 20 Aug 2003 14:49:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLn3qt056729 for ; Wed, 20 Aug 2003 14:49:03 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLmvoa018333; Wed, 20 Aug 2003 14:48:57 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLmv4A014230 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 14:48:57 -0700 Date: Wed, 20 Aug 2003 14:49:18 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: Lyndon Nerenberg {VE6BBM} , Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Rob Siemborski wrote: > It has been become clear that the ACL2 specification is made substantially > more complex by the requirement that it be implemented on top of Unix > filesystem permissions with tied rights. It is time to accept the fact > that this may not be a reasonable requirement that can be satisfied in a > simple and interoperable way. This argument has been made over and over again for years now, and has been rejected every time. If the IMAPEXT Working Group is unable to create an ACL mechanism that will support UNIX filesystem permissions, then it should declare defeat. I prefer that we work together in a spirit of cooperation without attacking the needs of a portion of the community. I do not understand why it is so important to certain individuals that IMAP not support UNIX filesystem permissions. I am not proposing that IMAP ACL not support Andrew filesystem permissions (which is essentially what RFC 2086 is). I am just trying to make IMAP ACL general enough to support other permission models. I need an ACL mechanism which supports UNIX filesystem permissions. If there is no other way, I will provide the IMAP world with a specification for a replacement to RFC 2086 which supports UNIX filesystem permissions. We would then end up with two non-interoperable ACL facilities in IMAP, and IESG will have to sort out the mess. I don't think that this is a good outcome. Please, let's work together and stop this sniping. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLiXqt055355 for ; Wed, 20 Aug 2003 14:44:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLiXso055354 for ietf-imapext-bks; Wed, 20 Aug 2003 14:44:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLiVqt055340 for ; Wed, 20 Aug 2003 14:44:32 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7KLiW63016413; Wed, 20 Aug 2003 15:44:32 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Wed, 20 Aug 2003 15:44:31 -0600 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-imapext@imc.org To: Mark Crispin From: Lyndon Nerenberg {VE6BBM} In-Reply-To: Message-Id: <7B6BE881-D357-11D7-A887-000393D34A62@orthanc.ab.ca> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, August 20, 2003, at 03:23 PM, Mark Crispin wrote: > On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: >>> What TCP/IP-specific network support is there in IMAP? >> Please examine tcp_unix.c in the c-client source code. > > If you examine that code carefully, you will see that there is no > requirement that it be used. And ditto for POSIX ACLs. If you don't have them, you don't support ACL2. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLSeqt050169 for ; Wed, 20 Aug 2003 14:28:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLSeqa050168 for ietf-imapext-bks; Wed, 20 Aug 2003 14:28:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLSdqt050143 for ; Wed, 20 Aug 2003 14:28:39 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) by lin1.andrew.cmu.edu (8.12.9/8.12.9) with ESMTP id h7KLSb4w021042; Wed, 20 Aug 2003 17:28:37 -0400 Date: Wed, 20 Aug 2003 17:28:37 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Lyndon Nerenberg {VE6BBM} , Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Mark Crispin wrote: > On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: > > Please remove all the network support from IMAP. IP networking not > > supported on versions of UNIX that pre-date the elitist 4.2BSD release. > > What TCP/IP-specific network support is there in IMAP? The KERBEROS_V4 SASL Mechanism described in RFC2222 (normative to 3501) requires IPv4 support. Of course, its perfectly possible to implement an IMAP server without support for the KERBEROS_V4 SASL mechanism. Its also perfectly possible to implement one without ACL[2] support. It should not be a requirement that all extentions of a protocol are implementable everywhere that the base protocol is implementable. It has been become clear that the ACL2 specification is made substantially more complex by the requirement that it be implemented on top of Unix filesystem permissions with tied rights. It is time to accept the fact that this may not be a reasonable requirement that can be satisfied in a simple and interoperable way. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLN3qt047998 for ; Wed, 20 Aug 2003 14:23:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLN3E5047997 for ietf-imapext-bks; Wed, 20 Aug 2003 14:23:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLN2qt047957 for ; Wed, 20 Aug 2003 14:23:02 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLMwCK017798; Wed, 20 Aug 2003 14:22:58 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KLMw4A012186 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 14:22:58 -0700 Date: Wed, 20 Aug 2003 14:23:19 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lyndon Nerenberg {VE6BBM} cc: ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: > > What TCP/IP-specific network support is there in IMAP? > Please examine tcp_unix.c in the c-client source code. If you examine that code carefully, you will see that there is no requirement that it be used. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLIkqt046336 for ; Wed, 20 Aug 2003 14:18:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLIknm046331 for ietf-imapext-bks; Wed, 20 Aug 2003 14:18:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLIiqt046311 for ; Wed, 20 Aug 2003 14:18:44 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7KLIi63016290; Wed, 20 Aug 2003 15:18:44 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Wed, 20 Aug 2003 15:18:43 -0600 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-imapext@imc.org To: Mark Crispin From: Lyndon Nerenberg {VE6BBM} In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > What TCP/IP-specific network support is there in IMAP? Please examine tcp_unix.c in the c-client source code. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KL7Tqt041844 for ; Wed, 20 Aug 2003 14:07:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KL7TP4041843 for ietf-imapext-bks; Wed, 20 Aug 2003 14:07:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KL7Rqt041802 for ; Wed, 20 Aug 2003 14:07:28 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KL7IgG018557; Wed, 20 Aug 2003 14:07:18 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KL7I4A010969 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 14:07:18 -0700 Date: Wed, 20 Aug 2003 14:07:40 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lyndon Nerenberg {VE6BBM} cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> Message-ID: References: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: > Please remove all the network support from IMAP. IP networking not > supported on versions of UNIX that pre-date the elitist 4.2BSD release. What TCP/IP-specific network support is there in IMAP? IMAP works quite well over non-TCP/IP links, or for that matter any link which provides a reliable stream. I've done IMAP over serial lines with a very basic checksum/retransmission protocol which was implemented in BASIC on an 8-bit micro. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKpFqt036572 for ; Wed, 20 Aug 2003 13:51:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KKpFrw036571 for ietf-imapext-bks; Wed, 20 Aug 2003 13:51:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKpDqt036565 for ; Wed, 20 Aug 2003 13:51:13 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7KKpA63016163; Wed, 20 Aug 2003 14:51:10 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Wed, 20 Aug 2003 14:51:09 -0600 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org To: Mark Crispin From: Lyndon Nerenberg {VE6BBM} In-Reply-To: Message-Id: <06C3567C-D350-11D7-A887-000393D34A62@orthanc.ab.ca> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Some people believe in compatibility with the past. Others do not. Please remove all the network support from IMAP. IP networking not supported on versions of UNIX that pre-date the elitist 4.2BSD release. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKEkqt035256 for ; Wed, 20 Aug 2003 13:14:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KKEkEs035255 for ietf-imapext-bks; Wed, 20 Aug 2003 13:14:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KKEjqt035249 for ; Wed, 20 Aug 2003 13:14:45 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KKEdCK006308; Wed, 20 Aug 2003 13:14:39 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KKEdXa015605 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 13:14:39 -0700 Date: Wed, 20 Aug 2003 13:15:00 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lyndon Nerenberg {VE6BBM} cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <46993FC6-D349-11D7-9BBA-000393D34A62@orthanc.ab.ca> Message-ID: References: <46993FC6-D349-11D7-9BBA-000393D34A62@orthanc.ab.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Lyndon Nerenberg {VE6BBM} wrote: > Which current versions of UNIX do not support POSIX ACLs? I really > don't think we have to think in the user/group/other paradigm any more. > This means sacrificing support for older UNIX variants. Oh well. The > future before us, not behind us. Some people believe in compatibility with the past. Others do not. I happen to believe in compatibility with the past, and as long as I am in any way associated with IMAP I will insist that IMAP do so. IMAP, like other Internet protocols, is not limited to elitist environments. Great effort went into the design of IMAP to support a wide variety of environments including 30 years' worth of legacy mail stores. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KK3Cqt034933 for ; Wed, 20 Aug 2003 13:03:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KK3BM8034932 for ietf-imapext-bks; Wed, 20 Aug 2003 13:03:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KK38qt034920 for ; Wed, 20 Aug 2003 13:03:10 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (peregrin.orthanc.ab.ca [192.168.42.6]) by orthanc.ab.ca (8.12.9/8.12.9) with ESMTP id h7KK2o63015963; Wed, 20 Aug 2003 14:02:50 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Wed, 20 Aug 2003 14:02:50 -0600 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org To: Mark Crispin From: Lyndon Nerenberg {VE6BBM} In-Reply-To: Message-Id: <46993FC6-D349-11D7-9BBA-000393D34A62@orthanc.ab.ca> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Please explain how a UNIX filesystem access control model is to > represent > ACL2 rights without tied rights. Which current versions of UNIX do not support POSIX ACLs? I really don't think we have to think in the user/group/other paradigm any more. This means sacrificing support for older UNIX variants. Oh well. The future before us, not behind us. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KJ7qqt032890 for ; Wed, 20 Aug 2003 12:07:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KJ7qPK032889 for ietf-imapext-bks; Wed, 20 Aug 2003 12:07:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KJ7oqt032873 for ; Wed, 20 Aug 2003 12:07:50 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 850565C896D9; Wed, 20 Aug 2003 22:07:41 +0300 (EEST) Subject: Re: acl-08: questions From: Timo Sirainen To: Mark Crispin Cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1061406461.24980.86.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 20 Aug 2003 22:07:41 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-08-20 at 21:58, Mark Crispin wrote: > On Wed, 20 Aug 2003, Timo Sirainen wrote: > > - if there's conflicting rules in same level (eg. two groups), the less > > permissive rights always takes precedence > > But what about if the server gets a request that has such a conflict? What request? Like adding ACL for two groups with conflicting rights with each others? I don't think there's any problem with that. If there are users who belong to those two groups, it works like I said above. Server shouldn't prevent ACL changes just because it might happen to create conflicts. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIxLqt032670 for ; Wed, 20 Aug 2003 11:59:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KIxLMo032669 for ietf-imapext-bks; Wed, 20 Aug 2003 11:59:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIxKqt032663 for ; Wed, 20 Aug 2003 11:59:20 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KIx4oa022800; Wed, 20 Aug 2003 11:59:04 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KIwqXa010780 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 11:59:00 -0700 Date: Wed, 20 Aug 2003 11:58:48 -0700 (Pacific Daylight Time) From: Mark Crispin To: Timo Sirainen cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Timo Sirainen wrote: > - if there's conflicting rules in same level (eg. two groups), the less > permissive rights always takes precedence But what about if the server gets a request that has such a conflict? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIrBqt032458 for ; Wed, 20 Aug 2003 11:53:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KIrBFu032457 for ietf-imapext-bks; Wed, 20 Aug 2003 11:53:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIrAqt032451 for ; Wed, 20 Aug 2003 11:53:10 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KIqvCK025400; Wed, 20 Aug 2003 11:53:02 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KIqc4A002161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 11:52:50 -0700 Date: Wed, 20 Aug 2003 11:52:35 -0700 (Pacific Daylight Time) From: Mark Crispin To: Timo Sirainen cc: Alexey Melnikov , Barry Leiba , IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Timo Sirainen wrote: > The capability string is already getting annoyingly large and having > some extension give two capabilities makes it even worse. Why not just > make LIST-SUBSCRIBED behaviour required by LISTEXT itself? All servers > are able to implement that functionality and it most likely won't take > many lines of code. If LIST-SUBSCRIBED is to become mandatory to implement I would like to see some changes. In particular, it should be alright for LIST-SUBSCRIBED to be implemented as a LIST that shows only mailboxes that are in the LSUB subscription list. That distinction is important to me. LSUB can include names that would not show up in LIST. Consider # namespaces vs. *. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIXbqt031773 for ; Wed, 20 Aug 2003 11:33:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KIXbCO031771 for ietf-imapext-bks; Wed, 20 Aug 2003 11:33:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KIXZqt031762 for ; Wed, 20 Aug 2003 11:33:35 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id A8BED238C6; Wed, 20 Aug 2003 21:33:31 +0300 (EEST) Received: from iki.fi (unknown [192.168.123.201]) by danu.procontrol.fi (Postfix) with ESMTP id 1F3E923896; Wed, 20 Aug 2003 21:33:30 +0300 (EEST) Date: Wed, 20 Aug 2003 21:33:41 +0300 Subject: Re: acl-08: questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Larry Greenfield , Alexey Melnikov , ietf-imapext@imc.org To: Mark Crispin From: Timo Sirainen In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, Aug 20, 2003, at 20:31 Europe/Helsinki, Mark Crispin wrote: > One of the purposes of the ACL2 exercise it to make IMAP ACL > implementable > with the UNIX filesystem access control model. If ACL2 does not do > this, > then it will be a failure. IMHO rule identifiers are still it's biggest potential failure. I know I already hate them. And I don't think there really is a need for them. There really isn't need a for tied rights either, although they could help. All that really is needed is ability for servers to accurately describe to clients what the current access rights are. If client requests some change that server cannot perform exactly, it would do what it thinks is the best and return the new rights to client. Server should never grant anyone more permissions than what was requested by client. Tied rights are one way to prevent this, another way would be to give client a suggestion of what rights server would accept instead of the one it asked. That might give worse user interface, but it would be more flexible. Anyway, the single rule that I think should be able to describe all kinds of rights: - you have + and - rights - you get union of rights - more specific rules always overrides less specific rules if they have conflicting rights - if there's conflicting rules in same level (eg. two groups), the less permissive rights always takes precedence For example: -r---w-rw- 1 cras users 40013065 Jul 12 02:11 inbox "ACL" (("user=cras" "r-w") ("group=users" "w-r") ("anyone" "rw")) I don't remember the exact ACL equilevants to rw now, but the idea should work. Only problem with having only single rule is that client wouldn't have exact knowledge of how the server works, but it probably couldn't know it in any case, unix group changing as one example. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHvDqt029222 for ; Wed, 20 Aug 2003 10:57:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KHvDGG029221 for ietf-imapext-bks; Wed, 20 Aug 2003 10:57:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHvBqt029198 for ; Wed, 20 Aug 2003 10:57:11 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 7CCAA2399C; Wed, 20 Aug 2003 20:57:02 +0300 (EEST) Received: from iki.fi (unknown [192.168.123.201]) by danu.procontrol.fi (Postfix) with ESMTP id A3DA523996; Wed, 20 Aug 2003 20:57:00 +0300 (EEST) Date: Wed, 20 Aug 2003 20:57:12 +0300 Subject: Re: Last Calling the LISTEXT draft? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Alexey Melnikov , Barry Leiba , IMAP extensions Mailing List To: Mark Crispin From: Timo Sirainen In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, Aug 20, 2003, at 19:10 Europe/Helsinki, Mark Crispin wrote: > Alternatively, have no LIST-xxx of any type and only LISTEXT, and > depend > everything upon another extension. We have a MAILBOX-REFERRALS and (I > think) a CHILDREN extension. The only problem is LIST-SUBSCRIBED. The capability string is already getting annoyingly large and having some extension give two capabilities makes it even worse. Why not just make LIST-SUBSCRIBED behaviour required by LISTEXT itself? All servers are able to implement that functionality and it most likely won't take many lines of code. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHVHqt027565 for ; Wed, 20 Aug 2003 10:31:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KHVH9O027564 for ietf-imapext-bks; Wed, 20 Aug 2003 10:31:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHVEqt027559 for ; Wed, 20 Aug 2003 10:31:16 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KHV8xu001109; Wed, 20 Aug 2003 10:31:13 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KHV8Qh023895; Wed, 20 Aug 2003 10:31:08 -0700 Date: Wed, 20 Aug 2003 10:31:08 -0700 (PDT) From: Mark Crispin To: Larry Greenfield cc: Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F43A3F5.2080406@andrew.cmu.edu> Message-ID: References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> <3F435473.2000302@isode.com> <3F43A3F5.2080406@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Larry Greenfield wrote: > >> . Do we have any experience with servers that have tied rights with > >> the current ACL specification? > > I have no idea. Anybody? > If there is no experience, I would guess that this is a feature that no > client is going to be able to display correctly and comprehensibly and > it should be dropped. Please explain how a UNIX filesystem access control model is to represent ACL2 rights without tied rights. The only way that I can see this working is if a server is permitted to tie rights internally, and thus just magically change rights without announcing to the client how it works. I don't know how this magic should work if a request simultaneously asks to remove a right and to add a right that is tied to the removed right. Tied rights were presumably intended to prevent this. One of the purposes of the ACL2 exercise it to make IMAP ACL implementable with the UNIX filesystem access control model. If ACL2 does not do this, then it will be a failure. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHL7qt027173 for ; Wed, 20 Aug 2003 10:21:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KHL780027172 for ietf-imapext-bks; Wed, 20 Aug 2003 10:21:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KHL6qt027163 for ; Wed, 20 Aug 2003 10:21:06 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KHKsin018111; Wed, 20 Aug 2003 10:20:59 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KHKsVm022955; Wed, 20 Aug 2003 10:20:54 -0700 Date: Wed, 20 Aug 2003 10:20:54 -0700 (PDT) From: Mark Crispin To: Larry Greenfield cc: Steve Hole , Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions In-Reply-To: <3F43A2E7.409@andrew.cmu.edu> Message-ID: References: <3F435473.2000302@isode.com> <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> <3F43A2E7.409@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Larry Greenfield wrote: > We should be designing protocols to have simple, analogous rules, not > "oh, in this circumstance only X is allowed, but in this circumstance > only Y". > > I strongly disagree with confining ACLs to "quoted". FWIW, I agree with Larry here. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGtDqt025780 for ; Wed, 20 Aug 2003 09:55:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGtDOB025779 for ietf-imapext-bks; Wed, 20 Aug 2003 09:55:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGtCqt025772 for ; Wed, 20 Aug 2003 09:55:12 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7KGx0V28504; Wed, 20 Aug 2003 10:59:00 -0600 Message-ID: <3F43A7EA.8090008@isode.com> Date: Wed, 20 Aug 2003 17:55:06 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Larry Greenfield CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> <3F435473.2000302@isode.com> <3F43A3F5.2080406@andrew.cmu.edu> In-Reply-To: <3F43A3F5.2080406@andrew.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Larry Greenfield wrote: > Alexey Melnikov wrote: > >> [Sorry, it took me ages to write a full reply to this message.] >> >> Lawrence Greenfield wrote: >> >>> . Why is there no 'anonymous' identifier in addition to 'anyone' and >>> 'authuser'? >> >> >> I've just added "anonymous" as a synonym for "anyone" (actually the >> other way around). Any objections to this? > > > "anonymous" is defined in the current draft as only the anonymous > user. It does not include all users. the current is draft-ietf-imapext-acl-09.txt, section 3.1 a). "anonymous" - special group that refers to the universal identity (all authentications, including anonymous). A special identifier "anyone" is a synonym for the "anonymous". Is this what you want? >>> . Do we have any experience with servers that have tied rights with >>> the current ACL specification? >>> >> I have no idea. Anybody? > > > If there is no experience, I would guess that this is a feature that > no client is going to be able to display correctly and comprehensibly > and it should be dropped. Mark will probably use this. I am not going to do any changes unless I hear more opinions. >> Now, does anybody has an argument for allowing rights to be >> represented as literals? >> If the working group thinks that, I will change the document. >> >>> How a string is sent is a lexical issue. Where strings are allowed is >>> a grammar issue. It's unfortunate that we specify both levels in a >>> single ABNF, but that's no reason to allow the two levels to mix. >> > > You helpfully quoted my argument right below your question. It was > correct when I wrote it and it's still correct now. And BINARY allows for 8bit data only in certain places. I am sorry, but I just fail to see this as a big deal. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGcKqt025058 for ; Wed, 20 Aug 2003 09:38:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGcK0Q025057 for ietf-imapext-bks; Wed, 20 Aug 2003 09:38:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGcJqt025049 for ; Wed, 20 Aug 2003 09:38:19 -0700 (PDT) (envelope-from leg@andrew.cmu.edu) Received: from mirapoint.corp.google.com (IDENT:mirapoint@mirapoint.corp.google.com [10.32.0.80]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h7KGcG3d020335; Wed, 20 Aug 2003 09:38:16 -0700 Received: from andrew.cmu.edu (dunbar.corp.google.com [10.2.2.110]) by mirapoint.corp.google.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACN53924 (AUTH leg); Wed, 20 Aug 2003 09:38:14 -0700 (PDT) Message-ID: <3F43A3F5.2080406@andrew.cmu.edu> Date: Wed, 20 Aug 2003 12:38:13 -0400 From: Larry Greenfield User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexey Melnikov CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> <3F435473.2000302@isode.com> In-Reply-To: <3F435473.2000302@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > [Sorry, it took me ages to write a full reply to this message.] > > Lawrence Greenfield wrote: > >> . Why is there no 'anonymous' identifier in addition to 'anyone' and >> 'authuser'? > > I've just added "anonymous" as a synonym for "anyone" (actually the > other way around). Any objections to this? "anonymous" is defined in the current draft as only the anonymous user. It does not include all users. >> . Do we have any experience with servers that have tied rights with >> the current ACL specification? >> > I have no idea. Anybody? If there is no experience, I would guess that this is a feature that no client is going to be able to display correctly and comprehensibly and it should be dropped. > Now, does anybody has an argument for allowing rights to be represented > as literals? > If the working group thinks that, I will change the document. > >> How a string is sent is a lexical issue. Where strings are allowed is >> a grammar issue. It's unfortunate that we specify both levels in a >> single ABNF, but that's no reason to allow the two levels to mix. You helpfully quoted my argument right below your question. It was correct when I wrote it and it's still correct now. Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGXpqt024931 for ; Wed, 20 Aug 2003 09:33:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGXpB8024930 for ietf-imapext-bks; Wed, 20 Aug 2003 09:33:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGXoqt024924 for ; Wed, 20 Aug 2003 09:33:50 -0700 (PDT) (envelope-from leg@andrew.cmu.edu) Received: from mirapoint.corp.google.com (IDENT:mirapoint@mirapoint.corp.google.com [10.32.0.80]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h7KGXk3d017743; Wed, 20 Aug 2003 09:33:46 -0700 Received: from andrew.cmu.edu (dunbar.corp.google.com [10.2.2.110]) by mirapoint.corp.google.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACN53462 (AUTH leg); Wed, 20 Aug 2003 09:33:44 -0700 (PDT) Message-ID: <3F43A2E7.409@andrew.cmu.edu> Date: Wed, 20 Aug 2003 12:33:43 -0400 From: Larry Greenfield User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Hole CC: Alexey Melnikov , ietf-imapext@imc.org Subject: Re: acl-08: questions References: <3F435473.2000302@isode.com> <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hole wrote: >>>. The ABNF rule "rights = quoted" is unacceptable. We want to >>>encourage the use of literals, not create more special cases in the >>>protocol where only a subset of string representations are >>>allowed. It's not clear to me why this change was made. >> >>Now, does anybody has an argument for allowing rights to be represented >>as literals? >>If the working group thinks that, I will change the document. > > > I can see no good reason why the rights string should be a literal > The set of characters that can legally be placed in the string is > restricted and can never included anything outside of that character > set. > > Even though I (of course) understand Alexey's issue on the difficulty > of parsing literals in an asynchronous processor, I really wouldn't > consider that to be a good enough reason to reject a literal syntax. > The real issue is that this is a string of a fixed set of ascii > characters. Anything outside that set is illegal. There is no > reason to invoke the complexity of a literal string parse in that > instance. Intermingling lexical and syntactic levels of a protocol increases complexity. It is not simplifying. The more special cases the harder it is to get things right. How many clients refuse to parse literals in certain places, even though they're allowed? This mistake is made because the examples don't show literals where they're allowed and the ABNF is already extremely confusing. We should be designing protocols to have simple, analogous rules, not "oh, in this circumstance only X is allowed, but in this circumstance only Y". I strongly disagree with confining ACLs to "quoted". Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGVqqt024861 for ; Wed, 20 Aug 2003 09:31:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGVqEl024860 for ietf-imapext-bks; Wed, 20 Aug 2003 09:31:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGVpqt024855 for ; Wed, 20 Aug 2003 09:31:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7KGZbV24463; Wed, 20 Aug 2003 10:35:37 -0600 Message-ID: <3F43A26E.2090708@isode.com> Date: Wed, 20 Aug 2003 17:31:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Barry Leiba , IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? References: <3F420A9B.40406@isode.com> <004701c3668b$9200d040$40280209@watson.ibm.com> <3F4358A4.7060008@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >On Wed, 20 Aug 2003, Alexey Melnikov wrote: > > >>However we need to keep LISTEXT as a capability name. Many extensions >>will depend on LISTEXT framework, but will not be named LIST-. >> >> > >I'm saying that they should. Otherwise, we will having magic behaviors >that inevitably will be misimplemented. People can't even get the IMAP >base spec right; what makes you think that they'll realize that LISTEXT >plus ACL2 implies LIST-ACL2? > No, ACL2 requires LISTEXT support. And ACL2 has own naming scheme already. I don't want to report LIST-ACL2=UNION. >I certainly understand the motivation, and in a perfect world it's >undeniably better. But we live in a very imperfect world. > >>A good example is ACL2, which defines its own capability prefix. >>A client should have an easy way of knowing if extended LIST syntax is >>supported by the server. >> >> > >Why not LIST-ACL2? > >Alternatively, have no LIST-xxx of any type and only LISTEXT, and depend >everything upon another extension. We have a MAILBOX-REFERRALS and (I >think) a CHILDREN extension. The only problem is LIST-SUBSCRIBED. > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGAYqt024044 for ; Wed, 20 Aug 2003 09:10:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGAYv7024043 for ietf-imapext-bks; Wed, 20 Aug 2003 09:10:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGAXqt024020 for ; Wed, 20 Aug 2003 09:10:33 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KGANgG031207; Wed, 20 Aug 2003 09:10:28 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7KGAMpx019272; Wed, 20 Aug 2003 09:10:22 -0700 Date: Wed, 20 Aug 2003 09:10:22 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov cc: Barry Leiba , IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? In-Reply-To: <3F4358A4.7060008@isode.com> Message-ID: References: <3F420A9B.40406@isode.com> <004701c3668b$9200d040$40280209@watson.ibm.com> <3F4358A4.7060008@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003, Alexey Melnikov wrote: > However we need to keep LISTEXT as a capability name. Many extensions > will depend on LISTEXT framework, but will not be named LIST-. I'm saying that they should. Otherwise, we will having magic behaviors that inevitably will be misimplemented. People can't even get the IMAP base spec right; what makes you think that they'll realize that LISTEXT plus ACL2 implies LIST-ACL2? I certainly understand the motivation, and in a perfect world it's undeniably better. But we live in a very imperfect world. > A good example is ACL2, which defines its own capability prefix. > A client should have an easy way of knowing if extended LIST syntax is > supported by the server. Why not LIST-ACL2? Alternatively, have no LIST-xxx of any type and only LISTEXT, and depend everything upon another extension. We have a MAILBOX-REFERRALS and (I think) a CHILDREN extension. The only problem is LIST-SUBSCRIBED. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KEspqt019566 for ; Wed, 20 Aug 2003 07:54:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KEsn5O019563 for ietf-imapext-bks; Wed, 20 Aug 2003 07:54:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KEshqt019550 for ; Wed, 20 Aug 2003 07:54:43 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7KEwSV11005; Wed, 20 Aug 2003 08:58:28 -0600 From: Steve Hole Date: Wed, 20 Aug 2003 08:58:28 -0700 To: Alexey Melnikov Subject: Re: acl-08: questions Cc: Lawrence Greenfield , ietf-imapext@imc.org In-Reply-To: <3F435473.2000302@isode.com> References: <3F435473.2000302@isode.com> <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7KEshqt019554 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 20 Aug 2003 11:58:59 +0100 Alexey Melnikov wrote: > > . The ABNF rule "rights = quoted" is unacceptable. We want to > > encourage the use of literals, not create more special cases in the > > protocol where only a subset of string representations are > > allowed. It's not clear to me why this change was made. > > Now, does anybody has an argument for allowing rights to be represented > as literals? > If the working group thinks that, I will change the document. I can see no good reason why the rights string should be a literal. The set of characters that can legally be placed in the string is restricted and can never included anything outside of that character set. Even though I (of course) understand Alexey's issue on the difficulty of parsing literals in an asynchronous processor, I really wouldn't consider that to be a good enough reason to reject a literal syntax. The real issue is that this is a string of a fixed set of ascii characters. Anything outside that set is illegal. There is no reason to invoke the complexity of a literal string parse in that instance. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KBGwqt003332 for ; Wed, 20 Aug 2003 04:16:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KBGwZj003331 for ietf-imapext-bks; Wed, 20 Aug 2003 04:16:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KBGvqt003326 for ; Wed, 20 Aug 2003 04:16:57 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7KBKhV21486; Wed, 20 Aug 2003 05:20:43 -0600 Message-ID: <3F4358A4.7060008@isode.com> Date: Wed, 20 Aug 2003 12:16:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Barry Leiba , IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? References: <3F420A9B.40406@isode.com> <004701c3668b$9200d040$40280209@watson.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >The ways in which the three LISTEXT options are available or not available >is ugly. SUBSCRIBED doesn't have to be implemented unless the server also >advertises LIST-SUBSCRIBED; REMOTE doesn't have to be implemented unless >the server also advertises MAILBOX-REFERRALS; CHILDREN doesn't have to be >implemented as long as it's ignored. > >Suggest that there be a capability for each LISTEXT option now and in the >future, and get rid of the LISTEXT capability. In other words, > LIST-SUBSCRIBED LIST-REMOTE LIST-CHILDREN >for a "full server". > > And most clients should be able to cope with \PlaceHolder anyway. I tend to agree with Mark on separating the base LISTEXT framework from LISTEXT extensions. However we need to keep LISTEXT as a capability name. Many extensions will depend on LISTEXT framework, but will not be named LIST-. A good example is ACL2, which defines its own capability prefix. A client should have an easy way of knowing if extended LIST syntax is supported by the server. >Reference is made to ACL for "extended set", but nothing about this >elsewhere in the document. Suggest either saying "for a possible future >LIST-ACL extension" or replacing with obviously bogus sample data, e.g.: > > (("tablecloth" (("fringe" "lacy")("color" "white")))("X-Sample" > "text")) > or... > (("tablecloth" ("fringe" "lacy"))("X-Sample" "text")) > I would prefer the latter, as this doesn't cause a confusion with ACL2. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KAx8qt002525 for ; Wed, 20 Aug 2003 03:59:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KAx8kq002524 for ietf-imapext-bks; Wed, 20 Aug 2003 03:59:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KAx3qt002519 for ; Wed, 20 Aug 2003 03:59:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7KB2oV19599; Wed, 20 Aug 2003 05:02:50 -0600 Message-ID: <3F435473.2000302@isode.com> Date: Wed, 20 Aug 2003 11:58:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lawrence Greenfield CC: ietf-imapext@imc.org Subject: Re: acl-08: questions References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> In-Reply-To: <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Sorry, it took me ages to write a full reply to this message.] Lawrence Greenfield wrote: > . Why is there no 'anonymous' identifier in addition to 'anyone' and > 'authuser'? I've just added "anonymous" as a synonym for "anyone" (actually the other way around). Any objections to this? > . Do we have any experience with servers that have tied rights with > the current ACL specification? > I have no idea. Anybody? > . I don't follow how ACL2=MOST-SPECIFIC works. When there are two > groups, which is more specific? What about "authuser" versus a group > that might contain "anonymous"? > > There needs to be a formal definition of how to order two rules. > I've changed the definition of ACL to be an "ordered list" instead of a "set". All entries are added to the end (unless they replace another member). This should have no effect on ACL2=UNION. To answer your question about "authuser" versa a group containing "anonymous". "authuser" is just a special group. If it is listed before the group containing "anonymous", it will be used. > . The ABNF rule "rights = quoted" is unacceptable. We want to > encourage the use of literals, not create more special cases in the > protocol where only a subset of string representations are > allowed. It's not clear to me why this change was made. I think I've expressed my opinion on this before, but I will try to write an extended answer that should clarify my position. 1). Speaking as a server implementor, I have to say that parsing literals (excluding non-synchronizing one) in a multithreaded server that uses asynchronous or non-blocking IO is a major headache. This is caused by the fact that the data is not following "}" immediately. Our non-blocking parser works the following way: a simple high level parser reads character until it sees CR LF pair. After that it calls the lower level parser that understand details of IMAP. Each time there is a literal, you have to save the current state, which adds to code complexity. Sure, this is my implementation. There are other, probably better ways of achieving this in a multithreaded environment. 2). ACL rights consist of a set of characters that denote rights. There is no need to i18ze them. There should be never any reason for this. Control and other weird characters are not allowed. In my client I emit literals only if there are characters that are not allowed in a quoted string. So, I think that quoted strings are easier for certain servers and there is no much burden (if at all) for clients. And we don't need 8bit characters in "rights". Now, does anybody has an argument for allowing rights to be represented as literals? If the working group thinks that, I will change the document. > How a string is sent is a lexical issue. Where strings are allowed is > a grammar issue. It's unfortunate that we specify both levels in a > single ABNF, but that's no reason to allow the two levels to mix. > > Larry > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K2BGqt048842 for ; Tue, 19 Aug 2003 19:11:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7K2BGxw048841 for ietf-imapext-bks; Tue, 19 Aug 2003 19:11:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K2BAqt048834 for ; Tue, 19 Aug 2003 19:11:10 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7K2B1oa011497; Tue, 19 Aug 2003 19:11:06 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h7K2B1Xa012682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Aug 2003 19:11:01 -0700 Date: Tue, 19 Aug 2003 19:11:22 -0700 (Pacific Daylight Time) From: Mark Crispin To: Barry Leiba cc: Alexey Melnikov , IMAP extensions Mailing List Subject: Re: Last Calling the LISTEXT draft? In-Reply-To: <004701c3668b$9200d040$40280209@watson.ibm.com> Message-ID: References: <3F420A9B.40406@isode.com> <004701c3668b$9200d040$40280209@watson.ibm.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The ways in which the three LISTEXT options are available or not available is ugly. SUBSCRIBED doesn't have to be implemented unless the server also advertises LIST-SUBSCRIBED; REMOTE doesn't have to be implemented unless the server also advertises MAILBOX-REFERRALS; CHILDREN doesn't have to be implemented as long as it's ignored. Suggest that there be a capability for each LISTEXT option now and in the future, and get rid of the LISTEXT capability. In other words, LIST-SUBSCRIBED LIST-REMOTE LIST-CHILDREN for a "full server". Reference is made to ACL for "extended set", but nothing about this elsewhere in the document. Suggest either saying "for a possible future LIST-ACL extension" or replacing with obviously bogus sample data, e.g.: (("tablecloth" (("fringe" "lacy")("color" "white")))("X-Sample" "text")) or... (("tablecloth" ("fringe" "lacy"))("X-Sample" "text")) -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJtjqt021145 for ; Tue, 19 Aug 2003 12:55:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JJtjU3021144 for ietf-imapext-bks; Tue, 19 Aug 2003 12:55:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJtjqt021139 for ; Tue, 19 Aug 2003 12:55:45 -0700 (PDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 019AE206608 for ; Tue, 19 Aug 2003 15:54:08 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19pCG2-0003CJ-7F for ietf-announce-list@asgard.ietf.org; Tue, 19 Aug 2003 15:35:06 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19pCFy-0003AR-CJ for all-ietf@asgard.ietf.org; Tue, 19 Aug 2003 15:35:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03693; Tue, 19 Aug 2003 15:34:56 -0400 (EDT) Message-Id: <200308191934.PAA03693@ietf.org> To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-acl-09.txt Date: Tue, 19 Aug 2003 15:34:56 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+76459_15913104021353_48263776221" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --MIMEStream=_0+76459_15913104021353_48263776221 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 ACL extension Author(s) : A. Melnikov Filename : draft-ietf-imapext-acl-09.txt Pages : 10 Date : 2003-8-19 The ACL (Access Control List) extension of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-acl-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-acl-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+76459_15913104021353_48263776221 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+173044_765583334319_329585914397" --MIMEStream=_1+173044_765583334319_329585914397 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19155045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-acl-09.txt --MIMEStream=_1+173044_765583334319_329585914397 Content-Type: Message/External-body; name="draft-ietf-imapext-acl-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19155045.I-D@ietf.org> --MIMEStream=_1+173044_765583334319_329585914397-- --MIMEStream=_0+76459_15913104021353_48263776221-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJrfqt021057 for ; Tue, 19 Aug 2003 12:53:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JJrefZ021056 for ietf-imapext-bks; Tue, 19 Aug 2003 12:53:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJrbqt021051 for ; Tue, 19 Aug 2003 12:53:38 -0700 (PDT) (envelope-from leiba@watson.ibm.com) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [9.2.112.58]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h7JJpGj117158; Tue, 19 Aug 2003 15:51:16 -0400 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7/8.11.7) with SMTP id h7JJrXQ34530; Tue, 19 Aug 2003 15:53:33 -0400 Message-ID: <004701c3668b$9200d040$40280209@watson.ibm.com> From: "Barry Leiba" To: "Alexey Melnikov" Cc: "IMAP extensions Mailing List" References: <3F420A9B.40406@isode.com> Subject: Re: Last Calling the LISTEXT draft? Date: Tue, 19 Aug 2003 15:53:32 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0044_01C3666A.0A9BB910" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C3666A.0A9BB910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Can we Last Call the LISTEXT document? It is pretty stable for a while now. Yeah, the reason I re-posted it with the last set of minor (very minor) changes was to get it put in for last call, at Pete's request. So, Pete, are we requesting last call? > Except for horrible formatting ;-), I don't have any issues with it. The formatting is puzzling me; is it me, or is it the I-D editor? This didn't used to happen, but the last couple of submissions I've made have had that formatting problem. I checked this before I sent it. I'm attaching the text file here -- someone tell me what the problem is, please, so I can stop it from happening the next time. Barry -- Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba ------=_NextPart_000_0044_01C3666A.0A9BB910 Content-Type: text/plain; name="draft-ietf-imapext-list-extensions-04.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-imapext-list-extensions-04.txt" =0A= =0A= IMAP Extensions Working Group B. Leiba Internet Draft IBM T.J. Watson Research Center Document: draft-ietf-imapext-list-extensions-04.txt August 2003 Expires January 2004 IMAP4 LIST Command Extensions =0A= Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. A revised version of this draft document will be submitted to the RFC editor as an Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to ietf-imapext@imc.org. This document will expire before 31 January 2004. Distribution of this memo is unlimited. =0A= 1. Abstract IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. =0A= B. Leiba Expires January 2004 [Page = 1]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= =0A= 2. Conventions used in this document In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client. The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in this document as specified in RFC 2119 [Keywords]. =0A= 3. Introduction The extensions to the LIST command will be accomplished by amending the syntax to allow options to be specified. The list of options will replace the several commands that are currently used to mix and match the information requested. The new syntax is backward- compatible, with no ambiguity: if the first word after the command name begins with a parenthesis, the new syntax is being used; if it does not, it's in the original syntax. By adding options to the LIST command, we are announcing the intent to phase out and eventually to deprecate the RLIST and RLSUB commands described in [MboxRefer]. We are also defining the mechanism to request extended mailbox information, such as is described in the now-expired "Child Mailbox Extension" draft [ChildMbox]. The base LSUB command is not deprecated by this extension; rather, this extension adds a way to obtain subscription information with more options, with those server implementations that support it. Clients that simply need a list of subscribed mailboxes, as provided by the LSUB command, SHOULD continue to use that command. =0A= 4. LIST Command Options The LIST command syntax is extended by adding a parenthesized list of command options between the command name and the reference name (see the formal syntax in section 6 for specific details). Command options will be defined in this document and in approved extension documents; each option will be enabled by a capability string (one capability may enable multiple options), and a client MUST NOT send an option for which the server has not advertised support. A server MUST respond to options it does not recognize with a NO response. This extension is identified by the capability string "LISTEXT", and support for it is a prerequisite for any future extensions that require specialized forms of the LIST command. Such extensions MUST refer to this document and MUST add their function through command options as described herein. This document also defines the "LIST- =0A= B. Leiba Expires January 2004 [Page = 2]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= SUBSCRIBED" capability string; see the "SUBSCRIBED" option below. This extension also defines extensions to the LIST response, allowing a series of extended fields at the end, a parenthesized list of attriobute/value pairs. Each attribute is a string, each value may be a string or a nested parenthesized list of the same attribute/value pairs. An example of this extended set might be (("ACL" (("id" "user=3Dfred")("rights" "rwi")))("X-Sample" "text")) or... (("ACL" ("user=3Dfred" "rwi"))("X-Sample" "text")) See the formal grammar, below, for the full syntatic details. The options defined in this specification are SUBSCRIBED - causes the LIST command to list subscribed mailboxes, rather than the actual mailboxes. This will often be a subset of the actual mailboxes. It's also possible for this list to contain the names of mailboxes that don't exist. In any case, the list MUST include exactly those mailbox names that match the selection criteria and are subscribed to. This option is intended to supplement the LSUB command, and support for it is optional -- a server that supports the SUBSCRIBED option indicates so through the LIST-SUBSCRIBED capability. Of particular note are the mailbox flags as returned by this option, compared with what is returned by LSUB. With the latter, the flags returned may not reflect the actual flag status on the mailbox, and the \NoSelect flag has a special meaning (it indicates that this mailbox is not, itself, subscribed, but that it has child mailboxes that are). With the SUBSCRIBED option described here, the flags are accurate and complete, and have no special meanings. "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, and some servers must do significant extra work to respond to "LIST (SUBSCRIBED)". Because of this, clients SHOULD continue to use "LSUB" unless they specifically want the additional information offered by "LIST (SUBSCRIBED)". At the same time, servers SHOULD support the LIST-SUBSCRIBED capability even if it entails extra work, because a client that wants the information will still obtain it by using LSUB followed by a series of LIST commands, so servers might as well make it easier. This option defines a new mailbox flag, "\NonExistent", that indicates that a mailbox is subscribed to, but does not actually exist. The "\NonExistent" flag MUST be supported and MUST be accurately computed. =0A= B. Leiba Expires January 2004 [Page = 3]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= REMOTE - causes the LIST command to show remote mailboxes as well as local ones, as described in [MboxRefer]. This option is intended to replace the RLIST command and, in conjunction with the SUBSCRIBED option, the RLSUB command. This option is only available on servers that also support RFC-2193. CHILDREN - Requests mailbox child information as originally proposed in [ChildMbox]. See section 5, below, for details. Support for this is optional, but this option MUST be accepted by all servers (though it MAY be ignored). The LISTEXT capability also defines a new mailbox flag, "\PlaceHolder", that indicates that the designated mailbox does not meet the selection criteria of the given LIST command, but that it has one or more child mailboxes that do [EDITORIAL NOTE: "might"?]. The LSUB command indicates this condition by using the "\NoSelect" flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since "\NoSelect" retains its original meaning here. Further, the "\PlaceHolder" flag is more general, in that it can be used with any extended set of selection criteria. =0A= 5. The CHILDREN Option The CHILDREN option implements the Child Mailbox Extension, originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft Corporation. Most of the information in this section is taken directly from their original specification [ChildMbox]. The CHILDREN option is simply an indication that the client wants this information; a server MAY provide it even if the option is not specified, or MAY ignore the option entirely. Many IMAP4 [IMAP4] clients present to the user a hierarchical view of the mailboxes that a user has access to. Rather than initially presenting to the user the entire mailbox hierarchy, it is often preferable to show to the user a collapsed outline list of the mailbox hierarchy (particularly if there is a large number of mailboxes). The user can then expand the collapsed outline hierarchy as needed. It is common to include within the collapsed hierarchy a visual clue (such as a ''+'') to indicate that there are child mailboxes under a particular mailbox. When the visual clue is clicked the hierarchy list is expanded to show the child mailboxes. The Child Mailbox Extension provides a mechanism for a client to efficiently determine if a particular mailbox has children, without issuing a LIST '' * or a LIST '' % for each mailbox name. The Child Mailbox Extension defines two new attributes that MAY be =0A= B. Leiba Expires January 2004 [Page = 4]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= returned within a LIST response: \HasChildren and \HasNoChildren. While these attributes MAY be returned in response to any LIST command, the CHILDREN option is provided to indicate that the client particularly wants this information. If the CHILDREN option is present, the server SHOULD return these attributes even if their computation is expensive. \HasChildren - The presence of this attribute indicates that the mailbox has child mailboxes. A server SHOULD NOT set this attribute if there are child mailboxes, and the user does not have permissions to access any of them. In this case, \HasNoChildren SHOULD be used. In many cases, however, a server may not be able to efficiently compute whether a user has access to all child mailboxes. As such a client MUST be prepared to accept the \HasChildren attribute as a hint. That is, a mailbox MAY be flagged with the \HasChildren attribute, but no child mailboxes will appear in the LIST response. \HasNoChildren - The presence of this attribute indicates that the mailbox has NO child mailboxes that are accessible to the currently authenticated user. In some instances a server that supports the Child Mailbox Extension might not be able to determine whether a mailbox has children. For example it may have difficulty determining whether there are child mailboxes when LISTing mailboxes while operating in a particular namespace. In these cases, a server MAY exclude both the \HasChildren and \HasNoChildren attributes in the LIST response. As such, a client can not make any assumptions about whether a mailbox has children based upon the absence of a single attribute. In particular, some servers may not be able to combine the SUBSCRIBED and CHILDREN options. Such servers MUST honour the SUBSCRIBED option, and they will simply ignore the CHILDREN option if both are requested. It is an error for the server to return both a \HasChildren and a \HasNoChildren attribute in a LIST response. Note: the \HasNoChildren attribute should not be confused with the IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no child mailboxes exist now and none can be created in the future. =0A= 6. Examples =0A= =0A= B. Leiba Expires January 2004 [Page = 5]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= The first example shows the complete local hierarchy that will be used for the other examples. C: A01 LIST "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Apple" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: A01 OK done In the next example, we'll see the subscribed mailboxes. This is similar, but not equivalent, to . Note that the mailbox called "Fruit/Peach" is subscribed to, but does not actually exist (perhaps it was deleted while still subscribed). And the "Fruit" mailbox is not subscribed to, but it has two subscribed children. C: A02 LIST (SUBSCRIBED) "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\PlaceHolder) "/" "Fruit" S: * LIST () "/" "Fruit/Banana" S: * LIST (\NonExistent) "/" "Fruit/Peach" S: A02 OK done The next example shows the use of the CHILDREN option. The client, without having to list the second level of hierarchy, now knows which of the top-level mailboxes have sub-mailboxes (children) and which do not. Note that it's not necessary for the server to return the \HasNoChildren flag for the inbox, because the \NoInferiors flag already implies that, and has a stronger meaning. C: A03 LIST (CHILDREN) "" "%" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\HasChildren) "/" "Fruit" S: * LIST (\HasNoChildren) "/" "Tofu" S: * LIST (\HasChildren) "/" "Vegetable" S: A03 OK done In this example we see more mailboxes, which reside on another server to which we may obtain referrals. This is similar to the command . We also see the mixing of two options. Note that in the case of the remote mailboxes, the server might or might not be able to include CHILDREN information; it includes it if it can, and omits it if it can't. C: A04 LIST (REMOTE CHILDREN) "" "%" S: * LIST (\Marked \NoInferiors) "/" "inbox" =0A= B. Leiba Expires January 2004 [Page = 6]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= S: * LIST (\HasChildren) "/" "Fruit" S: * LIST (\HasNoChildren) "/" "Tofu" S: * LIST (\HasChildren) "/" "Vegetable" S: * LIST () "/" "Bread" S: * LIST (\HasChildren) "/" "Meat" S: A04 OK done =0A= 7. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in [ABNF]. Terms not defined here are taken from [IMAP4]. child-mbox-flag =3D "\HasChildren" / "\HasNoChildren" ; flags for Child Mailbox Extension, at most one ; possible per LIST response list =3D "LIST" [SP list-options] SP mailbox SP = list-mailbox list-options =3D "(" [option *(SP option)] ")" mailbox-list =3D "(" [mbx-list-flags] ")" SP (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox [SP mbox-list-extended] mbox-list-extended =3D "(" [mbox-list-extended-item *(SP mbox-list-extended-item)] ")" mbox-list-extended-item =3D "(" string SP (nstring / mbox-list- extended-item) ")" / mailbox-list-extended mbox-list-oflag :=3D child-mbox-flag / "\NonExistent" / = "\PlaceHolder" option =3D "SUBSCRIBED" / "CHILDREN" / "REMOTE" / option-extension option-extension =3D atom =0A= 8. Security Considerations This document describes syntactic changes to the specification of the IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST command has the same security considerations as those commands. They are described in [IMAP4] and [MboxRefer]. The Child Mailbox Extension provides a client a more efficient means =0A= B. Leiba Expires January 2004 [Page = 7]=0C Internet DRAFT IMAP4 LIST Command Extensions August 2003 =0A= of determining whether a particular mailbox has children. If a mailbox has children, but the currently authenticated user does not have access to any of them, the server SHOULD respond with a \HasNoChildren attribute. In many cases, however, a server may not be able to efficiently compute whether a user has access to all child mailboxes. If such a server responds with a \HasChildren attribute, when in fact the currently authenticated user does not have access to any child mailboxes, potentially more information is conveyed about the mailbox than intended. In most situations this will not be a security concern, because if information regarding whether a mailbox has children is considered sensitive, a user would not be granted access to that mailbox in the first place. =0A= 9. References [IMAP4]; Crispin, M.; "Internet Message Access Protocol - Version 4rev1"; RFC 2060; University of Washington; December 1996. [MboxRefer]; Gahrns, M.; "IMAP4 Mailbox Referrals"; RFC 2193; Microsoft Corporation; September 1997. [ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox Extension"; RFC 3348; Microsoft Corporation; July 2002. [Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate Requirement Levels"; RFC 2119; Harvard University; March 1997. [ABNF]; Crocker, D., and Overell, P. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. =0A= 10. Acknowledgements Mike Gahrns and Raymond Cheng of Microsoft Corporation originally devised the Child Mailbox Extension and proposed it in 1997; the idea, as well as most of the text in section 5, is theirs. =0A= 11. Author's Address Barry Leiba IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10532 Phone: 1-914-784-7941 Email: leiba@watson.ibm.com =0A= =0A= B. Leiba Expires January 2004 [Page 8] ------=_NextPart_000_0044_01C3666A.0A9BB910-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJZ0qt019871 for ; Tue, 19 Aug 2003 12:35:00 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JJZ0mC019870 for ietf-imapext-bks; Tue, 19 Aug 2003 12:35:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJYxqt019861 for ; Tue, 19 Aug 2003 12:34:59 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03693; Tue, 19 Aug 2003 15:34:56 -0400 (EDT) Message-Id: <200308191934.PAA03693@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-acl-09.txt Date: Tue, 19 Aug 2003 15:34:56 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 ACL extension Author(s) : A. Melnikov Filename : draft-ietf-imapext-acl-09.txt Pages : 10 Date : 2003-8-19 The ACL (Access Control List) extension of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-acl-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-acl-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19155045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-acl-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-acl-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19155045.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JBVmqt085991 for ; Tue, 19 Aug 2003 04:31:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JBVmc2085990 for ietf-imapext-bks; Tue, 19 Aug 2003 04:31:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JBVfqt085984 for ; Tue, 19 Aug 2003 04:31:48 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.250]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7JBZUV20655; Tue, 19 Aug 2003 05:35:30 -0600 Message-ID: <3F420A9B.40406@isode.com> Date: Tue, 19 Aug 2003 12:31:39 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Last Calling the LISTEXT draft? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Can we Last Call the LISTEXT document? It is pretty stable for a while now. Except for horrible formatting ;-), I don't have any issues with it. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76FFIqt026626 for ; Wed, 6 Aug 2003 08:15:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h76FFIlB026625 for ietf-imapext-bks; Wed, 6 Aug 2003 08:15:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76FFHqt026615 for ; Wed, 6 Aug 2003 08:15:17 -0700 (PDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id CD32C206606 for ; Wed, 6 Aug 2003 11:13:38 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19kPWq-0004qp-UD for ietf-announce-list@asgard.ietf.org; Wed, 06 Aug 2003 10:44:40 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19kPTG-0004p0-UK for all-ietf@asgard.ietf.org; Wed, 06 Aug 2003 10:40:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18934; Wed, 6 Aug 2003 10:40:50 -0400 (EDT) Message-Id: <200308061440.KAA18934@ietf.org> To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-list-extensions-04.txt Date: Wed, 06 Aug 2003 10:40:50 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+217736_4370862858773_64755974508" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --MIMEStream=_0+217736_4370862858773_64755974508 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 LIST Command Extensions Author(s) : B. Leiba Filename : draft-ietf-imapext-list-extensions-04.txt Pages : 8 Date : 2003-8-6 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-list-extensions-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-list-extensions-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+217736_4370862858773_64755974508 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+56004_97273797717805_2791792793" --MIMEStream=_1+56004_97273797717805_2791792793 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-6095941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-04.txt --MIMEStream=_1+56004_97273797717805_2791792793 Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-6095941.I-D@ietf.org> --MIMEStream=_1+56004_97273797717805_2791792793-- --MIMEStream=_0+217736_4370862858773_64755974508-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76Eevqt021874 for ; Wed, 6 Aug 2003 07:40:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h76EevaL021873 for ietf-imapext-bks; Wed, 6 Aug 2003 07:40:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h76Eeqqt021859 for ; Wed, 6 Aug 2003 07:40:55 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18934; Wed, 6 Aug 2003 10:40:50 -0400 (EDT) Message-Id: <200308061440.KAA18934@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-list-extensions-04.txt Date: Wed, 06 Aug 2003 10:40:50 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 LIST Command Extensions Author(s) : B. Leiba Filename : draft-ietf-imapext-list-extensions-04.txt Pages : 8 Date : 2003-8-6 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-list-extensions-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-list-extensions-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-6095941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-6095941.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75FARqt016245 for ; Tue, 5 Aug 2003 08:10:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75FAR5m016244 for ietf-imapext-bks; Tue, 5 Aug 2003 08:10:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75FAQqt016234 for ; Tue, 5 Aug 2003 08:10:26 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h75FECV30857; Tue, 5 Aug 2003 09:14:12 -0600 Message-ID: <3F2FC8DF.5050007@isode.com> Date: Tue, 05 Aug 2003 16:10:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-03.txt References: <200308051415.KAA12765@ietf.org> In-Reply-To: <200308051415.KAA12765@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. > > Title : IMAP Extension for Conditional STORE operation > Author(s) : A. Melnikov, S. Hole > Filename : draft-ietf-imapext-condstore-03.txt > Pages : 16 > Date : 2003-8-5 > >Often, multiple IMAP clients need to coordinate changes to a common >IMAP mailbox. Examples include different clients for the same user, >and multiple users accessing shared mailboxes. These clients >need a mechanism to synchronize state changes for messages within the >mailbox. They must be able to guarantee that only one client can change >message state (e.g., message flags or annotations) at any time. An >example of such an application is use of an IMAP mailbox as a message >queue with multiple dequeueing clients. >The Conditional Store facility provides a protected update mechanism for >message state information that can detect and resolve conflicts between >multiple writing mail clients. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-03.txt > The goal is to Last Call this document ASAP. Please send your comments. This revision adds a new concept of fetch modifier and describes one of the (CHANGEDSINCE). After discussing this offline with Timo we've agreed that there was no need for a separate extension and that this functionality would be heavily used by the clients. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75EFRqt012860 for ; Tue, 5 Aug 2003 07:15:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75EFRAV012859 for ietf-imapext-bks; Tue, 5 Aug 2003 07:15:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75EFQqt012854 for ; Tue, 5 Aug 2003 07:15:27 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12765; Tue, 5 Aug 2003 10:15:22 -0400 (EDT) Message-Id: <200308051415.KAA12765@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-condstore-03.txt Date: Tue, 05 Aug 2003 10:15:22 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP Extension for Conditional STORE operation Author(s) : A. Melnikov, S. Hole Filename : draft-ietf-imapext-condstore-03.txt Pages : 16 Date : 2003-8-5 Often, multiple IMAP clients need to coordinate changes to a common IMAP mailbox. Examples include different clients for the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-condstore-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-condstore-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-5092212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-condstore-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-condstore-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-5092212.I-D@ietf.org> --OtherAccess-- --NextPart--