Subject: Re: Last Calling the LISTEXT draft?
From: Ken Murchison <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Date: Fri, 29 Aug 2003 20:10:15 -0400
List-Id: <ietf-imapext.imc.org>

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

Date: Sat, 30 Aug 2003 02:50:54 +0300
Subject: Re: Last Calling the LISTEXT draft?
Cc: Pete Maclean <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
To: Mark Crispin <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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.

Date: Fri, 29 Aug 2003 10:52:38 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Pete Maclean <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

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.

Date: Fri, 29 Aug 2003 13:44:47 -0400
To: "IMAP extensions Mailing List" <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

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

Date: Sun, 24 Aug 2003 18:39:07 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Designing secure protocols (or: how not to open the barn door)
Sender: [email-masked]

[This thread is getting far afield from imapext's charter. Let's move it
 to the IMAP protocol list. PLEASE remove [email-masked] 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 <[email-masked]> 
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

Date: Sun, 24 Aug 2003 20:36:09 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Timo Sirainen <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Mon, 25 Aug 2003 00:44:24 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Mon, 25 Aug 2003 00:17:49 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: LISTRIGHTS command (was Re: acl-08: questions)
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Mon, 25 Aug 2003 00:14:44 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Mon, 25 Aug 2003 02:05:59 +0300
Subject: Re: acl-08: questions
Cc: Paul Smith <[email-masked]>, [email-masked]
To: Mark Crispin <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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.

Date: Sun, 24 Aug 2003 17:42:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: LISTRIGHTS command (was Re: acl-08: questions)
Sender: [email-masked]

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

Date: Sun, 24 Aug 2003 17:27:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: [email-masked]
Subject: Re: ACL2 negative rights
Sender: [email-masked]

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

Date: Sun, 24 Aug 2003 09:02:39 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Sun, 24 Aug 2003 08:34:48 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Subject: ACL2 negative rights
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: 24 Aug 2003 03:10:01 +0300
Sender: [email-masked]

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

Subject: Re: Maildir ACLs
From: Timo Sirainen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Date: 24 Aug 2003 03:02:20 +0300
Sender: [email-masked]

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.

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Paul Smith <[email-masked]>, [email-masked]
Date: 24 Aug 2003 02:50:13 +0300
Sender: [email-masked]

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.

Date: Sat, 23 Aug 2003 19:43:14 -0400
From: Cyrus Daboo <[email-masked]>
To: Timo Sirainen <[email-masked]>, [email-masked]
Subject: Re: Maildir ACLs
Sender: [email-masked]

Hi Timo,

--On Sunday, August 24, 2003 2:21 +0300 Timo Sirainen <[email-masked]> 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

Date: Sat, 23 Aug 2003 19:35:46 -0400
From: Cyrus Daboo <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Paul,

--On Saturday, August 23, 2003 23:35 +0100 Paul Smith <[email-masked]> 
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

Date: Sun, 24 Aug 2003 02:21:34 +0300
Subject: Maildir ACLs
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Sender: [email-masked]

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?

Date: Sat, 23 Aug 2003 23:28:49 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 23:24:39 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

At 11:06 23/08/2003 -0600, Lyndon Nerenberg wrote:

>On Saturday, August 23, 2003 12:25 AM +0100 Paul Smith <[email-masked]> 
>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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 23:35:54 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 17:26:13 -0400
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg {VE6BBM} <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Lyndon,

--On Saturday, August 23, 2003 10:43 -0600 Lyndon Nerenberg {VE6BBM} 
<[email-masked]> 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

Date: Sat, 23 Aug 2003 21:30:23 +0300
Subject: Re: acl-08: questions
Cc: [email-masked]
To: Paul Smith <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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 :)

Date: Sat, 23 Aug 2003 11:06:09 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

On Saturday, August 23, 2003 12:25 AM +0100 Paul Smith <[email-masked]> 
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

Date: Sat, 23 Aug 2003 12:54:36 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Sat, 23 Aug 2003 10:43:56 -0600
From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

> 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

Date: Sat, 23 Aug 2003 12:05:16 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Rob,

--On Saturday, August 23, 2003 3:06 -0400 Rob Siemborski 
<[email-masked]> 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

Date: Sat, 23 Aug 2003 09:09:54 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 01:15:42 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 03:32:36 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Sat, 23 Aug 2003 03:06:00 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Fri, 22 Aug 2003 18:28:04 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Rob Siemborski <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 21:22:47 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Rob Siemborski <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Mark,

--On Friday, August 22, 2003 5:46 PM -0700 Mark Crispin 
<[email-masked]> 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

Date: Fri, 22 Aug 2003 19:58:26 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Point of order
Sender: [email-masked]

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 <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 22 Aug 2003 17:46:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 20:11:54 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Sat, 23 Aug 2003 00:21:25 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 00:25:34 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

At 11:03 22/08/2003 -0600, you wrote:
>On Friday, August 22, 2003 10:15 AM +0100 Paul Smith <[email-masked]> 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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 23:57:33 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 23:55:21 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 16:44:03 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 16:31:05 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 16:27:20 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 19:11:13 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Fri, 22 Aug 2003 15:53:41 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 23:27:34 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 23:31:56 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 15:39:05 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 18:26:22 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Fri, 22 Aug 2003 18:12:55 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Fri, 22 Aug 2003 11:23:48 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 14:03:19 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Alexey,

--On Friday, August 22, 2003 6:19 PM +0100 Alexey Melnikov 
<[email-masked]> 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

Date: Fri, 22 Aug 2003 10:50:57 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Steve Hole <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 11:49:12 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

> 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

Date: Fri, 22 Aug 2003 13:47:11 -0400
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Lyndon,

--On Friday, August 22, 2003 11:03 AM -0600 Lyndon Nerenberg 
<[email-masked]> 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

Date: Fri, 22 Aug 2003 18:41:32 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Cyrus Daboo wrote:

>
> Hi Mark,
>
> --On Friday, August 22, 2003 9:58 AM -0700 Mark Crispin 
> <[email-masked]> 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

Date: Fri, 22 Aug 2003 10:39:37 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 12:37:19 -0500
To: Alexey Melnikov <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: acl-08: questions
Cc: Mark Crispin <[email-masked]>, Steve Hole <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Sender: [email-masked]

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 <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 22 Aug 2003 18:27:19 +0100
From: Alexey Melnikov <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 20:23:22 +0300
Subject: Re: acl-08: questions
Cc: Paul Smith <[email-masked]>, [email-masked]
To: Lyndon Nerenberg <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 13:22:08 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Mark,

--On Friday, August 22, 2003 9:58 AM -0700 Mark Crispin 
<[email-masked]> 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

Date: Fri, 22 Aug 2003 18:19:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 13:17:25 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 10:12:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Steve Hole <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 10:10:07 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 18:05:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Steve Hole <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 11:03:07 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

On Friday, August 22, 2003 10:15 AM +0100 Paul Smith <[email-masked]> 
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

Date: Fri, 22 Aug 2003 10:59:13 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

On Thursday, August 21, 2003 5:26 PM +0100 Paul Smith <[email-masked]> 
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

Date: Fri, 22 Aug 2003 09:58:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 10:54:41 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

On Friday, August 22, 2003 3:42 PM +0100 Paul Smith <[email-masked]> 
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

Date: Fri, 22 Aug 2003 09:43:13 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 16:07:56 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 09:02:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Steve Hole <[email-masked]>
cc: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 08:56:24 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

From: Steve Hole <[email-masked]>
Date: Fri, 22 Aug 2003 09:51:23 -0700
To: Mark Crispin <[email-masked]>
Subject: Re: acl-08: questions
Cc: Paul Smith <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 22 Aug 2003 05:43:19 -0700 (PDT) Mark Crispin 
<[email-masked]> 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
<mailto:[email-masked]>
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Fri, 22 Aug 2003 09:17:08 -0700
To: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Cc: [email-masked]
Sender: [email-masked]

On Thu, 21 Aug 2003 17:26:57 +0100 Paul Smith <[email-masked]> 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
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Fri, 22 Aug 2003 15:42:18 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 15:57:28 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: 22 Aug 2003 17:57:43 +0300
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 15:28:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 15:23:19 +0100
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 10:16:36 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 10:02:50 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Fri, 22 Aug 2003 08:50:29 -0500
From: "Eric A. Hall" <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: acl2=os-fs
Sender: [email-masked]

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/

Date: Fri, 22 Aug 2003 06:45:59 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 14:42:24 +0100
From: Alexey Melnikov <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked], Cyrus Daboo <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 06:29:21 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 14:15:29 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 13:56:33 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 05:43:19 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 09:50:17 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 10:15:43 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 10:03:23 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

At 13:06 21/08/2003 -0400, you wrote:
>|> It is probably also necessary to say that only one ACL2=<foo> 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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 10:02:22 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Thu, 21 Aug 2003 17:26:57 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Thu, 21 Aug 2003 17:30:36 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Thu, 21 Aug 2003 11:07:34 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Rob Siemborski <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 11:02:39 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 11:00:12 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2=TOPS-20
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 13:31:47 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Date: 21 Aug 2003 20:21:09 +0300
Sender: [email-masked]

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

Date: Thu, 21 Aug 2003 13:17:16 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Thu, 21 Aug 2003 13:11:46 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Thu, 21 Aug 2003 13:06:47 -0400
From: Cyrus Daboo <[email-masked]>
To: Timo Sirainen <[email-masked]>, Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Timo,

--On Thursday, August 21, 2003 7:42 PM +0300 Timo Sirainen <[email-masked]> 
wrote:

|> It is probably also necessary to say that only one ACL2=<foo> 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

Date: Thu, 21 Aug 2003 10:00:46 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 09:54:42 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: [email-masked]
Date: 21 Aug 2003 19:42:06 +0300
Sender: [email-masked]

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

Date: Thu, 21 Aug 2003 09:39:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Larry Greenfield <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 09:34:33 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 17:24:09 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Thu, 21 Aug 2003 11:19:14 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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 <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 21 Aug 2003 11:53:00 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Larry Greenfield <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Thu, 21 Aug 2003 08:50:25 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Rob Siemborski <[email-masked]>, Larry Greenfield <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 08:38:58 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Larry Greenfield <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 11:37:11 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, Larry Greenfield <[email-masked]>
cc: Mark Crispin <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Rob,

--On Thursday, August 21, 2003 10:54 AM -0400 Rob Siemborski 
<[email-masked]> 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

Date: Thu, 21 Aug 2003 10:54:59 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Larry Greenfield <[email-masked]>
cc: Mark Crispin <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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=<foo> 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 * [email-masked] * 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-----

Date: Thu, 21 Aug 2003 10:39:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Philip Guenther wrote:

>Timo Sirainen <[email-masked]> 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

To: Timo Sirainen <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: acl-08: questions 
Date: Wed, 20 Aug 2003 16:21:24 -0700
Sender: [email-masked]

Timo Sirainen <[email-masked]> 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
[email-masked]

Date: Wed, 20 Aug 2003 16:16:02 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked]
Date: 21 Aug 2003 01:44:26 +0300
Sender: [email-masked]

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?

Date: Wed, 20 Aug 2003 15:17:30 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Larry Greenfield <[email-masked]>
cc: Rob Siemborski <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 17:59:29 -0400
From: Larry Greenfield <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 14:54:52 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg {VE6BBM} <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 14:49:18 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Lyndon Nerenberg {VE6BBM} <[email-masked]>, Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 15:44:31 -0600
Subject: Re: acl-08: questions
Cc: [email-masked]
To: Mark Crispin <[email-masked]>
From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 17:28:37 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lyndon Nerenberg {VE6BBM} <[email-masked]>, Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Wed, 20 Aug 2003 14:23:19 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg {VE6BBM} <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 15:18:43 -0600
Subject: Re: acl-08: questions
Cc: [email-masked]
To: Mark Crispin <[email-masked]>
From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
Sender: [email-masked]

> What TCP/IP-specific network support is there in IMAP?

Please examine tcp_unix.c in the c-client source code.

--lyndon

Date: Wed, 20 Aug 2003 14:07:40 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg {VE6BBM} <[email-masked]>
cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 14:51:09 -0600
Subject: Re: acl-08: questions
Cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
To: Mark Crispin <[email-masked]>
From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
Sender: [email-masked]

> 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

Date: Wed, 20 Aug 2003 13:15:00 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg {VE6BBM} <[email-masked]>
cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 14:02:50 -0600
Subject: Re: acl-08: questions
Cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
To: Mark Crispin <[email-masked]>
From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
Sender: [email-masked]

> 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

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Date: 20 Aug 2003 22:07:41 +0300
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 11:58:48 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 11:52:35 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 21:33:41 +0300
Subject: Re: acl-08: questions
Cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
To: Mark Crispin <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 20:57:12 +0300
Subject: Re: Last Calling the LISTEXT draft?
Cc: Alexey Melnikov <[email-masked]>, Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
To: Mark Crispin <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 10:31:08 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Larry Greenfield <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 10:20:54 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Larry Greenfield <[email-masked]>
cc: Steve Hole <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 17:55:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Larry Greenfield <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 12:38:13 -0400
From: Larry Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 12:33:43 -0400
From: Larry Greenfield <[email-masked]>
To: Steve Hole <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 17:31:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 09:10:22 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

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

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.

From: Steve Hole <[email-masked]>
Date: Wed, 20 Aug 2003 08:58:28 -0700
To: Alexey Melnikov <[email-masked]>
Subject: Re: acl-08: questions
Cc: Lawrence Greenfield <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, 20 Aug 2003 11:58:59 +0100 Alexey Melnikov 
<[email-masked]> 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
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Wed, 20 Aug 2003 12:16:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 11:58:59 +0100
From: Alexey Melnikov <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

[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 "}<CR><LF>" 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

Date: Tue, 19 Aug 2003 19:11:22 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-09.txt
Date: Tue, 19 Aug 2003 15:34:56 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--MIMEStream=_1+173044_765583334319_329585914397--
--MIMEStream=_0+76459_15913104021353_48263776221--

From: "Barry Leiba" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Date: Tue, 19 Aug 2003 15:53:32 -0400
Sender: [email-masked]

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  ([email-masked])
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 [email-masked].  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 <LSUB "" "*">.  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
   <RLIST "" "%">.  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: [email-masked]

=0A=

=0A=
B. Leiba                  Expires January 2004                  [Page 8]
------=_NextPart_000_0044_01C3666A.0A9BB910--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-09.txt
Date: Tue, 19 Aug 2003 15:34:56 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 19 Aug 2003 12:31:39 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Last Calling the LISTEXT draft?
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-04.txt
Date: Wed, 06 Aug 2003 10:40:50 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--MIMEStream=_1+56004_97273797717805_2791792793--
--MIMEStream=_0+217736_4370862858773_64755974508--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-04.txt
Date: Wed, 06 Aug 2003 10:40:50 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 05 Aug 2003 16:10:23 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-03.txt
Sender: [email-masked]

[email-masked] 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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-03.txt
Date: Tue, 05 Aug 2003 10:15:22 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 29 Aug 2003 20:10:15 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

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

Date: Sat, 30 Aug 2003 02:50:54 +0300
Subject: Re: Last Calling the LISTEXT draft?
Cc: Pete Maclean <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
To: Mark Crispin <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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.

Date: Fri, 29 Aug 2003 10:52:38 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Pete Maclean <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

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.

Date: Fri, 29 Aug 2003 13:44:47 -0400
To: "IMAP extensions Mailing List" <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

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

Date: Sun, 24 Aug 2003 18:39:07 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Designing secure protocols (or: how not to open the barn door)
Sender: [email-masked]

[This thread is getting far afield from imapext's charter. Let's move it
 to the IMAP protocol list. PLEASE remove [email-masked] 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 <[email-masked]> 
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

Date: Sun, 24 Aug 2003 20:36:09 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Timo Sirainen <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Mon, 25 Aug 2003 00:44:24 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Mon, 25 Aug 2003 00:17:49 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: LISTRIGHTS command (was Re: acl-08: questions)
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Mon, 25 Aug 2003 00:14:44 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Mon, 25 Aug 2003 02:05:59 +0300
Subject: Re: acl-08: questions
Cc: Paul Smith <[email-masked]>, [email-masked]
To: Mark Crispin <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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.

Date: Sun, 24 Aug 2003 17:42:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: LISTRIGHTS command (was Re: acl-08: questions)
Sender: [email-masked]

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

Date: Sun, 24 Aug 2003 17:27:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: [email-masked]
Subject: Re: ACL2 negative rights
Sender: [email-masked]

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

Date: Sun, 24 Aug 2003 09:02:39 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Sun, 24 Aug 2003 08:34:48 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Subject: ACL2 negative rights
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: 24 Aug 2003 03:10:01 +0300
Sender: [email-masked]

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

Subject: Re: Maildir ACLs
From: Timo Sirainen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Date: 24 Aug 2003 03:02:20 +0300
Sender: [email-masked]

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.

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Paul Smith <[email-masked]>, [email-masked]
Date: 24 Aug 2003 02:50:13 +0300
Sender: [email-masked]

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.

Date: Sat, 23 Aug 2003 19:43:14 -0400
From: Cyrus Daboo <[email-masked]>
To: Timo Sirainen <[email-masked]>, [email-masked]
Subject: Re: Maildir ACLs
Sender: [email-masked]

Hi Timo,

--On Sunday, August 24, 2003 2:21 +0300 Timo Sirainen <[email-masked]> 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

Date: Sat, 23 Aug 2003 19:35:46 -0400
From: Cyrus Daboo <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Paul,

--On Saturday, August 23, 2003 23:35 +0100 Paul Smith <[email-masked]> 
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

Date: Sun, 24 Aug 2003 02:21:34 +0300
Subject: Maildir ACLs
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Sender: [email-masked]

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?

Date: Sat, 23 Aug 2003 23:28:49 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 23:24:39 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

At 11:06 23/08/2003 -0600, Lyndon Nerenberg wrote:

>On Saturday, August 23, 2003 12:25 AM +0100 Paul Smith <[email-masked]> 
>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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 23:35:54 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 17:26:13 -0400
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg {VE6BBM} <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Lyndon,

--On Saturday, August 23, 2003 10:43 -0600 Lyndon Nerenberg {VE6BBM} 
<[email-masked]> 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

Date: Sat, 23 Aug 2003 21:30:23 +0300
Subject: Re: acl-08: questions
Cc: [email-masked]
To: Paul Smith <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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 :)

Date: Sat, 23 Aug 2003 11:06:09 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

On Saturday, August 23, 2003 12:25 AM +0100 Paul Smith <[email-masked]> 
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

Date: Sat, 23 Aug 2003 12:54:36 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Sat, 23 Aug 2003 10:43:56 -0600
From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

> 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

Date: Sat, 23 Aug 2003 12:05:16 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Rob,

--On Saturday, August 23, 2003 3:06 -0400 Rob Siemborski 
<[email-masked]> 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

Date: Sat, 23 Aug 2003 09:09:54 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 01:15:42 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 03:32:36 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Sat, 23 Aug 2003 03:06:00 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Fri, 22 Aug 2003 18:28:04 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Rob Siemborski <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 21:22:47 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Rob Siemborski <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Mark,

--On Friday, August 22, 2003 5:46 PM -0700 Mark Crispin 
<[email-masked]> 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

Date: Fri, 22 Aug 2003 19:58:26 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Point of order
Sender: [email-masked]

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 <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 22 Aug 2003 17:46:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 20:11:54 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Sat, 23 Aug 2003 00:21:25 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Sat, 23 Aug 2003 00:25:34 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

At 11:03 22/08/2003 -0600, you wrote:
>On Friday, August 22, 2003 10:15 AM +0100 Paul Smith <[email-masked]> 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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 23:57:33 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 23:55:21 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 16:44:03 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 16:31:05 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 16:27:20 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 19:11:13 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Fri, 22 Aug 2003 15:53:41 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 23:27:34 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 23:31:56 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 15:39:05 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 18:26:22 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Fri, 22 Aug 2003 18:12:55 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Fri, 22 Aug 2003 11:23:48 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 14:03:19 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Alexey,

--On Friday, August 22, 2003 6:19 PM +0100 Alexey Melnikov 
<[email-masked]> 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

Date: Fri, 22 Aug 2003 10:50:57 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Steve Hole <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 11:49:12 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

> 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

Date: Fri, 22 Aug 2003 13:47:11 -0400
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Lyndon,

--On Friday, August 22, 2003 11:03 AM -0600 Lyndon Nerenberg 
<[email-masked]> 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

Date: Fri, 22 Aug 2003 18:41:32 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Cyrus Daboo wrote:

>
> Hi Mark,
>
> --On Friday, August 22, 2003 9:58 AM -0700 Mark Crispin 
> <[email-masked]> 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

Date: Fri, 22 Aug 2003 10:39:37 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 12:37:19 -0500
To: Alexey Melnikov <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: acl-08: questions
Cc: Mark Crispin <[email-masked]>, Steve Hole <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Sender: [email-masked]

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 <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 22 Aug 2003 18:27:19 +0100
From: Alexey Melnikov <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 20:23:22 +0300
Subject: Re: acl-08: questions
Cc: Paul Smith <[email-masked]>, [email-masked]
To: Lyndon Nerenberg <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 13:22:08 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Mark,

--On Friday, August 22, 2003 9:58 AM -0700 Mark Crispin 
<[email-masked]> 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

Date: Fri, 22 Aug 2003 18:19:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 13:17:25 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 10:12:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Steve Hole <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 10:10:07 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 18:05:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Steve Hole <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 11:03:07 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

On Friday, August 22, 2003 10:15 AM +0100 Paul Smith <[email-masked]> 
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

Date: Fri, 22 Aug 2003 10:59:13 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

On Thursday, August 21, 2003 5:26 PM +0100 Paul Smith <[email-masked]> 
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

Date: Fri, 22 Aug 2003 09:58:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 10:54:41 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

On Friday, August 22, 2003 3:42 PM +0100 Paul Smith <[email-masked]> 
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

Date: Fri, 22 Aug 2003 09:43:13 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 16:07:56 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 09:02:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Steve Hole <[email-masked]>
cc: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 08:56:24 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

From: Steve Hole <[email-masked]>
Date: Fri, 22 Aug 2003 09:51:23 -0700
To: Mark Crispin <[email-masked]>
Subject: Re: acl-08: questions
Cc: Paul Smith <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 22 Aug 2003 05:43:19 -0700 (PDT) Mark Crispin 
<[email-masked]> 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
<mailto:[email-masked]>
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Fri, 22 Aug 2003 09:17:08 -0700
To: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Cc: [email-masked]
Sender: [email-masked]

On Thu, 21 Aug 2003 17:26:57 +0100 Paul Smith <[email-masked]> 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
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Fri, 22 Aug 2003 15:42:18 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 15:57:28 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: 22 Aug 2003 17:57:43 +0300
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 15:28:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 15:23:19 +0100
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 10:16:36 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 10:02:50 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Fri, 22 Aug 2003 08:50:29 -0500
From: "Eric A. Hall" <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: acl2=os-fs
Sender: [email-masked]

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/

Date: Fri, 22 Aug 2003 06:45:59 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 14:42:24 +0100
From: Alexey Melnikov <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked], Cyrus Daboo <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 06:29:21 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 14:15:29 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 13:56:33 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 05:43:19 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Fri, 22 Aug 2003 09:50:17 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 10:15:43 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 10:03:23 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

At 13:06 21/08/2003 -0400, you wrote:
>|> It is probably also necessary to say that only one ACL2=<foo> 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
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 22 Aug 2003 10:02:22 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Thu, 21 Aug 2003 17:26:57 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Thu, 21 Aug 2003 17:30:36 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Thu, 21 Aug 2003 11:07:34 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Rob Siemborski <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 11:02:39 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 11:00:12 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2=TOPS-20
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 13:31:47 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Date: 21 Aug 2003 20:21:09 +0300
Sender: [email-masked]

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

Date: Thu, 21 Aug 2003 13:17:16 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Thu, 21 Aug 2003 13:11:46 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Thu, 21 Aug 2003 13:06:47 -0400
From: Cyrus Daboo <[email-masked]>
To: Timo Sirainen <[email-masked]>, Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Timo,

--On Thursday, August 21, 2003 7:42 PM +0300 Timo Sirainen <[email-masked]> 
wrote:

|> It is probably also necessary to say that only one ACL2=<foo> 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

Date: Thu, 21 Aug 2003 10:00:46 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 09:54:42 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: [email-masked]
Date: 21 Aug 2003 19:42:06 +0300
Sender: [email-masked]

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

Date: Thu, 21 Aug 2003 09:39:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Larry Greenfield <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 09:34:33 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 17:24:09 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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
[email-masked]			http://www.pscs.co.uk/

Date: Thu, 21 Aug 2003 11:19:14 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

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 <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 21 Aug 2003 11:53:00 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Larry Greenfield <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Thu, 21 Aug 2003 08:50:25 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Rob Siemborski <[email-masked]>, Larry Greenfield <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 08:38:58 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Larry Greenfield <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Thu, 21 Aug 2003 11:37:11 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, Larry Greenfield <[email-masked]>
cc: Mark Crispin <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Hi Rob,

--On Thursday, August 21, 2003 10:54 AM -0400 Rob Siemborski 
<[email-masked]> 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

Date: Thu, 21 Aug 2003 10:54:59 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Larry Greenfield <[email-masked]>
cc: Mark Crispin <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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=<foo> 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 * [email-masked] * 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-----

Date: Thu, 21 Aug 2003 10:39:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

Philip Guenther wrote:

>Timo Sirainen <[email-masked]> 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

To: Timo Sirainen <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: acl-08: questions 
Date: Wed, 20 Aug 2003 16:21:24 -0700
Sender: [email-masked]

Timo Sirainen <[email-masked]> 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
[email-masked]

Date: Wed, 20 Aug 2003 16:16:02 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked]
Date: 21 Aug 2003 01:44:26 +0300
Sender: [email-masked]

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?

Date: Wed, 20 Aug 2003 15:17:30 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Larry Greenfield <[email-masked]>
cc: Rob Siemborski <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 17:59:29 -0400
From: Larry Greenfield <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Lyndon Nerenberg {VE6BBM} <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 14:54:52 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg {VE6BBM} <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 14:49:18 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Lyndon Nerenberg {VE6BBM} <[email-masked]>, Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 15:44:31 -0600
Subject: Re: acl-08: questions
Cc: [email-masked]
To: Mark Crispin <[email-masked]>
From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 17:28:37 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lyndon Nerenberg {VE6BBM} <[email-masked]>, Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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 * [email-masked] * 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-----

Date: Wed, 20 Aug 2003 14:23:19 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg {VE6BBM} <[email-masked]>
cc: [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 15:18:43 -0600
Subject: Re: acl-08: questions
Cc: [email-masked]
To: Mark Crispin <[email-masked]>
From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
Sender: [email-masked]

> What TCP/IP-specific network support is there in IMAP?

Please examine tcp_unix.c in the c-client source code.

--lyndon

Date: Wed, 20 Aug 2003 14:07:40 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg {VE6BBM} <[email-masked]>
cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 14:51:09 -0600
Subject: Re: acl-08: questions
Cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
To: Mark Crispin <[email-masked]>
From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
Sender: [email-masked]

> 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

Date: Wed, 20 Aug 2003 13:15:00 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg {VE6BBM} <[email-masked]>
cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 14:02:50 -0600
Subject: Re: acl-08: questions
Cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
To: Mark Crispin <[email-masked]>
From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
Sender: [email-masked]

> 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

Subject: Re: acl-08: questions
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Date: 20 Aug 2003 22:07:41 +0300
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 11:58:48 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 11:52:35 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 21:33:41 +0300
Subject: Re: acl-08: questions
Cc: Larry Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
To: Mark Crispin <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 20:57:12 +0300
Subject: Re: Last Calling the LISTEXT draft?
Cc: Alexey Melnikov <[email-masked]>, Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
To: Mark Crispin <[email-masked]>
From: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 10:31:08 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Larry Greenfield <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 10:20:54 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Larry Greenfield <[email-masked]>
cc: Steve Hole <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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.

Date: Wed, 20 Aug 2003 17:55:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Larry Greenfield <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 12:38:13 -0400
From: Larry Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 12:33:43 -0400
From: Larry Greenfield <[email-masked]>
To: Steve Hole <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 17:31:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 09:10:22 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

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

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.

From: Steve Hole <[email-masked]>
Date: Wed, 20 Aug 2003 08:58:28 -0700
To: Alexey Melnikov <[email-masked]>
Subject: Re: acl-08: questions
Cc: Lawrence Greenfield <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, 20 Aug 2003 11:58:59 +0100 Alexey Melnikov 
<[email-masked]> 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
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Wed, 20 Aug 2003 12:16:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

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

Date: Wed, 20 Aug 2003 11:58:59 +0100
From: Alexey Melnikov <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
CC: [email-masked]
Subject: Re: acl-08: questions
Sender: [email-masked]

[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 "}<CR><LF>" 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

Date: Tue, 19 Aug 2003 19:11:22 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-09.txt
Date: Tue, 19 Aug 2003 15:34:56 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--MIMEStream=_1+173044_765583334319_329585914397--
--MIMEStream=_0+76459_15913104021353_48263776221--

From: "Barry Leiba" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Date: Tue, 19 Aug 2003 15:53:32 -0400
Sender: [email-masked]

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  ([email-masked])
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 [email-masked].  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 <LSUB "" "*">.  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
   <RLIST "" "%">.  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: [email-masked]

=0A=

=0A=
B. Leiba                  Expires January 2004                  [Page 8]
------=_NextPart_000_0044_01C3666A.0A9BB910--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-09.txt
Date: Tue, 19 Aug 2003 15:34:56 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 19 Aug 2003 12:31:39 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Last Calling the LISTEXT draft?
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-04.txt
Date: Wed, 06 Aug 2003 10:40:50 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--MIMEStream=_1+56004_97273797717805_2791792793--
--MIMEStream=_0+217736_4370862858773_64755974508--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-04.txt
Date: Wed, 06 Aug 2003 10:40:50 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 05 Aug 2003 16:10:23 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-03.txt
Sender: [email-masked]

[email-masked] 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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-03.txt
Date: Tue, 05 Aug 2003 10:15:22 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--