Network Working Group J. G. Myers Internet Draft: IMSP Carnegie Mellon Document: internet-drafts/draft-myers-imap-imsp-00.txt March 1994 IMSP -- Internet Message Support Protocol Status of this memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress``. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. This document suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this draft is unlimited. This document will expire before September 25, 1994. The protocol discussed in this document is experimental and subject to change. Persons planning on either implementing or using this protocol are STRONGLY URGED to get in touch with the author before embarking on such a project. Introduction The Internet Message Support Protocol (IMSP) is designed to support the provision of mail in a medium to large scale operation. It is intended to be used as a companion to the IMAP4 protocol [IMAP4], providing services which are either outside the scope of mail access or which pertain to environments which must run more than one IMAP4 server in the same mail domain. Myers [Page 1] Internet DRAFT IMSP March 1994 The protocol The IMSP protocol consists of a sequence of client commands and server responses, with server data interspersed between the responses. To simplify the implementation of clients, the IMSP protocol has a command structure similar to the IMAP protocol. Many of the IMSP commands and responses have the same or similar syntax and semantics of their IMAP4 counterparts. Like the IMAP4 protocol, commands and responses are tagged. That is, a command begins with a unique identifier (typically a short alphanumeric sequence such as a Lisp "gensym" function would generate e.g., A0001, A0002, etc.), called a tag. The response to this command is given the same tag from the server. Additionally, the server may send an arbitrary amount of "untagged data", which is identified by the special reserved tag of "*". There is another special reserved tag, "+", discussed below. The server must be listening for a connection on TCP port 406. When a connection is opened the server sends an untagged OK or PREAUTH response as a greeting message and then waits for commands. The client opens a connection and waits for the greeting. The client must not send any commands until it has received the greeting from the server. Once the greeting has been received, the client may begin sending commands and is not under any obligation to wait for a server response to this command before sending another command, within the constraints of TCP flow control. When commands are received the server acts on them and responds with command responses, often interspersed with data. The effect of a command can not be considered complete until a command response with a tag matching the command is received from the server. Although all known IMSP servers at the time of this writing process commands to completion before processing the next command, it is not required that a server do so. However, many commands can affect the results of other commands, creating processing-order dependencies (or, for LIST and GETACL, ambiguities about which data is associated with which command). All implementations that operate in a non- lockstep fashion must recognize such dependencies and defer or synchronize execution as necessary. Generally, the first command from the client is a LOGIN command with user name and password arguments to establish identity and access authorization, unless this has already been accomplished through other means, e.g. connecting via the BSD "RSH" protocol. Until identity and access authorization have been established, no Myers [Page 2] Internet DRAFT IMSP March 1994 operations other than LOGIN or LOGOUT are permitted. The client terminates the session with the LOGOUT command. The server returns a "BYE" followed by an "OK". A Typical Scenario Client Server ------ ------ {Wait for Connection} {Open Connection} --> <-- * OK IMSP Server Ready {Wait for command} A001 LOGIN Fred Secret --> <-- A001 OK User Fred logged in {Wait for command} A002 LIST "" INBOX --> <-- * LIST () (imap3.do.main) NIL INBOX <-- A0002 OK List complete {Wait for command} A003 SUBSCRIBE comp.mail.mime --> <-- A003 OK Subscribe complete {Wait for command} A004 LOGOUT --> <-- * BYE IMSP server quitting <-- A004 OK Logout complete {Close Connection} --><-- {Close connection} {Go back to start} Responses The first group of responses complete a request, and indicate whether the command was successful. The response text is a line of human readable text, optionally prefixed by an atom inside square brackets that conveys a special information token between cooperating servers and clients. The currently defined special information tokens are: LOCKED The option or address book entry is already locked by another client. hex string A hexadecimal string is returned as a special information token to represent a Kerberos return authenticator. This only occurs in response to a LOGIN command that uses Kerberos authentication. Other special information tokens defined by particular client or Myers [Page 3] Internet DRAFT IMSP March 1994 server implementations should be prefixed with an "X" until they are added to a revision of this protocol. tag OK response_text This response identifies successful completion of the command with that tag. The response text may be useful in a protocol telemetry log for debugging purposes. tag NO response_text This response identifies unsuccessful completion of the command with that tag. The text is a line of human-readable text that probably should be displayed to the user in an error report by the client. tag BAD response_text This response identifies faulty protocol received from the client; The text is a line of human-readable text that should be recorded in any telemetry as part of a bug report to the maintainer of the client. The second group of responses convey human-readable information. The response text is a line of human readable text, optionally prefixed by an atom inside square brackets that conveys special information between cooperating servers and clients. * PREAUTH response_text This response is one of three possible greetings at session startup. It indicates that the session has already been authenticated by external means and thus no LOGIN command is needed. * OK response_text This response identifies an information message from the server. It does not indicate completion of any particular request, nor is it necessarily related to any request. The text is a line of human-readable text that should be presented to the user as an information message. Myers [Page 4] Internet DRAFT IMSP March 1994 This response is also one of three possible greetings at session startup. It indicates that the session is not yet authenticated and that a LOGIN command is needed. * NO response_text This response identifies a warning message from the server. does not indicate completion of any request, nor is it necessarily related to any request. The text is a line of human-readable text that should be presented to the user as a warning of improper operation. * BAD response_text This response identifies a serious error message from the server. It does not indicate completion of any request, nor is it necessarily related to any request. It may also indicate a faulty command from the client in which a tag could not be parsed. The text is a line of human-readable text that should be presented to the user as a serious or possibly fatal error. * BYE text This response identifies that the server is about to close the connection. The text is a line of human-readable text that should be displayed to the user in a status report by the client. This may be sent as part of a normal logout sequence, or as a panic shutdown announcement by the server. It is also used by some servers as an announcement of an inactivity autologout. This response is also one of three possible greetings at session startup. It indicates that the server is not willing to accept a session from this client. The third group of responses convey data about the objects being manipulated. They are described in later sections of this document. The final group of responses contains a single, special purpose response. + response_text This response identifies that the server is ready to accept the text of a literal from the client. The text of this response is a line of human-readable text of the server's choosing (it is Myers [Page 5] Internet DRAFT IMSP March 1994 generally never seen by a client's human user). The purpose of this command is to solve a synchronization problem that can occur if a string in a command is a literal. Normally, a command from the client is a single text line. If the server detects an error in the command, it can simply discard the remainder of the line. It cannot do this for commands that contain literals, since a literal can be an arbitrarily long amount of text, and the server may not even be expecting a literal. This mechanism is provided so the client knows not to send a literal until the server expects it, preserving client/server synchronization. No such synchronization protection is provided for literals sent from the server to the client. Any synchronization problems in this direction would be caused by a bug in the client or server. Base functionality Commands tag NOOP The NOOP command returns an OK to the client. By itself, it does nothing, but certain things may happen as side effects. Identification and Authorization Commands tag LOGIN user password The LOGIN command identifies the user to the server and carries the password authenticating this user. This information is used by the server to control access to commands. EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH with password SESAME. tag LOGOUT The LOGOUT command informs the server that the client is done with the session. The server will send an untagged BYE response before the (tagged) OK response, and then close the network connection. Myers [Page 6] Internet DRAFT IMSP March 1994 Responses * PREAUTH A pre-authenticated IMSP server should recognize that authentication has already happened, and enter the post-login state. In its greeting message, it should use the untagged reply "PREAUTH" instead of "OK" to indicate that external authentication has taken place. Server location and new message information Commands tag LIST reference mailbox The LIST command accepts as arguments a reference name followed by a mailbox name, including possible wildcards, that specifies some subset of names from the complete set of all names available to the user. Zero or more unsolicted LIST replies are returned. The exact meaning of "names available to the user" is implementation-dependent, since the concept of a bounded or deterministic set of "mailboxes available to the user" may not be meaningful for a particular server or server implementation. EXAMPLE: C: A002 LIST "~/Mail/" "%" S: * LIST (\Noselect) (imap1.do.main) "/" ~/Mail/foo S: * LIST () (imap1.do.main) "/" ~/Mail/meetings S: A002 OK LIST completed tag LSUB reference mailbox The LSUB command accepts as arguments a reference name followed by a mailbox name, including possible wildcards, that specifies some subset of names from the set of names that the user has declared as being "active" or "subscribed". Zero or more untagged LSUB replies are returned. EXAMPLE: C: A002 LSUB "#news." "comp.mail.*" S: * LSUB () (imap5.do.main) "." #news.comp.mail.mime S: * LSUB () (imap7.do.main) "." #news.comp.mail.misc S: A002 OK LSUB completed indicates that the user is subscribed to the two news groups listed, and to no other news groups with names beginning with "comp.mail.". Myers [Page 7] Internet DRAFT IMSP March 1994 tag UNSEEN reference mailbox The UNSEEN command accepts as arguments a reference name followed by a mailbox name, including possible wildcards, that specifies some subset of names from the set of names that the user has declared as being "active" or "subscribed" and which contains at least one message without the \Seen flag set. Zero or more untagged UNSEEN replies are returned. Should an implementation be unable to determine which mailboxes have unread messages, it should return the same set of mailboxes returned by LSUB. tag ADDRESSBOOK pattern The ADDRESSBOOK command accepts as an argument a pattern that specifies some subset of names from the complete set of all address book names available to the user. Zero or more unsolicted ADDRESSBOOK replies are returned. The exact meaning of "names available to the user" is implementation-dependent, since the concept of a bounded or deterministic set of "address books available to the user" may not be meaningful for a particular server or server implementation. EXAMPLE: A002 ADDRESSBOOK * * ADDRESSBOOK () "." Fred * ADDRESSBOOK () "." Fred.public A002 OK Addressbook completed Responses * LIST mstring This response occurs as a result of a LIST command. The mstring contains information about a name which matches the pattern in the command. EXAMPLE: C: A002 LIST "~/Mail/" "%" S: * LIST (\Noselect) (imap1.do.main) "/" ~/Mail/foo S: * LIST () "/" (imap1.do.main) ~/Mail/meetings S: A002 OK LIST completed * LSUB mstring Myers [Page 8] Internet DRAFT IMSP March 1994 This response occurs as a result of a LSUB command. The mstring contains information about a name which matches the pattern in the command. EXAMPLE: C: A002 LSUB "#news." "comp.mail.*" S: * LSUB () (imap5.do.main) "." #news.comp.mail.mime S: * LSUB () (imap7.do.main) "." #news.comp.mail.misc S: A002 OK LSUB completed * UNSEEN mstring This response occurs as a result of an UNSEEN command. The mstring contains information about a name which matches the pattern in the command. EXAMPLE: C: A002 LSUB "#news." "comp.mail.*" S: * LSUB () (imap5.do.main) "." #news.comp.mail.mime S: * LSUB () (imap7.do.main) "." #news.comp.mail.misc S: A002 OK LSUB completed [define the mailbox attributes somewhere] [put this somewhere relevant] Should the server_list contain more than one host name, the client should access the mailbox by attempting to connect to each server until one connection succeeds. The client should attempt each possible host in the sequence listed unless it has good reason to do otherwise (such as an already-open connection or geographic information). * ADDRESSBOOK attributes separator text_line [clean up grammar. abstring?] This response occurs as a result of an ADDRESSBOOK command. The string is an address book name that matches the pattern in the command. attributes is an S-expression list of addressbook attributes. There are no defined addressbook attributes. An IMSP client must be able to accept attributes it does not understand. Discussion When a user asks a client to read a mailbox by name, the client should issue a "LIST" command to the IMSP server in order to Myers [Page 9] Internet DRAFT IMSP March 1994 determine which server it is on. The following is a possible implementation of the UNSEEN command: When a message is appended to a mailbox, the IMAP server notifies the IMSP server of the message's UID. This could be done using an IMSP extension: tag LAST mailbox uid When a user has seen all messages in a mailbox and then switches mailboxes or closes a connection, the IMAP server notifies the IMSP server of the UID of the last message the user has read. This too could be done using an IMSP extension: tag SEEN mailbox uid user When asked for mailboxes with messages unseen by the user, the IMSP server can check the attribute of the message last reported for the user against the attribute of the message last appended to the mailbox. Subscription management tag SUBSCRIBE mailbox The SUBSCRIBE command adds the specified mailbox name to the list of "active" or "subscribed" mailboxes as returned by the LSUB command. This command returns an OK response only if the subscription is successful. Subscriptions should be preserved between sessions. tag UNSUBSCRIBE mailbox The UNSUBSCRIBE command removes the specified mailbox name from the list of "active" or "subscribed" mailboxes as returned by the LSUB command. This command returns an OK response only if the unsubscription is successful. Unsubscriptions should be preserved between sessions. Myers [Page 10] Internet DRAFT IMSP March 1994 Mailbox management tag CREATE mailbox tag CREATE mailbox server_partition_list The CREATE command creates a mailbox with the given name. This command returns an OK response only if a new mailbox with that name has been created. It is an error to attempt to create a mailbox with a name that refers to an extant mailbox. Any error in creation will return a NO response. Creating INBOX is not permitted. If there is a primary or default mailbox for this user, it MUST exist and be called INBOX; hence it may not be created. If server_partition_list is specified, it indicates the server or set of servers on which the mailbox is to be created. Each hostname in the list may be followed by a slash character and an atom. The atom specifies in an implementation-dependent manner where to store the mailbox on the server. EXAMPLE: A002 CREATE FOOBAR (imap2.do.main/a imap4.do.main) A002 OK Create completed If server_partition_list is not specified, the placement of the mailbox is up to the implementation. tag DELETE mailbox tag DELETE mailbox hostname The DELETE command deletes a mailbox with the given name. This command returns an OK response only if a mailbox with that name has been deleted. It is an error to attempt to delete a mailbox name that does not exist. Any error in deletion will return a NO response. A server SHOULD NOT attempt to test that a mailbox is empty prior to permitting deletion; this would prevent the deletion of a mailbox which for some reason can not be opened or expunged, leaving to possible denial of service problems. Any such checking should be left to the discretion of the client. Deleting INBOX is not permitted. If hostname is specified, the mailbox is deleted on that host. If it is not specified, the mailbox is deleted on all hosts on which the mailbox resides. Myers [Page 11] Internet DRAFT IMSP March 1994 tag RENAME oldmailbox newmailbox The RENAME command changes the name of a mailbox. This command returns an OK response only if a mailbox with the old name exists and has been successfully renamed to the new name. It is an error to attempt to rename with an old mailbox name that does not exist or a new mailbox name which already exists. Any error in renaming will return a NO response. Should any users be subscribed to "oldmailbox", they will subsequently be subscribed to "newmailbox". Renaming INBOX is permitted. A new, empty INBOX is created in its place. Should users be subscribed to the INBOX, they will remain subscribed to the new, empty INBOX as well as being subscribed to "newmailbox". tag REPLACE oldmailbox newmailbox The REPLACE command deletes a mailbox, automatically changing subscriptions to a new mailbox. This command returns an OK response only if a mailbox with the old name exists, a mailbox with the new name exists, and if the mailbox with the old name has successfully been deleted. It is an error to attempt to delete a mailbox name or change subscriptions to a mailbox name that does not exist. Any error in deletion will return a NO response. Should any users be subscribed to "oldmailbox", they will subsequently be subscribed to "newmailbox". Replacing INBOX is not permitted. tag MOVE mailbox hostname server_partition_list The MOVE command moves a mailbox between servers and/or replicates a mailbox. Hostname specifies where the move is to be made from and server_partition_list specifies where the move is to be made to. The interpretation of server_partition_list is the same as for the CREATE command. Discussion Of course, local administrative policy may restrict use of these commands. Implementations may use this as justification for not implementing partitions, multiple locations for mailboxes, or the Myers [Page 12] Internet DRAFT IMSP March 1994 MOVE command. MOVE cannot be implemented without some non-IMAP4 communication with the IMAP servers. Replication requires some communication between IMAP servers. Partitions require IMAP protocol extensions. Everything else can be implemented through the use of IMAP4 commands User configuration information Commands tag GET pattern The GET command accepts as an argument a pattern that specifies some set of configuration options. Wildcards are permitted as in LIST, except that the behavior of the "%" wildcard is undefined. Option names are case-insensitive. The GET command will return some set of untagged OPTION replies, giving the names and values of matching options. EXAMPLE: A002 GET SENT* * OPTION SENT.MAILBOX SENT-MAIL [READ-WRITE] A002 OK Get completed tag SET option value The SET command accepts as arguments the name of an option and a string value. The value of the option is set to the specified string. If the option with that name does not already exist, it is created. Option names are case-insensitive atoms. SET is not allowed if the named option is read-only. tag UNSET option The UNSET command accepts as an argument the name of an option. Depending on the implementation, the option is either removed or its value reverts to the implementation-defined default. UNSET is not allowed if the named option is read-only. Myers [Page 13] Internet DRAFT IMSP March 1994 Responses * OPTION atom string string This response occurs as a result of a GET command. The first string is an option name that matches the pattern in the command. The second string is the value of the option. The third string is either [READ-WRITE] if the user may change the option or [READ- ONLY] if the user may not. Discussion Options can be site wide or per-user. Possible uses include: User preferences (e.g. mailbox to store copies of outgoing mail) Site configuration information (e.g. names of SMTP servers) Per- user configuration information (e.g. contents of From: header) The option name registry is currently imsp-options@andrew.cmu.edu. Address book Commands tag SEARCHADDRESS addressbook lookup_criteria The SEARCHADDRESS command searches the specified address book for entries that express the intersection (AND function) of all of the specified criteria. The names matching the criteria are returned in some set of untagged SEARCHADDRESS replies. If no criterea are specified, all names in the address book are provided. The lookup_criteria is a sequence of "field pattern" pairs, each specifying entries where the value of field matches the specified pattern in a case-independent manner. The pattern may optionally be an RFC-1522 [RFC1522] format multinational character string. The reserved field "name" specifies entries whose name matches the specified pattern. [Replace old istring mechanism with something else] EXAMPLE: A0340 SEARCHADDRESS Fred name "* Rubble" email "*@bedrock" * SEARCHADDRESS "Barney Rubble" * SEARCHADDRESS "Betty Rubble" A0340 OK Searchaddress completed Myers [Page 14] Internet DRAFT IMSP March 1994 tag FETCHADDRESS addressbook names Fetches the contents of the entries in the specified address book for the specified names. The entries are returned in a series of untagged FETCHADDRESS replies. Entry names are case-insensitive. EXAMPLE: A0341 FETCHADDRESS Fred "Barney Rubble" * FETCHADDRESS Fred "Barney Rubble" hair "blond" email "barney@bedrock" A0341 OK Fetchaddress completed tag STOREADDRESS addressbook name field_data Creates or modifies the entry in the specified addressbook for the specified name. Fields not specified in the command are not changed. Setting the value of a field to the null string removes the field. Entry names are case-insensitive strings. The reserved field name "name" may not be specified in field_data. EXAMPLE: A0342 STOREADDRESS Fred "Barney Rubble" phone "555" email "" * FETCHADDRESS Fred "Barney Rubble" hair "blond" phone "555" A0342 OK Storeaddress completed tag DELETEADDRESS addressbook name Removes the entry in the specified addressbook for the specified name. Responses * SEARCHADDRESS addressbook name This response occurs as a result of a SEARCHADDRESS command. The name refers to an address book entry that matches the search criteria. * FETCHADDRESS addressbook name field_data This is the means by which address book entries are returned to the client. The entry for name in addressbook contains field_data. Myers [Page 15] Internet DRAFT IMSP March 1994 Discussion Address books provide a way for users to store and search typed information. They are primarily intended to be used for storing information about entities with which the user communicates. The addressbook field to the various commands allows users to access address books belonging to other users, should they have the appropriate access. Servers are expected to at least allow the client to manipulate the address book with the same name as the "user" specified in the LOGIN command. Servers may accept "addressbook" values that do not correspond to users that may LOGIN. Each address book contains some number of entries. Each entry has a name and any number of fields. Each field has an atom name and a string value. The standard fields are: EMAIL CRLF-separated list of electronic mail addresses MEMBERS CRLF-separated list of address book entry specifiers which should be recursively expanded when sending mail to the address book entry. An address book entry specifier may be the name of an address book entry in the current address book, or it may be the name of an address book followed by a ":" followed by the name of an entry in that address book. Any occurances of ":" or "\" in the address book name or entry name must be quoted with a preceeding "\". PHONE CRLF-separated list of phone numbers ADDRESS Postal address An entry may also have additional, user-defined fields. Clients are expected to allow the user to view and modify all fields of an entry, even if they do not recognize some field names. Advisory Locking Commands tag LOCK OPTION option Myers [Page 16] Internet DRAFT IMSP March 1994 The LOCK OPTION command accepts as an argument the name of an option and attempts to acquire an exclusive semaphore. The named option need not exist. If the command is successful, the server must ensure that no other client will be able to successfully lock the named option until the successful client either performs a matching UNLOCK OPTION command or closes the connection. If the named option exists, the server then must ensure that the client's cached value of the option is up to date, by sending an untagged OPTION reply if necessary. If some other client has obtained the semaphore, the server must send a NO response, with the first word of the text being the token "[LOCKED]". The server should ensure that the client has permission to perform a SET operation on the option. Even though other clients may not perform a LOCK OPTION operation on the option, servers should not prevent them from performing SET operations on the option. EXAMPLE: A0067 LOCK OPTION SENT.MAILBOX * OPTION SENT.MAILBOX SENT-1993 A0067 OK Lock completed A0068 LOCK OPTION DELIVERY.HOSTS A0068 NO [LOCKED] Locked by Fred on client3.do.main tag UNLOCK OPTION option The UNLOCK OPTION command accepts as an argument the name of an option and releases any exclusive semaphore the client may have previously obtained on that option by using the LOCK OPTION command. tag LOCK ADDRESSBOOK addressbook name The LOCK ADDRESSBOOK command accepts as arguments an addressbook and the name of an entry. It attempts to acquire an exclusive semaphore. The addressbook must exist, but the named entry need not. If the command is successful, the server must ensure that no other client will be able to successfully lock the named entry in the addressbook until the successful client either performs a matching UNLOCK ADDRESSBOOK command or closes the connection. If the named option exists, the server then must ensure that the client's Myers [Page 17] Internet DRAFT IMSP March 1994 cached value of the entry is up to date, by sending an untagged FETCHADDRESS reply if necessary. If some other client has obtained the semaphore, the server must send a NO response, with the first word of the text being the token "[LOCKED]". The server should ensure that the client has permission to perform a STOREADDRESS operation on the entry. Even though other clients may not perform a LOCK ADDRESSBOOK operation on the entry, servers should not prevent them from performing STOREADDRESS operations on the entry. EXAMPLE: A0069 LOCK ADDRESSBOOK Fred barney * FETCHADDRESS Fred barney email "barney@bedrock" A0069 OK Lock completed A0070 LOCK ADDRESSBOOK Shared-book "Bam Bam" A0070 NO [LOCKED] Locked by Barney on client7.do.main tag UNLOCK ADDRESSBOOK addressbook name The UNLOCK ADDRESSBOOK command accepts as an arguments an adressbook and the name of an entry. It releases any exclusive semaphore the client may have previously obtained on that option by using the LOCK ADDRESSBOOK command. Discussion These commands allow cooperating clients to synchronize their updates to options and addressbooks. The ability to lock nonexistent options or address book entries allows clients to synchronize the addition of new options or address book entries. Although the locking interface is specified with a per-option and per-entry granularity, a server may implement the commands with a coarser granularity, say, per-user for options and per-addressbook for addressbooks. Access control lists Commands tag SETACL MAILBOX mailbox identifier rights Changes the access control list on the specified mailbox so that Myers [Page 18] Internet DRAFT IMSP March 1994 the specified identifier is granted the permissions enumerated in rights. Identifier has implementation-defined semantics. Possible variations of identifier interpretation include: * User names, as specified in the LOGIN command. * Named groups of users, presumably managed by some authorization service. * Only allowing identifiers supported by the operating system (e.g. ``user'', ``group'', and ``other'' for the Unix filesystem) * Whether rights granted to other mailboxes in an implementation-defined hierarchy are inherited * A portion of the identifier specifying an "authentication type". As an example, an implementation may control posting to a group based on the contents of the From: header: from$user p * Whether the union of rights for matching identifiers are granted to a user or whether the rights for the most specific matching identifier is granted. As an example, for a mailbox with the following ACL: user lrsa group-user-is-in lrsw One implementation may grant the user 'lrswa' rights, another may only grant the user 'lrsa'. * A prefix to an identifier name specifying the listed rights are to be removed from users who match the prefixed identifier. As an example, for a mailbox with the following ACL: group-user-is-in lrsw -user w An implementation may grant the user 'lrs' rights. Rights is a string listing a (possibly empty) set of alphanumeric Myers [Page 19] Internet DRAFT IMSP March 1994 characters, each character listing a set of operations which is being controlled. Letters [lowercase?] are reserved for ``standard'' rights, listed below. Digits are reserved for implementation or site defined rights. The standard rights are: l - lookup (mailbox is visible to LIST/LSUB/UNSEEN commands) r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, SEARCH, COPY from mailbox) s - keep seen/unseen information across sessions (STORE \SEEN flag) w - write (STORE flags other than \SEEN and \DELETED) i - insert (perform APPEND, COPY into mailbox) p - post (send mail to submission address for mailbox, not enforced by IMAP4/IMSP itself) c - create (CREATE new sub-mailboxes in any implementation-defined hierarchy) d - delete (STORE \DELETED flag, perform EXPUNGE) a - administer (perform SETACL) An implementation may tie rights together or may force rights to always or never be granted. For example, in an implementation that uses unix mode bits, the rights "wisd" are tied. The "a" right is always granted to the owner and is never granted to another user. If rights are tied in an implementation, it should be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, none should be used. Numeric rights may not be tied. tag SETACL ADDRESSBOOK addressbook identifier rights Changes the access control list of the specified addressbook so that the specified identifier is granted the permissions enumerated in rights. Identifier and rights are as specified for SETACL MAILBOX. Not all rights specified in SETACL MAILBOX will be meaningful for an address book. tag DELETEACL MAILBOX mailbox identifier Removes any portion of the access control list for mailbox for the specified identifier. tag DELETEACL ADDRESSBOOK addressbook identifier Removes any portion of the access control list for the specified addressbook for the specified identifier. Myers [Page 20] Internet DRAFT IMSP March 1994 tag GETACL MAILBOX mailbox Returns the access control list for mailbox in some set of untagged ACL replies. There may not be more than one ACL reply specifying any given identifier. EXAMPLE: A002 GETACL MAILBOX INBOX * ACL MAILBOX INBOX Fred rwipslda A002 Ok Getacl complete tag GETACL ADDRESSBOOK addressbook Returns the access control list for the specified addressbook in some set of untagged ACL replies. EXAMPLE: A002 GETACL ADDRESSBOOK Fred * ACL ADDRESSBOOK Fred anybody-else r * ACL ADDRESSBOOK Fred Fred rwipd A002 Ok Getacl complete tag MYRIGHTS MAILBOX mailbox Returns the set of rights that the user has to mailbox in an untagged MYRIGHTS reply. tag MYRIGHTS ADDRESSBOOK addressbook Returns the set of rights that the user has to the specified addressbook in an untagged MYRIGHTS reply. Responses * ACL MAILBOX string string string This response occurs as a result of a GETACL MAILBOX command. The first string is the mailbox name for which this ACL entry applies. The second string is the identifier for which this entry applies. The third string is the set of rights that the identifier has. * ACL ADDRESSBOOK string string string This response occurs as a result of a GETACL ADDRESSBOOK command. The first string is the addressbook for which this ACL entry Myers [Page 21] Internet DRAFT IMSP March 1994 applies. The second string is the identifier for which this entry applies. The third string is the set of rights that the identifier has. * MYRIGHTS MAILBOX string string This response occurs as a result of a MYRIGHTS MAILBOX command. The first string is the mailbox name for which this ACL entry applies. The third string is the set of rights that the client has. * MYRIGHTS ADDRESSBOOK string string This response occurs as a result of a MYRIGHTS ADDRESSBOOK command. The first string is the addressbook for which this ACL entry applies. The second string is the set of rights that the client has. Minimal conformance Implementation of the following commands is mandatory: NOOP LOGIN LOGOUT LIST LSUB UNSEEN [Make this optional?] ADDRESSBOOK SUBSCRIBE UNSUBSCRIBE CREATE (server_partition_list argument is optional) DELETE RENAME GET SET SEARCHADDRESS FETCHADDRESS STOREADDRESS DELETEADDRESS LOCK UNLOCK Myers [Page 22] Internet DRAFT IMSP March 1994 Backwards compatibility When a client is directed by a user or an initial configuration to contact a server, it should first attempt to reach the IMSP service. If that fails with connection refused, it should fall back to the IMAP4 protocol. Formal syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in RFC 822 with one exception; the delimiter used with the "#" construct is a single space (SP) and not a comma. acl_data ::= "ACL" SPACE acl_option SPACE astring SPACE astring SPACE astring acl_option ::= "MAILBOX" / "ADDRESSBOOK" addressbook ::= "ADDRESSBOOK" SPACE list_pattern address_data ::= "ADDRESSBOOK" SPACE "(" 0#flag_sys_ext ")" SPACE mstring_sep SPACE astring astring ::= atom / quoted-string / literal atom ::= 1* CHAR ::= CHAR8 ::= CR ::= CRLF ::= CR LF CTL ::= create ::= "CREATE" SPACE mailbox_other [ SPACE server_partition_list ] delete ::= "DELETE" SPACE mailbox_other [ SPACE hostname ] deleteaddress ::= "DELETEADDRESS" SPACE astring SPACE name DIGIT ::= Myers [Page 23] Internet DRAFT IMSP March 1994 digit_hex :: DIGIT / "a" / "b" / "c" / "d" / "e" / "f" extension ::= atom fetchaddress ::= "FETCHADDRESS" SPACE astring 1#( SPACE name ) fetchaddress_d ::= "FETCHADDRESS" SPACE astring SPACE name field_data field_data ::= 1#key_value flag_sys_ext ::= "\" extension get ::= "GET" SPACE list_pattern getacl ::= "GETACL" SPACE acl_option SPACE astring greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF hostname ::= atom ;; Fully qualified domain name kerberos_auth ::= 1*digit_hex kerberos_resp ::= 1*digit_hex key ::= atom key_value ::= SPACE key SPACE astring LF ::= list ::= "LIST" SPACE mailbox_other SPACE list_pattern list_pattern ::= astring ;; includes list_wildcards list_wildcards ::= "%" / "?" / "*" literal ::= "{" number "}" CRLF 1*CHAR8 ;; The number represents the number of CHAR8 octets. login ::= "LOGIN" SPACE userid SPACE password logout ::= "LOGOUT" lookup_criterea ::= 0#( SPACE key SPACE list_pattern ) lsub ::= "LSUB" SPACE mailbox_other SPACE list_pattern Myers [Page 24] Internet DRAFT IMSP March 1994 mailbox ::= "INBOX" / mailbox_other mailbox_other ::= astring ;; May not be INBOX (in any case.) Should not ;; include list_wildcards. May be case-dependent ;; as a function of server implementation. mailbox_data ::= "LIST" SPACE mstring / "LSUB" SPACE mstring / "UNSEEN" SPACE mstring mstring ::= mstring_attr SPACE "(" 1#hostname ")" SPACE mstring_sep SPACE mailbox ;; Represents a mailbox mstring_attr ::= "(" 0#("\Noinferiors" / "\Noselect" / flag_sys_ext) ")" mstring_sep ::= <"> QCHAR <"> / nil move ::= "MOVE" SPACE mailbox SPACE hostname SPACE server_partition_list myrights ::= "MYRIGHTS" SPACE acl_option SPACE astring myrights_data ::= "MYRIGHTS" acl_option SPACE astring SPACE astring name ::= quoted-string / atom nil ::= "NIL" noop ::= "NOOP" number ::= 1*DIGIT option_data ::= "OPTION" SPACE atom SPACE astring SPACE ("[READ-ONLY]" / "[READ-WRITE]") password ::= astring / "@KERBEROS:" kerberos_auth QCHAR ::= qspecials ::= <"> / "%" / "\" quoted_string ::= <"> *QCHAR <"> ready ::= "+" SPACE response_text rename ::= "RENAME" SPACE mailbox SPACE mailbox_other Myers [Page 25] Internet DRAFT IMSP March 1994 replace ::= "REPLACE" SPACE mailbox_other SPACE mailbox_other request ::= tag SPACE (noop / login / logout / list / lsub / unseen / addressbook / subscribe / unsubscribe / create / delete / rename / replace / move / get / set / searchaddress / fetchaddress / storeaddress / deleteaddress / getacl / setacl / myrights) CRLF response ::= * response_done response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / mailbox_data / address_data / option_data / searchaddress_d / fetchaddress_d / acl_data / myrights_data) CRLF response_done ::= response_tagged / response_fatal response_fatal ::= "*" SPACE resp_cond_bye CRLF response_tagged ::= tag SPACE resp_cond_state CRLF resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text ;; Authentication condition resp_cond_bye ::= "BYE" SPACE resp_text ;; Server will disconnect condition resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text ;; Status condition resp_text ::= [resp_token SPACE] text_line resp_token ::= "LOCKED" / "X" atom / kerberos_resp searchaddress ::= "SEARCHADDRESS" SPACE astring lookup_criteria searchaddress_d ::= "SEARCHADDRESS" SPACE astring SPACE name server_partition ::= hostname [ "/" atom ] server_partition_list ::= "(" 1#server_partition ")" set ::= "SET" SPACE atom SPACE astring setacl ::= "SETACL" SPACE acl_option SPACE astring SPACE astring SPACE astring Myers [Page 26] Internet DRAFT IMSP March 1994 SPACE ::= specials ::= "(" / ")" / "{" / qspecials storeaddress ::= "STOREADDRESS" SPACE astring SPACE name field_data subscribe ::= "SUBSCRIBE" SPACE mailbox tag ::= 1*TCHAR TCHAR ::= TEXTCHAR ::= text_line ::= 1*TEXTCHAR unseen ::= "UNSEEN" SPACE mailbox_other SPACE list_pattern unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox_mailbox userid ::= astring A protocol session is as follows: Server: greeting * Server: response > References [IMAP4] Crispin, Mark R., "Internet Message Access Protocol - Version 4", Work in Progress of the IETF IMAP WG, draft-ietf-imap- imap4-??.txt. Check Internet Drafts listing for latest version. [RFC1522] Moore, Keith, "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522, University of Tennessee, September 1993. Myers [Page 27] Internet DRAFT IMSP March 1994 Security Considerations Security issues are discussed in this memo only as far as authentication for the purpose of accessing a server are concerned. Author's Address John G. Myers Carnegie-Mellon University 5000 Forbes Ave. Pittsburgh PA, 15213-3890 Email: jgm+@cmu.edu This document will expire before September 25, 1994. Myers [Page 28]