Skip to main content

IMAP4 Access Control List (ACL) Extension
RFC 4314

Yes

(Scott Hollenbeck)

No Objection

(Bill Fenner)
(Brian Carpenter)
(David Kessens)
(Mark Townsley)
(Russ Housley)
(Ted Hardie)

Note: This ballot was opened for revision 08 and is now closed.

(Scott Hollenbeck; former steering group member) Yes

Yes ()

                            

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) (was No Record, No Objection) No Objection

No Objection (2005-06-22)
While this entire document concerns access and permissions, it seems to lack any text describing the protocol security requirements of a protocol that sets such permissions. Section 4 details what rights one must possess in order to modify ACLs, but I don't really see any text that describes the related threats concerning impersonation, replays, eavesdropping and so on in ACL creation. I have no doubt that mechanisms to address such threats exist in core IMAP (like SASL and STARTTLS), but it would be nice if this document explained why implementers should bother to use them.

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) (was Discuss) No Objection

No Objection (2005-06-21)
This document says that identifiers used as usernames for the login
and authenticate commands are reserved to correspond to those users.
However the authenticate command doesn't really take a username.  I'm
not sure what the right way of saying this in IMAP is, but in SASL it
would be the authorization identity.  But basically the text should be
clarified to make it consistent with how authenticate actually works.

(Ted Hardie; former steering group member) No Objection

No Objection ()