IMAP Extensions Working Group Madan Ganesh Velayudham Internet Draft: IMAP ORGANIZE Extension Hewlett-Packard Company Expires: April 2004 October 2003 IMAP ORGANIZE Extension draft-madanganeshv-imapext-organize-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at The list of Internet-Draft Shadow Directories can be accessed at . Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The ORGANIZE extension to Internet Message Access Protocol [IMAP4] specifies the mechanism by which the client can inform the server to maintain the entries for the messages to be organized. The organization of messages include appending, moving to a mailbox, deleting messages, or changing the attributes of received messages. This extension enables the lightweight IMAP clients to organize their messages on the server side, rather than performing it on the client side. In addition to the information on the IMAP ORGANIZE extension, this document describes implementation of the ORGANIZE extension for Simple Mail Transfer Protocol [SMTP]. 1. 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]. Madan Ganesh Velayudham Expires April 2004 [Page 1] Internet-Draft IMAP ORGANIZE Extension April 2003 In protocol examples, "C:" designates lines sent by the client, while "S:" show lines sent by the server. In such examples, line breaks are for editorial clarity only. PUOT means that Per User Organizing Table where the server maintains user's organizing rules. PUOE means Per User Organizing Entry, that is each entry in Per User Organizing Table. 2. Requirement The requirement is to allow IMAP clients to inform servers with its organize information, there by server can organize messages according to clients requirements. 3. IMAP Extension This memo defines the following extension to Internet Message Accessible Protocol [IMAP4]. 3.1 CAPABILITY Identification IMAP4 servers that support this extension MUST include an ORGANIZE capability response in the response list to the CAPABILITY command. This entry indicates that the server supports the extension. In addition, it lists the schemes available to the ORGANIZE command. The capability response consists of the string "ORGANIZE=" followed by a list of commands and actions supported by the ORGANIZE extension. * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5 ORGANIZE=ADD,UPDATE [APPEND,DELETE,STORE], REMOVE,ENABLE,DISABLE,LIST 3.2 ORGANIZE Command Arguments: PUOT-command Action-command Responses: REQUIRED untagged response: ORGANIZE Result: OK - PUOT-command completed. NO - organize error: cannot search that [CHARSET], or PUOT-command cannot be completed. BAD - Unknown command or invalid arguments. The ORGANIZE command informs the server to update the client's PUOT information with the provided information. This command is valid in the authenticated state. When the IMAP server receives a mail for a user, it performs the Madan Ganesh Velayudham Expires April 2004 [Page 2] Internet-Draft IMAP ORGANIZE Extension April 2003 specified action for messages that match the enabled search criteria. The format for storing PUOEs is implementation defined. Example, PUOT can be a flat file for each user or any directory services. 3.2.1 PUOT Manipulation commands This specification currently defines the following POUT manipulation commands : 3.2.1.1 ADD search-criteria Adds the search criteria to the PUOT. The ORGANIZE response for this command SHOULD contain the puoe sequence number. 3.2.1.2. UPDATE puoe-seqno search-criteria Searches PUOT for puoe-seqno, If puoe-seqno is found then it updates it with the search-criteria. OPTIONAL [CHARSET] specification searching criteria (one or more) Searching criteria consist of one or more search keys. When multiple keys are specified, the result is the intersection AND function) of all the messages that match those keys. Server implementations MAY exclude [MIME-IMB] body parts with terminal content media types other than TEXT and MESSAGE from consideration in search matching. The OPTIONAL [CHARSET] specification consists of the word "CHARSET" followed by a registered [CHARSET]. It indicates the [CHARSET] of the strings that appear in the search criteria. [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing text in a [CHARSET] other than US-ASCII. US-ASCII MUST be supported; other [CHARSET]s MAY be supported. If the server does not support the specified [CHARSET], it MUST return a tagged NO response (not a BAD). This response SHOULD contain the BADCHARSET response code, which MAY list the [CHARSET]s supported by the server. In all search keys that use strings, a message matches the key if the string is a substring of the field. The matching is case- insensitive. The defined search keys are as follows. Refer to the Formal Syntax section for the precise syntactic definitions of the arguments. ALL BCC BEFORE Madan Ganesh Velayudham Expires April 2004 [Page 3] Internet-Draft IMAP ORGANIZE Extension April 2003 BODY CC FROM HEADER KEYWORD LARGER NOT ON OR SENTBEFORE SENTON SENTSINCE SINCE SMALLER SUBJECT TEXT TO The definitions of above search keys are defined in the 6.4.4 section of [IMAP4]. 3.2.1.3 REMOVE puoe-sequence-set Searches puoe-sequance-set and removes found list of PUOE entries. 3.2.1.4 ENABLE puoe-sequence-set Searches puoe-sequence-set and enables found list of PUOE entries. 3.2.1.5 DISABLE puoe-sequence-set Searches puoe-sequence-set and disables found list of PUOE entries. If a command is unsuccessfull for any reason, server implementation MUST restore the PUOT to its original state before the respective command's execuition. 3.2.1.6 LIST [ puoe-sequence-set ] If puoe-sequence-set is not provided, the LIST command displays all PUOEs from PUOT. Otherwise it displays only puoe-squence-set entries from PUOT. 3.2.2 Action commands The defined actions by this specification are APPEND, DELETE, and STORE actions. Any user-defined action is prepended with Xaction. 3.2.2.1 APPEND ( Refer formal syntax ) Appends the received message to the specified mailbox. This command reuses the definition specified in the 6.3.11 section of [IMAP4]. The descriptions about flag parenthesized list, date/time string applies here. The only difference here is that the message is a new (received) message. The consistency of the destination mailbox Madan Ganesh Velayudham Expires April 2004 [Page 4] Internet-Draft IMAP ORGANIZE Extension April 2003 SHOULD be maintained. 3.2.2.2 DELETE ( Refer formal syntax ) Deletes the received messages permanently. It is similar to setting the \Deleted flag and calling EXPUNGE in a user's INBOX. 3.2.2.3 STORE ( Refer formal syntax ) Alters data associated with the received message in the mailbox. 3.2.2.4 Xaction ( Refer formal syntax ) Any action prefixed with an X is an experimental command. Commands which are not part of this specification, a standard or standards- track revision of this specification, or an IESG-approved experimental protocol, MUST use the X prefix. Refer to the 3.3 section for ORGANIZE response. Server Implementation of this specification in IMAP simplifies the manipulation of incoming messages on the server side. Example: C: A282 ORGANIZE ADD FROM "spammer" ACTION=DELETE S: A282 OK ORGANIZE completed C: A283 ORGANIZE UPDATE 2 TEXT "string not in mailbox" ACTION=APPEND mbox S: A283 OK ORGANIZE completed C: A284 ORGANIZE ADD CHARSET UTF-8 TEXT {6} ACTIONS=STORE +Flags (\Deleted) S: A284 OK ORGANIZE completed C: A285 ORGANIZE ENABLE 2 S: A285 OK ORGANIZE completed C: A285 ORGANIZE DELETE 2 S: A285 OK ORGANIZE completed 3.3 ORGANIZE Response Contents: Unilateral response : puoe-seq-number action ADD : none DELETE : none LIST : zero or more PUOE from PUOT The ORGANIZE response occurs in following cases: Madan Ganesh Velayudham Expires April 2004 [Page 5] Internet-Draft IMAP ORGANIZE Extension April 2003 1. When the server matches a search criteria for the received message, That is a unilateral server decision. Here puoe-seq-number represents the sequence number that matches in PUOT, and the action represents whether the message is deleted, appended, or stored. Example : S: * ORGANIZE 4 Deleted S: * ORGANIZE 3 Appended to smteam S: * ORGANIZE 3 Marked FLAGS \Deleted The client may use this response for logging purpose. 2. When one of the following PUOT manipulation commands is executed: ADD: After adding a search criteria to the PUOT, the server implementation SHOULD return a unique puoe sequence number, That is the previous puoe sequence number is incremented by 1. Example : S: * 10 ORGANIZE The update from the ADD response should be recorded by the client. LIST: The response to the LIST manipulation command SHOULD contain the puoe number, the search criteria, and the action to be performed. The content of search criteria and corresponding action SHOULD be simple and clear to users. Example : S: * ORGANIZE 1 FROM "spammer" DELETE * 2 TEXT "not in the string " APPEND mbox * 3 CHARSET UTF-8 TEXT {6} STORE +Flags (\Deleted) DELETE: This resposne message reports that the specified PUOE is permanently removed from the PUOT. The PUOE sequence number for each successive puoe in the PUOT is immediately decremented by 1. This decremented value is reflected in PUOE sequence numbers in the subsequent untagged LIST responses. Example Madan Ganesh Velayudham Expires April 2004 [Page 6] Internet-Draft IMAP ORGANIZE Extension April 2003 S: * 2 ORGANIZE The update from the DELETE response should be recorded by the client. 3.4 Formal Syntax The following syntax specification uses the Augmented Backnus-Naur Form (ABNF) notation as specified in [ABNF]. This syntax reuses the appropriate formal syntax defined in the 9 section of [IMAP4]. tag ORGANIZE put-command SP "ACTION=" organize-command put-command = put-update-command / put-control-command put-update-command = ( "ADD" / "UPDATE" SP seq-number ) [SP "CHARSET" SP astring] 1*(SP search-key) ; Here seq-number means PUOE number. put-control-command = ( ( "ENABLE" / "DISABLE" / "REMOVE" ) SP sequence-set ) / "LIST" [ sequence-set ] ) ; Here sequence-set describes PUOE set instead of message sequence number. search-key = "ALL" / "BCC" SP astring / "BEFORE" SP date / "BODY" SP astring / "CC" SP astring / "FROM" SP astring / "KEYWORD" SP flag-keyword / "ON" SP date / "SINCE" SP date / "SUBJECT" SP astring / "TEXT" SP astring / "TO" SP astring / "HEADER" SP header-fld-name SP astring / "LARGER" SP number / "NOT" SP search-key / "OR" SP search-key SP search-key / "SENTBEFORE" SP date / "SENTON" SP date / "SENTSINCE" SP date / "SMALLER" SP number / "UID" SP sequence-set / "UNDRAFT" / "(" search-key *(SP search-key) ")" organize-command = organize-append / organize-delete / organize-store / organize-x-action organize-append = "APPEND" SP mailbox [SP flag-list] [SP date-time] organize-delete = "DELETE" organize-store = "STORE" SP store-att-flags organize-x-action = "X" atom 3.5 Security Considerations The per user organization of information should have proper ACL Madan Ganesh Velayudham Expires April 2004 [Page 7] Internet-Draft IMAP ORGANIZE Extension April 2003 entries to protect it from non-authorized users. This draft does not introduce any security problems. 4. ORGANIZE in SMTP : This section provides brief information on implementing the ORGANIZE extension in the SMTP server side. This introduces ORGANIZE extension to [SMTP]. The EHLO command should announce the support of the ORGANIZE extension. The server implementation uses the extended MAIL FROM: and RCPT TO: commands and an empty DATA to store PUOE in the PUOT. Example: C:EHLO mydomain S: 220 ...... S: 250.....pleased to meet you S:250-EXPN S:250-VERB S:250-8BITMIME S:250-SIZE S:250-DSN S:250-ONEX S:250-ETRN S:250-XUSR S:250 HELP S:250 ORGANIZE C:MAIL FROM: ORGANIZE S:250 Sender Ok C:RCPT TO: ORGANIZE=REJECT S:250 Organize Recipient Ok C:RCPT TO: ORGANIZE=ACCEPT S:250 Organize Recipient Ok C:DATA S:354 Enter mail, end with "." on a line by itself C:. S:XXXXX Message accepted for delivery When the server receives the extended MAIL FROM: ORGANIZE command, it recognizes that it is a special update request to PUOT. It updates PUOT of the user for the list of RCPTs. However, this approach could introduce denial of service. In that case, the server implementation could use SMTP AUTH: extension to authorize clients. This section only captures the logic of implementation. Appendices A. References The following documents contain definitions or specifications that are necessary to understand this document properly: [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Madan Ganesh Velayudham Expires April 2004 [Page 8] Internet-Draft IMAP ORGANIZE Extension April 2003 [CHARSET] Freed, N. and J. Postel, "IANA Character Set Registration Procedures", RFC 2978, October 2000. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003 [MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,November 1996. [MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", STD 10, RFC 2821, April 2001. 8. Author's Address Madan Ganesh Velayudham Hewlett-Packard, 29, Cunningham road, Bangalore, India 560052 madan-ganesh.v@hp.com +91-80-205-3108 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Madan Ganesh Velayudham Expires April 2004 [Page 9] Internet-Draft IMAP ORGANIZE Extension April 2003 Full Copyright Statement Copyright (C) The Internet Society 2003. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Madan Ganesh Velayudham Expires April 2004 [Page 10]