InfoMagic Internet Tools 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0050.txt < prev next >

Wrap

Text File | 1993-07-02 | 39.7 KB | 1,038 lines

I think I'm ready to throw this to the wolves. Comments welcome. *DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT* Network Working Group J. G. Myers Request for Comments: ???? Carnegie Mellon March 1993 IMSP -- Interactive Mail Support Protocol Status of this memo This document suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. 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 intent of the Interactive Mail Support Protocol (IMSP) is to support the provision of mail in a medium to large scale operation. It is intended to be used as a companion to the IMAP2bis protocol [RFC-1176] [IMAP2bis], providing services which are either outside the scope of mail access or which pertain to environments which must run more than one IMAP2 server in the same mail domain. 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 IMAP2 counterparts. Like the IMAP2 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 "unsolicited 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 XXX. When a connection is opened the server sends an unsolicited 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 FIND 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 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 FIND ALL.MAILBOXES INBOX --> <-- * MAILBOX INBOX (imap3.do.main) <-- A0002 OK Find complete {Wait for command} A003 SUBSCRIBE BBOARD 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} 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. Responses tag OK text This response identifies successful completion of the command with that tag. The text is a line of human-readable text that may be useful in a protocol telemetry log for debugging purposes. tag NO 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 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. * 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. * OK text This response identifies normal operation on the server. No special action by the client is called for, however, the text should be displayed to the user in some fashion. This is currently only used by servers at startup as a greeting message to show they are ready to accept the first command. * NO text This response identifies a warning from the server that does not affect the overall results of any particular request. The text is a line of human-readable text that should be presented to the user as a warning of improper operation. * BAD text This response identifies a serious error at the server; it may also indicate faulty protocol 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. It should also be recorded in any telemetry as part of a bug report to the maintainer of the client and server. + text This response identifies that the server is ready to accept the text of a literal from the client. 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. In practice, this condition is rarely encountered. In the current protocol, the only client command likely to contain a literal is the LOGIN command. Consider a server that validates the user before checking the password. If the password contains "funny" characters and hence is sent as a literal, then if the user is invalid an error would occur before the password is parsed. No such synchronization protection is provided for literals sent from the server to the client, for performance reasons. Any synchronization problems in this direction would be caused by a bug in the client or server. 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 should send an unsolicited BYE response before the (tagged) OK response, and then close the network connection. 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 unsolicited reply "PREAUTH" instead of "OK" to indicate that external authentication has taken place. Server location and new message information Commands tag FIND MAILBOXES pattern The FIND MAILBOXES command accepts as an argument a pattern (including wildcards) that specifies some set of mailbox names that are usable by connecting to an IMAP2 server and using the SELECT command. The format of mailboxes is implementation dependent. Only those mailboxes that the user has declared as being "subscribed" are returned. Two wildcard characters are defined; "*" specifies any number (including zero) characters may match at this position and "%" specifies a single character may match at this position. For example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, whereas FOO%BAR will match only FOO.BAR. "*" will match all mailboxes. The FIND MAILBOXES command will return some set of unsolicited MAILBOX replies that have as their value a single mailbox name and a list of hosts on which the mailbox resides. EXAMPLE: A002 FIND MAILBOXES * * MAILBOX INBOX (imap3.do.main) * MAILBOX FOOBAR (imap3.do.main) * MAILBOX GENERAL (imap12.do.main) A002 OK Find completed Although the use of explicit file or path names for mailboxes is discouraged by this standard, it may be unavoidable. It is important that the value returned in the MAILBOX unsolicited reply be usable in a SELECT command given to an IMAP server running on each of the returned hosts without remembering any path specification that may have been used in the FIND MAILBOXES pattern. The SUBSCRIBE MAILBOX and UNSUBSCRIBE MAILBOX commands manipulate the list returned by this command. tag FIND ALL.MAILBOXES pattern The FIND ALL.MAILBOXES command is similar to FIND MAILBOXES; however, it should return a complete list of all mailboxes available to the user. Data is returned as in FIND MAILBOXES. The exact meaning of this 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. The command must at least return the set of mailboxes that FIND MAILBOXES does. tag FIND UNSEEN.MAILBOXES pattern The FIND UNSEEN.MAILBOXES command is similar to FIND MAILBOXES; however, only those "subscribed" mailboxes in which there are messages without the \SEEN flag are returned. Data is returned as in FIND MAILBOXES. Should an implementation be unable to determine which mailboxes have unread messages, it should return the same information returned by FIND MAILBOXES. tag FIND BBOARDS pattern The FIND BBOARDS command accepts as an argument a pattern that specifies some set of bulletin board names that are usable by connecting to an IMAP2 server and using the BBOARD command. Wildcards are permitted as in FIND MAILBOXES. Only those bboards that the user has declared as being "subscribed" are returned. The FIND BBOARDS command will return some set of unsolicited BBOARD replies that have as their value a single bulletin board name and a list of hosts on which the bboard resides. EXAMPLE: A002 FIND BBOARDS * * BBOARD comp.mail.mime (imap7.do.main imap8.do.main) * BBOARD GENERAL (imap2.do.main) A002 OK Find completed tag FIND ALL.BBOARDS pattern The FIND ALL.BBOARDS command is similar to FIND BBOARDS; however, it should return a complete list of all bulletin boards available to the user. Data is returned as in FIND BBOARDS. The exact meaning of this is implementation-dependent, since the concept of a bounded or deterministic set of `bboards available to the user' may not be meaningful for a particular server or server implementation. The command must at least return the set of bboards that FIND BBOARDS does. tag FIND UNSEEN.BBOARDS pattern The FIND UNSEEN.BBOARDS command is similar to FIND BBOARDS; however, only those "subscribed" bboards for which there are messages without the \SEEN flag are returned. Data is returned as in FIND BBOARDS. Should an implementation be unable to determine which bboards have unread messages, it should return the same information returned by FIND BBOARDS. Responses * MAILBOX string server_list This response occurs as a result of a FIND MAILBOXES, FIND ALL.MAILBOXES, or FIND UNSEEN.MAILBOXES command. The string is a mailbox name that matches the pattern in the command. server_list is an S-expression list of the fully qualified domain names of the hosts on which the mailbox resides. 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). * BBOARD string server_list This response occurs as a result of a FIND BBOARDS, FIND ALL.BBOARDS, or FIND UNSEEN.BBOARDS command. The string is a bboard name that matches the pattern in the command. server_list is an S-expression list of the fully qualified domain names of the hosts on which the bboard resides. Should the server_list contain more than one host name, the client should access the bboard 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). Discussion When a user asks a client to read a bboard by name, the client should issue a "FIND ALL.BBOARDS" command to the IMSP server in order to determine which server it is on. An alternate way of returning the server location would be to use the {server.do.main} notation used by a popular IMAP client library. This would have simplified the implementation of IMSP by those client. This was not done for the following reasons: * The {server.do.main} notation provides no mechanism for specifying multiple hosts. * This would assign a protocol interpretation to what is explicitly specified in RFC-1176 as being implementation specific. There is a minor design flaw in IMAP2bis: the MAILBOX/BBOARD unsolicited response has an ambiguous meaning--one can only tell if the folder is subscribed or not by figuring out whether it is a response to a FIND foo or a FIND ALL.foo command. The following is a possible implementation of the FIND UNSEEN.MAILBOXES and FIND UNSEEN.BBOARDS commands: When a message is appended to a folder, the IMAP server notifies the IMSP server of some unique (within the folder) attribute of the message. Possibile attributes include the message-id and the internaldate. This could be done using an IMSP extension: tag LAST MAILBOX mailbox attribute user tag LAST BBOARD mailbox attribute When a user switches folders or closes a connection and has read all messages in that folder, the IMAP server notifies the IMSP server that the user has read all of the messages, including the attribute of the last message. This too could be done using an IMSP extension: tag SEEN MAILBOX mailbox attribute user tag SEEN BBOARD mailbox attribute user When asked for folders with unread 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 folder. In the interest of having the IMAP server/IMSP server communications be the same across implementation, it might be worthwhile to propose this method of implementing FIND UNSEEN.MAILBOXES and FIND UNSEEN.BBOARDS as a standard. Subscription management tag SUBSCRIBE MAILBOX mailbox The SUBSCRIBE MAILBOX command adds the specified mailbox name to the list of "active" or "subscribed" mailboxes as returned by the FIND MAILBOXES command. This command returns an OK response only if the subscription is successful. Subscriptions should be preserved between sessions. tag UNSUBSCRIBE MAILBOX mailbox The UNSUBSCRIBE MAILBOX command removes the specified mailbox name from the list of "active" or "subscribed" mailboxes as returned by the FIND MAILBOXES command. This command returns an OK response only if the unsubscription is successful. Unsubscriptions should be preserved between sessions. tag SUBSCRIBE BBOARD bboard The SUBSCRIBE BBOARD command adds the specified mailbox name to the list of "active" or "subscribed" bulletin boards as returned by the FIND BBOARDS command. This command returns an OK response only if the subscription is successful. Subscriptions should be preserved between sessions. tag UNSUBSCRIBE BBOARD bboard The UNSUBSCRIBE BBOARD command removes the specified mailbox name from the list of "active" or "subscribed" bulletin boards as returned by the FIND BBOARDS command. This command returns an OK response only if the unsubscription is successful. Unsubscriptions should be preserved between sessions. Mailbox and BBoard 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. Otherwise, the name INBOX can not be used; see section VI, "INBOX Requirement Loosened", of IMAP2bis [IMAP2bis] for more details. 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. 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 the mailbox, their subscriptions should be updated appropriately. Renaming INBOX is permitted. A new, empty INBOX is created in its place. Should users be subscribed to the INBOX, they should remain subscribed to the new, empty INBOX. 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. tag CREATE.BBOARD bboard tag CREATE.BBOARD bboard server_partition_list The CREATE.BBOARD command creates a bboard with the given name. This command returns an OK response only if a new bboard with that name has been created. It is an error to attempt to create a bboard with a name that refers to an extant bboard. Any error in creation will return a NO response. If server_partition_list is specified, it indicates the server or set of servers on which the bboard 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 bboard on the server. EXAMPLE: A002 CREATE.BBOARD FOOBAR (imap2.do.main/a map4.do.main) A002 OK Create completed If server_partition_list is specified, the placement of the bboard is up to the implementation. tag DELETE.BBOARD bboard tag DELETE.BBOARD bboard hostname The DELETE.BBOARD command deletes a bboard with the given name. This command returns an OK response only if a bboard 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. If hostname is specified, the bboard is deleted on that host. If it is not specified, the bboard is deleted on all hosts on which the bboard resides. tag RENAME.BBOARD oldbboard newbboard The RENAME.BBOARD command changes the name of a bboard. This command returns an OK response only if a bboard 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 bboard name that does not exist or a new bboard name which already exists. Any error in renaming will return a NO response. Should any users be subscribed to the bboard, their subscriptions should be updated appropriately. tag MOVE.BBOARD bboard hostname server_partition_list The MOVE.BBOARD command moves a bboard between servers and/or replicates a bboard. 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. tag ALIAS.BBOARD oldbboard newbboard After "oldbboard" gets subsequently deleted, all users that are subscribed to "oldbboard" will be subscribed to newbboard. [Call this RESUBSCRIBE? Put in Subscription management? Actually perform the deletion? Provide ALIAS command for mailboxes?] 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/bboards, or the MOVE and MOVE.BBOARD commands. MOVE and MOVE.BBOARD cannot be implemented without some non-IMAP2 communication with the IMAP servers. Replication requires some communication between IMAP servers. CREATE.BBOARD, DELETE.BBOARD, and RENAME.BBOARD, and partitions require IMAP protocol extensions. Everything else can be implemented through the use of IMAP2bis 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 FIND MAILBOXES. The GET command will return some set of unsolicited OPTION replies, giving the names and values of matching options. Example: A002 GET BCC* * OPTION BCC.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 must conform to the grammar of 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. 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 namespace could be split into a section for standard options and sections for client-specific options. Possible standard options include: DATE (current time, in rfc822 format) DOMAIN (local mail domain) FROM (string to use for From: header) DELIVERY.HOSTS (list of smtp hosts for mail submission) BCC.MAILBOX (mailbox to store copies of outgoing mail) Access control lists Commands tag SETACL MAILBOX mailbox identifier rights Changes the access control list on the specified mailbox so that 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 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 (folder is visible to FIND 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 IMAP2/IMSP itself) c - create (CREATE new sub-folders 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 BBOARD bboard identifier rights Changes the access control list on the specified mailbox so that the specified identifier is granted the permissions enumerated in rights. Identifier and rights are as specified for SETACL MAILBOX. tag DELETEACL MAILBOX mailbox identifier Removes any portion of the access control list for mailbox for the specified identifier. tag DELETEACL BBOARD bboard identifier Removes any portion of the access control list for bboard for the specified identifier. tag GETACL MAILBOX mailbox Returns the access control list for mailbox in some set of unsolicited 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 BBOARD bboard Returns the access control list for bboard in some set of unsolicited ACL replies. EXAMPLE: A002 GETACL BBOARD comp.mail.mime * ACL BBOARD comp.mail.mime anybody-else rpsl * ACL BBOARD comp.mail.mime news rwipcsld A002 Ok Getacl complete tag MYACL MAILBOX mailbox Returns the set of rights that the user has to mailbox in an unsolicited ACL reply. tag MYACL BBOARD mailbox Returns the set of rights that the user has to bboard in an unsolicited ACL reply. Responses * ACL MAILBOX string string string This response occurs as a result of a GETACL MAILBOX or MYACL 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 BBOARD string string string This response occurs as a result of a GETACL BBOARD or MYACL BBOARD command. The first string is the bboard 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. Discussion The assignment of letters to rights is AFS-centric. Alternatively we could change i->a, l->v, a->what?. The set of rights should make some sense in other messaging domains, particularly NNTP. The IMSP and NNTP ACL specifications should be similar. The IMSP author will work with the author of the NNTP ACL extension in order to resolve this. Unresolved issues The following mail support issues have been raised, but not resolved in IMSP. * User forwarding address * User address book * Distribution lists Deferred. These probably belong in a separate user directory service. * Mail filing control (e.g. ``vacation'', delivery of mail to folders other than INBOX based on subject, sender) Deferred. This probably belongs in a separate service, quite possibly a user directory service. * Administrative issues: Purge rates for bboards (not necessarily age related) Quotas for users or bboards (not necessarily megabyte related) * Notification issues Current use of quota Exhaustion of quota Renamed/deleted folders/bboards [ Use unsolicited OK/NO messages? ] For renamed/deleted folders/bboards, server should notify, then change or delete subscription as necessary. Minimal conformance Implementation of the following commands is mandatory: NOOP LOGIN LOGOUT FIND MAILBOXES FIND ALL.MAILBOXES FIND UNSEEN.MAILBOXES FIND BBOARDS FIND ALL.BBOARDS FIND UNSEEN.BBOARDS SUBSCRIBE MAILBOX SUBSCRIBE BBOARD UNSUBSCRIBE MAILBOX UNSUBSCRIBE BBOARD GET SET [CREATE DELETE RENAME CREATE.BBOARD, DELETE.BBOARD RENAME.BBOARD ALIAS.BBOARD with partitions and multiple residency optional?] 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 IMAP2 protocol. Conventions The following terms are used in a meta-sense in the syntax specification below: An ASCII-STRING is a sequence of arbitrary ASCII characters. An ATOM is a sequence of ASCII characters delimited by SP or CRLF. A CHARACTER is any ASCII character except """", "{", CR, or LF. A CRLF is an ASCII carriage-return character followed immediately by an ASCII linefeed character. A NUMBER is a sequence of the ASCII characters that represent decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or ":". A SP is the ASCII space character. A TEXT_LINE is a human-readable sequence of ASCII characters up to but not including a terminating CRLF. A common field in the IMSP protocol is a STRING, which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes), or a LITERAL. A literal consists of an open brace ("{"), a number, a close brace ("}"), a CRLF, and then an ASCII-STRING of n characters, where n is the value of the number inside the brace. In general, a string should be represented as an ATOM or QUOTED-STRING if at all possible. The semantics for QUOTED-STRING or LITERAL are checked before those for ATOM; therefore an ATOM used in a STRING may only contain CHARACTERs. Literals are most often sent from the server to the client; in the rare case of a client to server literal there is a special consideration (see the "+ text" response below). Note the set of allowable CHARACTERs is larger than specified for IMAP2. 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 ::= "ACL" acl_option SP string SP string SP string acl_option ::= "MAILBOX" / "BBOARD" alias_bboard ::= "ALIAS.BBOARD" SP string SP string bboard_reply ::= "BBOARD" SP string SP "(" 1#hostname ")" create ::= "CREATE" SP mailbox [ server_partition_list ] create_bboard ::= "CREATE.BBOARD" SP string [ server_partition_list ] delete ::= "DELETE" SP mailbox [ hostname ] delete_bboard ::= "DELETE.BBOARD" SP string [ hostname ] find ::= "FIND" SP find_option SP string find_option ::= "MAILBOXES" / "ALL.MAILBOXES" / "UNSEEN.MAILBOXES / "BBOARDS" / "ALL.BBOARDS" / "UNSEEN.BBOARDS" get ::= "GET" SP string getacl ::= "GETACL" SP acl_option SP string hostname ::= atom ; Fully qualified domain name literal ::= "{" NUMBER "}" CRLF ASCII-STRING login ::= "LOGIN" SP userid SP password logout ::= "LOGOUT" mailbox ::= "INBOX" / string mailbox_reply ::= "BBOARD" SP string SP "(" 1#hostname ")" move ::= "MOVE" SP mailbox SP hostname SP server_partition_list move_bboard ::= "MOVE.BBOARD" SP string SP hostname SP server_partition_list myacl ::= "MYACL" SP acl_option SP string noop ::= "NOOP" option ::= "OPTION" SP atom SP string SP string rename ::= "RENAME" SP mailbox SP string rename_bboard ::= "RENAME.BBOARD" SP string SP string request ::= tag SP (noop / login / logout / find / subscribe / unsubscribe / create / delete / rename / move / create_bboard / delete_bboard / rename_bboard / move_bboard / alias_bboard / get / set / getacl / setacl / myacl) CRLF response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF server_partition ::= hostname [ "/" atom ] server_partition_list ::= "(" 1#server_partition ")" set ::= "SET" SP atom SP string setacl ::= "SETACL" SP acl_option SP string SP string string ::= atom / """" 1*character """" / literal subscribe ::= "SUBSCRIBE" SP subscribe_opt SP string subscribe_opt ::= "MAILBOX" / "BBOARD" unsolicited ::= "*" SP (mailbox_reply / bboard_reply / option / acl) CRLF unsubscribe ::= "UNSUBSCRIBE" SP subscribe_opt SP string References [RFC-1176] Crispin, Mark R. Interactive Mail Access Protocol - Version 2. August 1990. RFC-1176. [IMAP2bis] Crispin, Mark R. IMAP2bis - Extensions to the IMAP2 Protocol, December 1992 Author's Address John G. Myers Carnegie-Mellon University 4910 Forbes Ave. Pittsburgh PA, 15213-3890 Email: jgm+@cmu.edu