Internet Draft: IMAP Message Submission R. Gellens, Editor Document: draft-gellens-lemonade-push-00.txt Qualcomm Expires: June 2004 December 2003 IMAP Message Submission 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 This document describes an IMAP protocol extension allowing clients to submit new messages using IMAP. This is the so-called "IMAP Push" approach currently being considered by the lemonade working group as one solution to the "forward without download" problem (that is, as a means for clients to send new messages consisting of or containing all or parts of previously received messages without having to download and upload the data). This proposal relies on additional IMAP extensions, including CATENATE and Annotations. The IMAP extension described here requires that the message to be submitted be already composed and ready to go at the time of submission. Gellens [Page 1] Expires June 2004 Internet Draft IMAP Message Submission December 2003 Table of Contents 1. Conventions Used in this Document . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 3. Concept of Operation . . . . . . . . . . . . . . . . . . . . 2 4. SUBMIT Extension . . . . . . . . . . . . . . . . . . . . . 3 4.1 SUBMIT Command . . . . . . . . . . . . . . . . . . . . . 3 4.2 UID SUBMIT . . . . . . . . . . . . . . . . . . . . . . . 5 4.3 SUBMIT Response . . . . . . . . . . . . . . . . . . . . . 5 5. Required SMTP/Submit Extensions . . . . . . . . . . . . . . 5 6. Annotations . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. SMTP/Submit Extension Discovery . . . . . . . . . . . . 6 6.2. Message Envelope and Status . . . . . . . . . . . . . . 6 6.2.1. Security Considerations . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 10. Informative References . . . . . . . . . . . . . . . . . . 9 11. Editor's Address . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property Statement . . . . . . . . . . . . . . . 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 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]. 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. 2. Introduction 3. Concept of Operation The client composes the message, presumably using the [CATENATE] extension (although potentially using only APPEND). Annotations are used to specify the desired SMTP/Submit envelope, including MAIL-FROM, RCPT-TO, and any extensions. This creates a draft message in an IMAP mailbox containing headers, body, and envelope. The message status is indicated in an annotation, which will generally be either 'pending' or 'queued' prior to submission. Gellens [Page 2] Expires June 2004 Internet Draft IMAP Message Submission December 2003 When desired, the client uses the SUBMIT or UID SUBMIT command as specified here. This causes the message to be submitted to the message submission server for processing. The status of the message is returned as a response, and is also indicated in the message annotation. The SUBMIT extension can require that the submit server used by the IMAP server support certain extensions. Currently, only the [DSN] extension is required. The client can learn which extensions are supported by the submit server by fetching a server annotation (using [ANNOTATEMORE]). The IMAP server can either dynamically obtain the supported extensions when this annotation is accessed, or, if the IMAP and submit servers are integrated, can cache or obtain this information internally. If one or more recipients are rejected by the submit server, the IMAP server either aborts the message submission or continues. By default it aborts, but the client can optionally instruct the server to continue. If one or more recipients failed, the client can use CATENATE to create a new draft which identical to the failed draft except for the corrected recipient information (both message header and RCPT-TO annotation) and can then resubmit the new message. If the rejected recipient is not disclosed in the header, the client can instead correct the recipient in the RCPT-TO annotation in the original message and resubmit the corrected draft. NOTE: the requirement for and use of annotations could be avoided by having the SMTP/submit envelope be passed as a literal in the SUBMIT command, but this has a number of disadvantages. It severs the linkage between the draft message and the envelope, requiring the client to maintain the envelope in local storage, and prevents the message from being prepared for submission by one client and submitted by another. It also requires DSNs to learn the status of failed recipients if the client disconnects before receiving the response to the SUBMIT command. 4. SUBMIT Extension The SUBMIT extension is advertised by "SUBMIT" in the CAPABILITY response. Gellens [Page 3] Expires June 2004 Internet Draft IMAP Message Submission December 2003 4.1 SUBMIT Command Arguments: message sequence number OPTIONAL "NOABORT" Responses: untagged responses: SUBMIT Result: OK - submit completed: if "NOABORT" was specified, then all recipients were accepted by the submit server; otherwise at least one recipient was accepted NO - submit error: submit server rejected some (unless "NOABORT" specified) or all recipients; the submit server rejected one or more extensions; the submit server rejected the message for some other reason. BAD - command not supported or arguments invalid The SUBMIT command is only valid when a mailbox has been selected. The indicated message is submitted to the message submission server. Error responses by the submit server are returned in untagged SUBMIT responses (one per error). If there are no errors, no SUBMIT responses are returned. When the message has been accepted by the submit server, an OK response is sent. If a recipient is rejected, by default the submission is aborted, although the remaining recipients will be checked (the IMAP server continues to send RCPT TO commands, but sends RSET or QUIT instead of DATA). If the optional "NOABORT" option is specified, the submission is not aborted. If an extension or other aspect of the message is rejected, the submission is aborted even if "NOABORT" was specified. If the connection to the client closes, or the client logs out, before the command response had been sent, the server continues processing the command. The client learns the status of the submitted message by the SUBMIT response and the command result. The client can also learn the status by examining the annotation. The annotation allows the client to find out what happened to a message submitted before a disconnect. Note that multiple SUBMIT commands can be pipelined together. Examples: C: a15 SUBMIT 12 S: * SUBMIT "MAIL FROM:" "550 5.7.0 user not authorized to submit (subscription expired)" S: a15 NO not my fault submission rejected by submit server C: a15 SUBMIT 12 S: a15 OK submission accepted by submit server submit.example.com Gellens [Page 4] Expires June 2004 Internet Draft IMAP Message Submission December 2003 C: a15 SUBMIT 12 S: * SUBMIT "RCPT TO:" "550 5.1.1 User unknown" S: * SUBMIT "RCPT TO:" "550 5.1.1 User unknown" S: a15 NO not my fault submission rejected by submit server 4.2 UID SUBMIT This document adds SUBMIT as a valid command to UID. The parameters are the same as for SUBMIT, but instead of a sequence number a unique identifier is used. 4.3 SUBMIT Response Contents: envelope errors The SUBMIT response lists any error responses returned by the submit server to the SMTP/submit commands. Each response contains the SMTP/submit command followed by the response code and text returned by the server. Both the command and the response are strings. Note that multi-line responses are returned as a single string containing the reply minus the CRLFs and repeated response codes, and with line breaks replaced by a single space. Example: S: * SUBMIT "MAIL FROM:" "550 5.7.0 user not authorized to submit (subscription expired)" S: * SUBMIT "RCPT TO:" "550 5.1.1 User unknown" 5. Required SMTP/Submit Extensions Currently, only [DSN] is the only SMTP/submit extension required to be supported. Gellens [Page 5] Expires June 2004 Internet Draft IMAP Message Submission December 2003 6. Annotations 6.1. SMTP/Submit Extension Discovery The "/submit-capabilities" entry is used to access the capabilities supported by the submit server. The IMAP server MUST ensure that the response is accurate when received by the client. This can be done by opening a connection to the submit server to learn the capabilities when the "/submit-capabilities" entry is accessed, or by caching the information with a mechanism to update it when it changes (for example, if the two servers are combined or have other means of communication). Example: C: a GETANNOTATION "" "/submit-capabilities" "value" S: * ANNOTATION "/submit-capabilities" ("value.shared" "(PIPELINING) (8BITMIME) (ENHANCEDSTATUSCODES) (ETRN) (AUTH CRAM-MD5 NTLM PLAIN LOGIN) (AUTH=LOGIN) (SIZE 2147483647)") 6.2. Message Envelope and Status This specification adds the following entry names: /draft-envelope Defines the top-level of annotations containing the SMTP/submit envelope for draft (sent or unsent) messages. /draft-envelope/$state The value of this annotation indicates the draft state: "pending", "queued", "sent", "rejected", or "partially-sent". /draft-envelope/mail-from Holds elements of the mail-from portion of the envelope. /draft-envelope/mail-from/
Is named and contains the address, not including angle brackets, to be sent in the MAIL FROM command. Note that the value of this attribute is identical to its name. Gellens [Page 6] Expires June 2004 Internet Draft IMAP Message Submission December 2003 /draft-envelope/mail-from/
/dsn Contains the DSN extension values to be used with this MAIL FROM. /draft-envelope/mail-from/
/$status Contains the response code and text returned by the submit server to the MAIL FROM command. It is placed under the
sub-entry to be consistent with the handling of RCPT TO entries. This entry has no value until the SUBMIT command is used on this message. If a new SUBMIT command is issued following a previous one, the server must only return the updated status. /draft-envelope/rcpt-to Holds elements of the rcpt-to portions of the envelope. /draft-envelope/rcpt-to/
Is named and contains the address of this recipient. Note that the value of this attribute is identical to its name. /draft-envelope/rcpt-to/
/dsn Contains the DSN extension parameters and values for this recipient. /draft-envelope/rcpt-to/
/$status Contains the response code and text returned by the submit server to this RCPT TO command. This entry has no value until the SUBMIT command is used on this message. If a new SUBMIT command is issued following a previous one, the server must only return the updated status. Note that SMTP/submit extensions are specified as entries under the command being extended. The IMAP server SHOULD process all entries which do not start with "$" under "/draft-envelope/mail-from/
" and "/draft-envelope/rcpt-to/
" as extensions without trying to recognize them. This allows new extensions to be introduced without modifying the IMAP server. Note that new submit command may be defined in the future. Such commands would have their own entries under "/draft-envelope". Since it is conceivable that such commands would be used in place of MAIL FROM or RCPT TO, the IMAP server SHOULD NOT process unrecognized entries under "/draft-envelope" but instead SHOULD return a BAD response to the SUBMIT command. Gellens [Page 7] Expires June 2004 Internet Draft IMAP Message Submission December 2003 Example: C: a FETCH 12 (ANNOTATION ("/draft-envelope/*" "value.priv")) S: * 12 FETCH (ANNOTATION ("/draft-envelope/$state" ("value.priv" "rejected") "/draft-envelope/mail-from/schlmo@example.com" ("value.priv" "schlmo@example.com") "/draft-envelope/mail-from/schlmo@example.com/dsn" ("value.priv" "ENVID 00BADBAD00") "/draft-envelope/mail-from/schlmo@example.com/$status" ("value.priv" "250 2.1.0 sender ok") "/draft-envelope/rcpt-to/b1ff@example.com" ("value.priv" "b1ff@example.com") "/draft-envelope/rcpt-to/b1ff@example.com/dsn" ("value.priv" "NOTIFY=success") "/draft-envelope/rcpt-to/b1ff@example.com/$status" ("value.priv" "550 5.1.1 User unknown"))) 6.2.1. Security Considerations This approach requires that the submit server trust the IMAP server to submit messages on behalf of the end user. In addition, since new functionality is being added to IMAP, including expansion of referenced data, implementation errors have the potential to create vulnerabilities that could compromise the IMAP server, giving access to all of the user's IMAP data, all IMAP data for all users, or root access to the system. 7. IANA Considerations The hard-working IANA staff is kindly requested to add "SUBMIT" to the IMAP4 capabilities registry with a reference to this document. 8. Acknowledgements The editor is grateful for and would like to acknowledge the significant contributions made to this document by several members of the lemonade group, most especially Cyrus Daboo. Gellens [Page 8] Expires June 2004 Internet Draft IMAP Message Submission December 2003 9. Normative References [binary SMTP] "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", G. Vaudreuil, December 2000, RFC 3030. [BURL] Newman, C., "Message Composition", draft-newman-lemonade-compose-xx (work in progress). [DSN] "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", K. Moore, January 2003, RFC 3461 [IMAP] "INTERNET MESSAGE ACCESS PROTOCOL -- VERSION 4rev1", M. Crispin, March 2003, RFC 3501. [message submission] "Message Submission", R. Gellens, J. Klensin, December 1998, RFC 2476. [URL access-type] "Definition of the URL MIME External-Body Access-Type", N. Freed, K. Moore, A. Cargille, October 1996, RFC 2017. [URLAUTH] Crispin, Newman, "Internet Message Access Protocol (IMAP) - URLAUTH Extension", draft-crispin-imap-urlauth-xx (work in progress). 10. Informative References [annotate] Gellens, Daboo, "IMAP ANNOTATE Extension" (work in progress). [ANNOTATEMORE] Daboo, (work in progress). [CATENATE] Resnick, [mailbox referrals] "IMAP4 Mailbox Referrals", M. Gahrns, September 1997, RFC 2193. [SMTP] "Simple Mail Transfer Protocol", J. Klensin, Ed., April 2001, RFC 2821. Gellens [Page 9] Expires June 2004 Internet Draft IMAP Message Submission December 2003 11. Editor's Address Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA randy@qualcomm.com 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 implementors 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. 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 Gellens [Page 10] Expires June 2004 Internet Draft IMAP Message Submission December 2003 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. Gellens [Page 11] Expires June 2004