Network Working Group Sabarish Ramanathan Internet Draft: Internet Message Mapping Protocol Sabari Illam Document: internet-drafts/draft-sabarish-immp-01.txt May 2005 IMMP -- Internet Message Mapping Protocol Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. By submitting this Internet-Draft, I accept the provisions of Section 3 of RFC 3667 (BCP 78). 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. 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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Sabarish [Page 1] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 Abstract The Internet Message Mapping Protocol (IMMP) 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 SMTP protocol and mail receiving protocols (POP, IMAP, web mail also), providing services which are outside the scope of mail access. The services that IMMP provides are mapping mails into appropriate subinbox (inside the inbox) when the messages are received through SMTP, Extended inbox management and Spam guard management. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Conventions Used in this Document . . . . . . . . . . . . 3 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 2.1 Link Level . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 IMMP Model . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1 Client Server Model . . . . . . . . . . . . . . . . . 4 2.2.2 IMMP with SMTP model . . . . . . . . . . . . . . . . . 4 2.3 Commands and Responses. . . . . . . . . . . . . . . . . . 5 2.3.1 Client Protocol Sender and Server Protocol Receiver . 6 2.3.2 Server Protocol Sender and Client Protocol Receiver . 7 3 State and Flow Diagram . . . . . . . . . . . . . . . . . . . 7 3.1 Non-Authenticated State . . . . . . . . . . . . . . . . . 8 3.2 Authenticated State . . . . . . . . . . . . . . . . . . . 8 3.3 Logout State . . . . . . . .. . . . . . . . . . . . . . . 8 3.4 Anonymous State . . . . . . . . . . . . . . . . . . . . 8 4 Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1 Atom . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Number . . . . . . . .. . . . . . . . . . . . . . . . . . 8 4.3 String. . . . . . . .. . . .. . . . . . . . . . . . . . . 8 4.3.1 8-bit and Binary Strings. . . . . . . . . . . . . . . 9 5 Operational Considerations . . . . . . . . . . . . . . . . . 9 5.1 SubInbox Naming . . . . . . . . . . . . . . . . .. . . . 9 5.2 Untagged Status Updates . . . . . . . . . . . . . . . . . 10 5.3 Response when no Command in Progress . . . . . . . . . . 10 5.4 Autologout Timer . . . . . . . . . . . . . . . . . . . . 10 5.5 Multiple Commands in Progress . . . . . . . .. . . . . . 10 5.6 Mail Access Protocol Fallback . . . . . . . . . . . . 11 6 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1 Client Commands - Any State . . . . . . . . . . .. . . . 11 6.1.1 CAPABILITY Command . . . . . . . . . . . . . . . . . . 11 6.1.2 NOOP Command . . . . .. . . . . . . . . . . . . . . . 12 6.1.3 LOGOUT Command . . . . . . . . . . . . . . . . . . . . 12 6.2 Client Commands - Non-Authenticated State. . . . .. . . . 12 6.2.1 AUTHENTICATE Command . . . . . . . . . . . . . . . . 13 6.2.2 LOGIN Command . . . . .. . . . . . . . . . . . . . . 14 Sabarish [Page 2] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 6.3 Client Commands - SubInbox management. . . . . . .. . . . 15 6.3.1 CREATE Command . . . . . . . . . . . . . . . . . . . .15 6.3.2 DELETE Command . . . . .. . . . . . . . . . . . . . . .16 6.3.3 RENAME Command . . . . . . . . . . . . . . . . . . . . 16 6.3.4 REPLACE Command . . . . . . . . . . . . . . . . . . . 17 6.3.5 MOVE Command . . . . .. . . . . . . . . . . . . . . . 17 6.3.6 LIST Command . . . . . . . . . . . . . . . . . . . . .18 6.4 Client Commands - Spam Guard Agent . . . . . . . . . . . 19 6.4.1 SEARCHSPAMENTRY Command . . . . . . . . . . . . . . .20 6.4.2 STORESPAMENTRY Command . . . . .. . . . . . . . . . . .20 6.4.3 DELETESPAMENTRY Command . . . . . . . . . . . .. . . . 21 6.4.4 SEARCHSPAMGUARDAGENT Command . . . . . . . . .. . . . 21 6.4.5 STORESPAMGUARDAGENT Command . . . . .. . . . .. . . . 22 6.4.6 DELETESPAMGUARDAGENT Command . . . . . . . . . . . . .22 6.5 Client Commands - Anonymous Query Commands . . .. . . . . 22 6.5.1 VERIFYINSPAMGUARDAGENT Command . . . . . . . . . . .23 6.5.2 VERIFYSUBINBOX Command . . . . .. . . . . . . . . . . .23 7 Security Considerations . . . . . . . . . . . . . . . . . . . 23 8 IANA consideration . . . . . . . . . . . . . . . . . . . . . . 24 9 Informative References . . . . . . . . . . . . . . . . . . . 24 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property Statement . . . . . . . . . . . . . . . 25 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1 Introduction 1.1 Scope This document describes how to map messages into subinboxes of an inbox of a mail. It also describes how to block the spam mail coming to store in the inbox or subinboxes. It also describes how the clients are going to manage subinboxes and spam guard agent. 1.2 Conventions Used in this Document The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 1.3 Abbreviations SMTP indicates Simple Mail Transfer Protocol throughout this document. IMMP indicates Internet Message Mapping Protocol throughout this document. Sabarish [Page 3] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 In examples, "RS:", "IS:" and "IC:" indicate lines sent by the Receiver-SMTP, IMMP-Server and IMMP-Client respectively. 2 Protocol Overview 2.1 Link Level The IMMP protocol assumes a reliable data stream such as provided by TCP. When TCP is used, an IMMP-Server listens on port 323. 2.2 IMMP Model 2.2.1 Client Server Model This model of IMMP describes how the clients are creating, renaming or deleting SubInboxes inside an Inbox of a user through IMMP-Server. This model also describes how the client is managing the Spam guard agent inside the IMMP-Server. We are going to discuss about this in details in coming chapters. 2.2.2 IMMP with SMTP model The IMMP design is based on the following model of communication: as the result of a destination Receiver-SMTP received the From-Mail address and To-Mail address from the Sender-SMTP, then it checks whether To-Mail address (after removing the SubInboxes information from the mail address) is valid or not. If the To-Mail address is valid then the Receiver-SMTP server establishes a two way transmission channel to IMMP-Server and checks whether that From-Mail address is blocked by the IMMP SPAM guard agent of the To-Mail address. If the From-Mail address is not blocked by the Spam guard agent in IMMP server, then it sends an acceptance receipt OK reply to the Receiver-SMTP to accept the mail. If From-Mail address is blocked then IMMP-Server sends denied receipt NO reply to the Receiver-SMTP. IMMP commands are generated by the Receiver-SMTP and sent to the IMMP-Server. IMMP replies are sent from the IMMP-Server to the Receiver-SMTP in response to the commands. If Spam guard accepted to receive the mail from From-Address, Receiver-SMTP sends OK reply to the Sender-SMTP to transfer the remaining mail data. After receiving the end of mail indicator from the Sender-SMTP, Receiver-SMTP checks whether the To-Mail address is having the SubInboxes information. If there is no SubInboxes information in the To-Address, then Receiver-SMTP maps (stores) the Sabarish [Page 4] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 mail into the INBOX of the recipient. If the To-Mail address has SubInboxes information then Receiver-SMTP establishes a two way transmission channel to the IMMP server and checks the availability of the SubInboxes for that Recipient and if it is available then sends OK reply to Receiver-SMTP and Receiver-SMTP server mapped (stored) the data into that SubInbox of the Recipient. If Receiver-SMTP server gets the unavailability of the SubInbox as NO reply from the IMAP-Server then Receiver-SMTP server stores the data into the Inbox of the Recipient itself. ------------------------------------------------------------- +----------+ +----------+ +------+ | | | | +------+ | User |<-->| | | |<-->| IMMP | +------+ | Sender- | | Receiver-| +------+ +------+ | SMTP |<-->| SMTP | +------+ | File |<-->| | | |<-->| File | |System| | | | | |System| +------+ +----------+ +----------+ +------+ IMMP with SMTP model Figure 1 ------------------------------------------------------------- 2.3 Commands and Responses A Receiver-SMTP and IMMP-Server and session consist of the establishment of a client/server connection, query for verifying whether the From-Address is blocked by the spam guard of IMMP-Server for the corresponding To-Address and also check the availability of SubInboxes for that Recipient. An IMMP client/server model session consists of the establishment of a client/server connection, an initial greeting from the server, and client/server interactions. These client/server interactions consist of a client command, server data, and a server completion result response. Sabarish [Page 5] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 All interactions transmitted by client and server are in the form of lines; that is, strings that end with a CRLF. The protocol receiver of an IMMP-Client or Server is either reading a line, or is reading a sequence of octets with a known count followed by a line. 2.3.1 Client Protocol Sender and Server Protocol Receiver The client command begins an operation. Each client command is prefixed with an identifier (typically a short alphanumeric string, e.g. A0001, A0002, etc.) called a "tag". A different tag is generated by the client for each command. Requests send by SMTP server to check the availability of SubInboxes and query against Spam Guard Agent in IMMP server needs not to have a tag in the request and they need not to Authenticate. There are two cases in which a line from the client does not represent a complete command. In one case, a command argument is quoted with an octet count (see the description of literal in String under Data Formats); in the other case, the command arguments require server feedback (see the AUTHENTICATE command). In either case, the server sends a command continuation request response if it is ready for the octets (if appropriate) and the remainder of the command. This response is prefixed with the token "+". Note: If, instead, the server detected an error in the command, it sends a BAD completion response with tag matching the command (as described below) to reject the command and prevent the client from sending any more of the command. It is also possible for the server to send a completion response for some other command (if multiple commands are in progress), or untagged data. In either case, the command continuation request is still pending; the client takes the appropriate action for the response, and reads another response from the server. The protocol receiver of an IMMP server reads a command line from the client, parses the command and its arguments, and transmits server data and a server command completion result response. Sabarish [Page 6] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 2.3.2 Server Protocol Sender and Client Protocol Receiver Data transmitted by the server to the client and status responses that do not indicate command completion are prefixed with the token "*", and are called untagged responses. Server data may be sent as a result of a client command, or may be sent unilaterally by the server. There is no syntactic difference between server data that resulted from a specific command and server data that were sent unilaterally. The server completion result response indicates the success or failure of the operation. It is tagged with the same tag as the client command which began the operation. Thus, if more than one command is in progress, the tag in a server completion response identifies the command to which the response applies. There are three possible server completion responses: OK (indicating success), NO (indicating failure), or BAD (indicating protocol error such as unrecognized command or command syntax error). The protocol receiver of an IMMP client reads a response line from the server. It then takes action on the response based upon the first token of the response, which may be a tag, a "*", or a "+". As described above. A client MUST be prepared to accept any server response at all times. This includes server data that it may not have requested. Server data SHOULD be recorded, so that the client can reference its recorded copy rather than sending a command to the server to request the data. 3 State and Flow Diagram An IMMP server is in one of four states. Most commands are valid in only certain states. It is a protocol error for the client to attempt a command while the command is in an inappropriate state. In this case, a server will respond with a BAD or NO (depending upon server implementation) command completion result. Sabarish [Page 7] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 3.1 Non-Authenticated State In non-authenticated state, the user must supply authentication credentials before most commands will be permitted. This state is entered when a connection starts unless the connection has been pre-authenticated. 3.2 Authenticated State In authenticated state, the user is authenticated and most commands will be permitted. This state is entered when a pre-authenticated connection starts or when acceptable authentication credentials have been provided. 3.3 Logout State In logout state, the session is being terminated, and the server will close the connection. This state can be entered as a result of a client request or by unilateral server decision. 3.4 Anonymous State In anonymous state, the SMTP server sends the query to Spam guard agent of IMMP server and also checks the availability of SubInboxes in the Inbox. 4 Data Formats IMMP uses textual commands and responses. Data in IMMP can be in one of several forms: atom, number, string, parenthesized list, or NIL. 4.1 Atom An atom consists of one or more non-special characters. 4.2 Number A number consists of one or more digit characters, and represents a numeric value. 4.3 String A string is in one of two forms: literal and quoted string. The literal form is the general form of string. The quoted string form is an alternative that avoids the overhead of processing a literal at the cost of restrictions of what may be in a quoted string. Sabarish [Page 8] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 A literal is a sequence of zero or more octets (including CR and LF), prefix-quoted with an octet count in the form of an open brace ("{"), the number of octets, close brace ("}"), and CRLF. In the case of literals transmitted from server to client, the CRLF is immediately followed by the octet data. In the case of literals transmitted from client to server, the client must wait to receive a command continuation request (described later in this document) before sending the octet data (and the remainder of the command). A quoted string is a sequence of zero or more 7-bit characters, excluding CR and LF, with double quote (<">) characters at each end. The empty string is represented as either "" (a quoted string with zero characters between double quotes) or as {0} followed by CRLF (a literal with an octet count of 0). Note: Even if the octet count is 0, a client transmitting a literal must wait to receive a command continuation request. 4.3.1 8-bit and Binary Strings IMMP implementations MAY transmit 8-bit or multi-octet characters in literals, but should do so only when the character set is identified. Unencoded binary strings are not permitted. A "binary string" is any string with NUL characters. Implementations MUST encode binary data into a textual form such as BASE64 before transmitting the data. A string with an excessive amount of CTL characters may also be considered to be binary, although this is not required. 5 Operational Considerations 5.1 SubInbox Naming The interpretation of SubInbox names is implementation-dependent. However, the mailbox name INBOX is a special name reserved to mean "the primary mailbox for this user on this server". Using IMMP protocol can create SubInboxes inside the Inbox in tree model where the Inbox is the root. We can directly send mail into the SubInboxes but we need to specify it in the To-Address of a mail so that the destination Receiver-SMTP works together with IMMP and maps the mail data into the corresponding SubInbox of Inbox. Sabarish [Page 9] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 For Example: 1) Mail sends to sabarish@immp.pro store the mail data into INBOX of Sabarish. 2) Mail sends to work/sabarish@immp.pro store the mail data into SubInbox "Work" inside the INBOX of Sabarish. 3) Mail sends to office/work/sabarish@immp.pro store the mail data into the SubInbox "office" inside the SubInbox "Work". 5.2 Untagged Status Updates At any time, a server can send data that the client did not request. 5.3 Response when no Command in Progress Server implementations are permitted to send an untagged response while there is no command in progress. Server implementations that send such responses MUST deal with flow control considerations. Specifically, they must either (1) verify that the size of the data does not exceed the underlying transport's available window size, or (2) use non-blocking writes. 5.4 Autologout Timer If a server has an inactivity autologout timer, that timer MUST be of at least 30 minutes' duration. The receipt of ANY command from the client during that interval should suffice to reset the autologout timer. 5.5 Multiple Commands in Progress The client is not required to wait for the completion result response of a command before sending another command, subject to flow control constraints on the underlying data stream. Similarly, a server is not required to process a command to completion before beginning processing of the next command, unless an ambiguity would result because of a command that would affect the results of other commands. If there is such an ambiguity, the server executes commands to completion in the order given by the client. Sabarish [Page 10] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 5.6 Mail Access Protocol Fallback When a client is directed by a user or an initial configuration to contact a SubInbox service on a given host, it should first attempt to reach the IMMP service on that host. The client should then use the IMMP SubInbox management commands instead of the Mail Access protocol (IMAP4, etc) mailbox management commands. If the connection to the IMMP server fails with a refused connection, the client should fall back to using the Mail Access protocol. 6 Commands 6.1 Client Commands - Any State The following commands are valid in any state: CAPABILITY, NOOP, and LOGOUT. 6.1.1 CAPABILITY Command Arguments: none Data: mandatory untagged response: CAPABILITY Result: OK - capability completed BAD - command unknown or arguments invalid The CAPABILITY command requests a listing of capabilities that the server supports. This listing of capabilities is not dependent upon connection state or user. It is therefore not necessary to issue a CAPABILITY command more than once in a session. Capability names refer to extensions, revisions, or amendments to this specification. No capabilities are enabled without explicit client action to invoke the capability. Example: IC: A001 CAPABILITY IS: * CAPABILITY IS: A001 OK CAPABILITY completed Sabarish [Page 11] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 6.1.2 NOOP Command Arguments: none Data: no specific data for this command (but see below) Result: OK - noop completed BAD - command unknown or arguments invalid The NOOP command always succeeds. It does nothing. Since any command can return a status update as untagged data, the NOOP command can be used as a periodic poll for status updates during a period of inactivity. The NOOP command can also be used to reset any inactivity autologout timer on the server. Example: IC: A002 NOOP IS: A002 OK NOOP completed 6.1.3 LOGOUT Command Arguments: none Data: mandatory untagged response: BYE Result: OK - logout completed BAD - command unknown or arguments invalid The LOGOUT command informs the server that the client is done with the session. The server must send a BYE untagged response before the (tagged) OK response, and then close the network connection. Example: IC: A003 LOGOUT IS: * BYE IMMP Server logging out IS: A003 OK LOGOUT completed (Server and client then close the connection) 6.2 Client Commands - Non-Authenticated State In non-authenticated state, the AUTHENTICATE or LOGIN command establishes authentication and enter authenticated state. The AUTHENTICATE command provides a general mechanism for a variety of authentication techniques, whereas the LOGIN command uses the traditional user name and plaintext password pair. Sabarish [Page 12] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 Server implementations may allow non-authenticated access to certain information. The convention is to use a LOGIN command with the userid "anonymous". A password is required. It is implementation - dependent what requirements, if any, are placed on the password and what access restrictions are placed on anonymous users. Once authenticated (including as anonymous), it is not possible to re-enter non-authenticated state. In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), the following commands are valid in non-authenticated state: AUTHENTICATE and LOGIN. 6.2.1 AUTHENTICATE Command Arguments: authentication mechanism name Data: continuation data may be requested Result: OK - authenticate completed, now in authenticated state NO - authenticate failure: unsupported authentication mechanism, credentials rejected BAD - command unknown or arguments invalid, authentication exchange cancelled The AUTHENTICATE command indicates an authentication mechanism, such as described in [IMAP-AUTH], to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the user. Optionally, it also negotiates a protection mechanism for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server should reject the AUTHENTICATE command by sending a tagged NO response. The authentication protocol exchange consists of a series of server challenges and client answers that are specific to the authentication mechanism. A server challenge consists of a command continuation request response with the "+" token followed by a BASE64 encoded string. The client answer consists of a line consisting of a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it should issue a line with a single "*". If the server receives such an answer, it must reject the AUTHENTICATE command by sending a tagged BAD response. Sabarish [Page 13] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 A protection mechanism provides integrity and privacy protection to the protocol session. If a protection mechanism is negotiated, it is applied to all subsequent data sent over the connection. The protection mechanism takes effect immediately following the CRLF that concludes the authentication exchange for the client, and the CRLF of the tagged OK response for the server. Once the protection mechanism is in effect, the stream of command and response octets is processed into buffers of ciphertext. Each buffer is transferred over the connection as a stream of octets prepended with a four octet field in network byte order that represents the length of the following data. The maximum ciphertext buffer length is defined by the protection mechanism. The server is not required to support any particular authentication mechanism, nor are authentication mechanisms required to support any protection mechanisms. If an AUTHENTICATE command fails with a NO response, the client may try another authentication mechanism by issuing another AUTHENTICATE command, or may attempt to authenticate by using the LOGIN command. In other words, the client may request authentication types in decreasing order of preference, with the LOGIN command as a last resort. Example: IS: * OK KerberosV4 IMMP Server IC: A004 AUTHENTICATE KERBEROS_V4 IS: + AmFYig== IC: BAcAQU5EUkVXLfhASHFRFUAOCAsho84kLN3/IJmrMG+25a4DT +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh IS: + or//EoAADZI= IC: DiAF5A4gA+oOIALuBkAAmw== IS: A004 OK Kerberos V4 authentication successful Note: the line breaks in the first client answer are for editorial clarity and are not in real authenticators. 6.2.2 LOGIN Command Arguments: user name password Data: no specific data for this command Result: OK - login completed, now in authenticated state NO - login failure: user name or password rejected BAD - command unknown or arguments invalid Sabarish [Page 14] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 The LOGIN command identifies the user to the server and carries the plaintext password authenticating this user. Example: IC: A005 LOGIN SABARISH RAMAN IS: A005 OK LOGIN completed 6.3 Client Commands - SubInbox management This section describes commands permitted in authenticated state for manipulating SubInboxes as atomic entities. 6.3.1 CREATE Command Arguments: subinbox name Data: no specific data for this command Result: OK - create completed NO - create failure: can't create subinbox with that name,can't create subinbox on that subinbox path which specified along the name BAD - command unknown or arguments invalid The CREATE command creates a subinbox with the given name in INBOX. An OK response is returned only if a new subinbox with that name has been created. It is an error to attempt to create INBOX or a subinbox with a name that refers to an existing subinbox inside the same parent subinbox. Any error in creation will return a tagged NO response. If the subinbox name is suffixed with the server's hierarchy separator character (as returned from the server by a LIST command), this is a declaration that the client may, in the future, create subinbox names under this name in the hierarchy. Server implementations that do not require this declaration MUST ignore it and return a tagged OK response. Example: IC: A006 CREATE work/ IS: A006 OK CREATE completed IC: A007 CREATE office/work IS: A007 OK CREATE completed Sabarish [Page 15] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 Note: the interpretation of the above commands in this example depends on whether "/" was returned as the hierarchy separator from LIST. If "/" is the hierarchy separator, then a new level of hierarchy named "work" with a member called "office" is created. Otherwise, two subinbox at the same hierarchy level are created. 6.3.2 DELETE Command Arguments: subinbox name Data: no specific data for this command Result: OK - delete completed NO - delete failure: can't delete subinbox with that name BAD - command unknown or arguments invalid The DELETE command permanently removes the subinbox with the given name. An OK response is returned only if the subinbox has been deleted. It is an error to attempt to delete INBOX or a subinbox name that does not exist. Any error in deletion will return a tagged NO response. Example: IC: A008 DELETE work IS: A008 OK DELETE completed 6.3.3 RENAME Command Arguments: existing subinbox name new subinbox name Data: no specific data for this command Result: OK - rename completed NO - rename failure: can't rename subinbox with that name can't rename to subinbox with that name BAD - command unknown or arguments invalid The RENAME command changes the name of a subinbox. An OK response is returned only if the subinbox has been renamed. It is an error to attempt to rename from a subinbox name that does not exist or to a subinbox name that already exists in the parent subinbox. Any error in renaming will return a tagged NO response. Sabarish [Page 16] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 Renaming INBOX is permitted; a new, empty INBOX is created in its place. Example: IC: A009 RENAME worksabari offsabari IS: A009 OK RENAME completed 6.3.4 REPLACE Command Arguments: existing subinbox name existing new subinbox name Data: no specific data for this command Result: OK - replace completed NO - replace failure: can't delete subinbox with that name, can't replace with subinbox with that name BAD - command unknown or arguments invalid The REPLACE command deletes a subinbox, automatically changing subscriptions to a new subinbox. An OK response is returned only if the subinbox has been removed. It is an error to attempt to replace a subinbox name that does not exist or replace with a subinbox name that does not exist. Any error in deletion will return a NO response. Replacing INBOX is not permitted. Example: IC: A010 REPLACE worksabari offsabari IS: A010 OK REPLACE completed 6.3.5 MOVE Command Arguments: subinbox name partition parenthesized list Data: no specific data for this command Result: OK - move completed NO - move failure: can't move subinbox with that name can't move subinbox to that server/partition BAD - command unknown or arguments invalid Sabarish [Page 17] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 The MOVE command moves a subinbox between subinboxes, moves a subinbox between two subinboxes. The partition parenthesized list specifies where the subinbox is to be moved to. The interpretation of the partition parenthesized list is the same as for the CREATE command. Example: IC: A011 MOVE SABARISUBINBOX (oldpath, newpath ) IS: A011 OK MOVE completed 6.3.6 LIST Command Arguments: reference name subinbox name with possible wildcards Data: untagged responses: LIST Result: OK - list completed NO - list failure: can't list that reference or name BAD - command unknown or arguments invalid The LIST command returns a subset of names from the complete set of all subinboxes inside the inbox. Zero or more untagged LIST replies are returned, containing the name hierarchy delimiter and name; see the description of the LIST reply for more detail. An empty ("" string) reference name argument indicates that the subinbox name is interpreted as by SELECT. The returned subinbox names MUST match the supplied subinbox name pattern. A non-empty reference name argument is the name of a subinbox or a level of subinbox hierarchy. The reference and subinbox name arguments are interpreted, in an implementation-dependent fashion, into a canonical form that represents an unambiguous left-to-right hierarchy. The returned subinbox names will be in the interpreted form. Any part of the reference argument that is included in the interpreted form SHOULD prefix the interpreted form. It should also be in the same form as the reference name argument. This rule permits the client to determine if the returned subinbox name is in the context of the reference argument, or if something about the subinbox argument overrode the reference argument. Without this rule, the client would have to have knowledge of the server's naming semantics including what characters are "breakouts" that override a naming context. Sabarish [Page 18] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 For example, here are some examples of how references and subinbox names might be interpreted on a UNIX-based server: Reference Subinbox Name Interpretation ------------ ------------ -------------- inbox/Mail/ foo.* inbox/Mail/foo.* inbox/ % inbox/% The character "*" is a wildcard, and matches zero or more characters at this position. The character "%" is similar to "*", but it does not match a hierarchy delimiter. Example: IC: A012 LIST "inbox/Mail/" "%" IS: * LIST (\Noselect) "/" inbox/Mail/foo IS: * LIST () "/" inbox/Mail/meetings IS: A012 OK LIST completed 6.4 Client Commands - Spam Guard Agent This section describes commands permitted in authenticated state for manipulating Spam Guard Agent. Spam Guard Agent provides a way for users to store list of spam mail addresses and blocked the mail when the SMTP server is getting mails from those spam mail addresses with the help of IMMP. Servers are expected to at least allow the client to manipulate the spam guard agent with the same name as the "user" specified in the LOGIN command. Servers allow client to create any number of spam guard agents and IMMP check the incoming mails with all the information in the spam guard agents assigned to that user. Each spam guard agent contains some number of spam mail addresses. The standard field is: EMAIL electronic mail address Sabarish [Page 19] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 6.4.1 SEARCHSPAMENTRY Command Arguments: spam guard agent name lookup criteria Data: untagged responses: SEARCHSPAMENTRY Result: OK - searchspamentry completed NO - searchspamentry failure: can't searchspamentry that name BAD - command unknown or arguments invalid The SEARCHSPAMENTRY command searches the specified spam guard agent for mail address that express the intersection (AND function) of all of the specified criteria. The names matching the criteria are returned in some set of untagged SEARCHSPAMENTRY replies. If no criteria are specified, all mail addresses in the spam guard agent are returned. Wildcards are permitted in the pattern as in LIST, except that the behavior of the "%" wildcard is undefined. The reserved field "mail" specifies entries whose mail addresses matches the specified pattern. Example: IC: A013 SEARCHSPAMENTRY Sabarish Email "*Rubble" IS: * SEARCHSPAMENTRY "*Rubble" IS: A013 OK SEARCHSPAMENTRY completed 6.4.2 STORESPAMENTRY Command Arguments: spam guard agent name Email Data: no specific data for this command Result: OK - storespamentry completed NO - storespamentry failure: can't storespamentry that name BAD - command unknown or arguments invalid Store the spam entry in the specified spam guard agent. Here the spam entry is a mailing address. For creating a new entry, directly use this storespamentry. For editing the spam entry, delete the spam entry and store the new one. Sabarish [Page 20] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 Entry names are case-insensitive strings. Example: IC: A014 STORESPAMENTRY SabariGuard "mail@immp.pro" IS: A014 OK STORESPAMENTRY completed 6.4.3 DELETESPAMENTRY Command Arguments: spam guard agent name Email Data: no specific data for this command Result: OK - deletespamentry completed NO - deletespamentry failure: can't deletespamentry that name BAD - command unknown or arguments invalid Remove the spam entry in the specified spam guard agent for the specified Email. Example: IC: A015 DELETESPAMENTRY SabariGuard "mail@immp.pro" IS: A015 OK DELETESPAMENTRY completed 6.4.4 SEARCHSPAMGUARDAGENT Command Arguments: lookup criteria Data: untagged responses: SEARCHSPAMGUARDAGENT Result: OK - searchspamguardagent completed NO - searchspamguardagent failure: can't searchspamguardagent that name BAD - command unknown or arguments invalid The SEARCHSPAMGUARDAGENT command searches for the specified spam guard assigned for the login user. The names matching the criteria are returned in some set of untagged SEARCHSPAMGUARDAGENT replies. If no criteria are specified, all spam guard agents are returned. Wildcards are permitted in the pattern as in LIST, except that the behavior of the "%" wildcard is undefined. The reserved field "mail" specifies entries whose mail addresses matches the specified pattern. Example: IC: A016 SEARCHSPAMGUARDAGENT "*RubbleAgent" IS: * SEARCHSPAMGUARDAGENT "*RubbleAgent" IS: A016 OK SEARCHSPAMGUARDAGENT completed Sabarish [Page 21] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 6.4.5 STORESPAMGUARDAGENT Command Arguments: spam guard agent name Data: no specific data for this command Result: OK - storespamguardagent completed NO - storespamguardagent failure: can't storespamguardagent that name BAD - command unknown or arguments invalid Store the spam guard agent and assigned for the login user. For creating a new guard, directly use this storespamguardagent. For editing the spam guard agent, delete the spam guard agent and store the new one. Spam guard agent names are case-insensitive strings. Example: IC: A017 STORESPAMGUARDAGENT SabariGuard IS: A017 OK STORESPAMGUARDAGENT completed 6.4.6 DELETESPAMGUARDAGENT Command Arguments: spam guard agent name Data: no specific data for this command Result: OK - deletespamguardagent completed NO - deletespamguardagent failure: can't deletespamguardagent that name BAD - command unknown or arguments invalid Remove the spam guard agent for the login user. Example: IC: A018 DELETESPAMENTRY SabariGuard "mail@immp.pro" IS: A018 OK DELETESPAMENTRY completed 6.5 Client Commands - Anonymous Query Commands This section describes commands permitted in anonymous state for querying IMMP server to check whether a particular subinbox is available for that mail address and also check whether that incoming mail address is blocked by the spam guard agent of the IMMP server. Mostly mail posting protocols (SMTP, etc) use this commands. Sabarish [Page 22] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 6.5.1 VERIFYINSPAMGUARDAGENT Command Arguments: check-mail-address, in-mail-address Data: no specific data for this command Result: OK - not blocked by Spam guard agent. NO - blocked by Spam guard agent BAD - command unknown or arguments invalid Check whether the check-mail-address is blocked by spam guard agents of the user of in-mail-address. Example: RS: VERIFYINSPAMGUARDAGENT "spammail@immp.pro" "mymail@immp.pro" IS: OK VERIFYINSPAMGUARDAGENT completed 6.5.2 VERIFYSUBINBOX Command Arguments: sub-inbox, mail-address Data: no specific data for this command Result: OK - available inside the inbox NO - unavailable inside the inbox BAD - command unknown or arguments invalid Check whether the sub-inbox is available inside the inbox of the mail-address. Example: RS: VERIFYSUBINBOX "office/work" "mymail@immp.pro" IS: OK VERIFYSUBINBOX completed 7 Security Considerations IMMP protocol transactions, including spam guard agent and option data, are sent in the clear over the network unless the optional privacy protection is negotiated in the AUTHENTICATE command. A server error message for an AUTHENTICATE command which fails due to invalid credentials should not detail why the credentials are invalid. Sabarish [Page 23] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 Use of the LOGIN command sends passwords in the clear. This can be avoided by using the AUTHENTICATE command instead. A server error message for a failing LOGIN command should not specify that the user name, as opposed to the password, is invalid. Additional security considerations are discussed in the section discussing the AUTHENTICATE and LOGIN commands. 8 IANA consideration IANA needs to reserve 323 port to this protocol. 9 Informative References [SMTP] Jonathan B. Postel, "SIMPLE MAIL TRANSFER PROTOCOL", RFC 821 [POP3] R. Gellens, "POP3 Extension Mechanism", RFC 2449 [IMAP4] Crispin, Mark R., "Internet Message Access Protocol - Version 4", RFC 1730. [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731 [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522. [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822. 10 Author's Address Sabarish Ramanathan "Sabari Illam", 96 Gangadhara Iyer Street, Karaikudi, Tamil Nadu 630 001 India sabarish@computer.org Sabarish [Page 24] Expires November 2005 Internet Draft IMMP -- Internet Message Mapping Protocol May 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Sabarish [Page 25] Expires November 2005