Internet Draft: IMAP Submit Without Download R. Gellens, Editor Document: draft-ietf-lemonade-submit-00.txt Qualcomm Expires: December 2003 20 June 2003 IMAP Submit Without Download 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 IMAP clients operating over low-bandwidth or high-latency links, such as cellular telephones, need to be able to submit mail messages containing all or part of previously-received IMAP messages. Clients need to be able to do this without sloshing the bits both ways, that is, without being forced to download IMAP messages solely to be able to upload the content in a submitted message. This document currently identifies the two main approaches to doing this (called "IMAP push" and "IMAP pull"), one which adds submission to IMAP, and another which adds the expansion of IMAP references to message submission. This version of the document attempts to lay out the protocol mechanisms along with associated trade-offs and security considerations of each. Once a decision has been made to Gellens [Page 1] Expires December 2003 Internet Draft IMAP Submit Without Download June 2003 go with a particular technique, this document will describe the specifics of that choice as a standards-track proposal. Gellens [Page 2] Expires December 2003 Internet Draft IMAP Submit Without Download June 2003 Table of Contents 1. Conventions Used in this Document . . . . . . . . . . . . . 3 2. Fundamental Requirement . . . . . . . . . . . . . . . . . . 3 3. Additional Requirements, Goals, Etc: . . . . . . . . . . . . 3 4. "IMAP Push" Versus "IMAP Pull" . . . . . . . . . . . . . . 4 4.1. "IMAP Push" . . . . . . . . . . . . . . . . . . . . . . 4 4.1.1. Overview . . . . . . . . . . . . . . . . . . . . . 4 4.1.2. Unresolved Issues . . . . . . . . . . . . . . . . . 5 4.1.3. Security Considerations . . . . . . . . . . . . . . 6 4.1.4. Advantages . . . . . . . . . . . . . . . . . . . . . 6 4.1.5. Disadvantages . . . . . . . . . . . . . . . . . . . 6 4.2. "IMAP Pull" . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Overview . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Security Considerations . . . . . . . . . . . . . . 8 4.2.3. Advantages . . . . . . . . . . . . . . . . . . . . 8 4.2.4. Disadvantages . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . 10 10. Editor's Address . . . . . . . . . . . . . . . . . . . . . . 10 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. Fundamental Requirement The fundamental requirement is to allow [IMAP] clients (especially those on low-bandwidth or high-latency links) to submit messages containing all or part of received messages without having to slosh all the bits both ways (that is, without needing to download the content of received messages or parts thereof just to be able to upload it within a submitted message). Gellens [Page 3] Expires December 2003 Internet Draft IMAP Submit Without Download June 2003 3. Additional Requirements, Goals, Etc: Being able to store the sent message on the IMAP server is a goal. 4. "IMAP Push" Versus "IMAP Pull" Two main approaches have been proposed. We can call these "IMAP push" and "IMAP pull", since in one case the content is "pushed" from the IMAP server to the [message submission] server, while in the other case the content is "pulled" from the IMAP server by the submit server. 4.1. "IMAP Push" 4.1.1. Overview In the "IMAP push" model, the client creates a skeleton, or template, for a message it desires to submit. This can include references to previously-received IMAP messages or portions thereof. All other aspects of the message (such as headers, new content and in-line quoted text) appear in the skeleton, or template, as they are to appear in the message that is actually sent. The client APPENDs this message in a mailbox on the IMAP server, marking it as a draft or template (skeleton) in some manner (perhaps a flag or annotation). At some point, the client instructs the IMAP server to submit the message. The IMAP server then connects to the submit server, sends the appropriate commands, and then (because it is indicated as a skeleton or template) sends the message template one body part at a time. If it encounters a part which has any content-type other than message/external-body, it sends it (including its headers) as-is. If the IMAP server finds a body part with a content-type of message/external-body with an access-type of URL which points to a message body on the IMAP server, it sends the encapsulated headers of the message/external-body (not including those headers specific to the content-type) followed by the contents of the IMAP message body indicated by the external-body (which may be part of an IMAP message). Gellens [Page 4] Expires December 2003 Internet Draft IMAP Submit Without Download June 2003 The IMAP server does not need to examine the contents of the body parts it is retrieving from elsewhere in the IMAP store; it fetches them normally, redirecting the output to the submit server rather than to the requesting client. The IMAP server does not recurse through the referenced body parts looking for more external-body parts. The client MUST set an appropriate content-transfer-encoding for each embedded part. 4.1.2. Unresolved Issues Deletion of referenced data before expansion is a concern, although one that could be ignored, as it would be a result of client action (a timing hole exists with any solution, although it is larger or smaller in some models). A number of variances are possible. These include how the envelope information (including return-path, recipients and extensions) is indicated; the precise mechanism for references to IMAP messages or portions, including how such mechanism interacts with [mailbox referrals], and if the mechanism requires that all referenced data exist on the same IMAP server doing the submission; if the final submission completes synchronously or synchronously or if this is an option; how errors during the submission process are to be handled. One approach to the envelope issue would be for the client to store the complete desired submission envelope in a message annotation per the [annotate] extension. Another is to simply include this in the IMAP command which submits the message. In either case, the desired envelope can be sent by the client as a literal, or can be integrated into IMAP. The former has the advantage of tying IMAP submission directly to [message submission], thus guaranteeing that all current and future submit extensions are valid within the IMAP submit mechanism. This avoids potentially creating two parallel but separate message submission mechanisms, one for IMAP clients and one for all other clients (including POP and submit-only). The latter has the advantage of providing a clear way to inform the client of the submission extensions supported by the server. A promising mechanism for referring to IMAP messages or parts thereof is to use a message/external-body part with a [URL access-type] (in this case an IMAP URL) for each such reference. A parameter can be specified within the content-type indicating that the body part is to be expanded on submission (or even on storage, which could help reduce the timing window during which referenced messages can be expunged). Alternatively, message/external body parts referring to the local message store could be automatically expanded on submission. Gellens [Page 5] Expires December 2003 Internet Draft IMAP Submit Without Download June 2003 4.1.3. 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. 4.1.4. Advantages * Avoids requiring Submit server to understand MIME. * The IMAP server already stores the messages which are referenced, and hence can get at them conveniently. * The IMAP server can easily store the sent message in the user's Outbox or Sent Mail folder, where they are immediately available (there is the potential for delay in the "IMAP pull" model). * Messages can remain in a "sendable but not queued" state, where they are complete but not eligible to be submitted, for any desired period of time, where they can be edited or deleted. 4.1.5. Disadvantages * Only external-body references to messages on the IMAP server can be expanded. * Adds message submission to IMAP, with the potential for two separate submission mechanisms 4.2. "IMAP Pull" 4.2.1. Overview In the "IMAP pull" model, the client connects to a [message submission] server and submits a message. This message may contain message/external-body parts which the client requests the server to expand. This allows arbitrary content to be incorporated into messages without first downloading by client. One possible solution for storing copies of sent mail in the IMAP server would be to standardize an IMAP mailbox annotation using [annotate] which contains an e-mail address that posts directly to the mailbox. (This would also be desirable for shared mailboxes.) Gellens [Page 6] Expires December 2003 Internet Draft IMAP Submit Without Download June 2003 Several techniques are possible for the client to indicate to the submit server that the message contains references to be expanded. One approach is to layer it on the CHUNKING extension to SMTP added by [binary SMTP]. The CHUNKING extension allows submission of a series of byte-counted message fragments using the "BDAT" command. The submission extension would add a "BURL" command that could be interleaved with the "BDAT" commands. This allows the message to be composed without any sort of hokey post-processing. For example, a message could be submitted as follows: BDAT .... headers and first part BURL 8bit forwarded 8bit content from IMAP BDAT .... MIME delimiters or whatever BURL base64 get IMAP content, base64 encode and include it BDAT .... final data Potentially, this could be pipeline-able into one round-trip. However, the error cases involved need to be examined in more detail. For example, if the submit server gets an error while dereferencing a URL, does this get passed to the client immediately (assuming synchronous dereferencing), or are errors reported at the end or subsequently? The BURL extension should advertise what types of URLs it supports (the initial focus should of course be for IMAP; additional URL types can be considered later) and which hosts trust it. For example: 250-BURL imap://trusted-host.example.com/ The URL token mechanism provides authorization for the posseser of the token to access one specific piece of data. The submit server could use the SASL ANONYMOUS mechanism (or equivalent), and then use one or more tokens to authorize access to one or more messages or message parts. The limited-use URL could be generated by the server upon request, or by the client using data included in the IMAP server's CAPABILITY response. Server-generated URLs could be done by defining a "GENURL" command which turns a message or body-part reference within the selected mailbox into an extended IMAP URL with an authorization token. This could have a time-limit or a number of uses limit. The authorization token would likely be an HMAC-MD5 covering the URL, a nonce, a time-limit and using a per-user random secret known only to the IMAP server. Gellens [Page 7] Expires December 2003 Internet Draft IMAP Submit Without Download June 2003 The limited-use URL would be used by defining a "GETURL" command which is accessible by any IMAP user (including anonymous) which returns a literal of the relevant message/body part if the authorization token is valid. 4.2.2. Security Considerations This method requires either that the IMAP server trusts the submit server or that a mechanism be specified by which the IMAP client or server constructs a URL which authorizes access to specific limited content (this URL could expire after some amount of time or uses and/or be usable only by the submit server). If the IMAP server trusts the submit server, the IMAP server can include in its CAPABILITIES response a list of such trusted submission servers. Or, the submit server can indicate which IMAP servers trust it. Note that the primary target for forward-without-download is email on cell phones, where the carrier will operate both the IMAP and submit server and there is thus a pre-existing trust relationship between these servers. Also note that plain text passwords (with or without TLS) are in widespread use (indeed are dominant) for authentication. Authenticating to the submit server may thus disclose authentication credentials sufficient to grant the submit server access to the user's IMAP account. The URI-based token mechanism described here poses a potentially serious problem for channels which are not secure (secure channels are not required by [message submission] or [SMTP]). Given a compromise there, an attacker could anticipate the download of a body part by dereferencing the URI before the submit server (by taking a second or third BURL-reference, for example, to win the race condition). This both compromises the body part and potentially creates a denial of service for the message being sent (assuming that the access methods cause the retrieved resource to be unavailable using the same credentials). Using "one resource" but not "one use" credentials reverts the problem to compromise. 4.2.3. Advantages Gellens [Page 8] Expires December 2003 Internet Draft IMAP Submit Without Download June 2003 * Keeps message submission within [message submission]. * Avoids adding significant new functionality to [IMAP] * Can potentially be expanded to include other types or URIs and additional associated services 4.2.4. Disadvantages * Adds significant new functionality to [message submission] servers * Requires submit server to have access to (at least specific pieces of) IMAP data 5. Security Considerations Security considerations are currently discussed within each of the two main alternatives above. 6. IANA Considerations None identified yet. Stay tuned. 7. Acknowledgements The editor would like to acknowledge that significant contributions to this document were made by several members of the lemonade group, including Mark Crispin, Cyrus Daboo, Larry Greenfield, Ted Hardie, Chris Newman, and Pete Resnick. 8. Normative References [binary SMTP] "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", G. Vaudreuil, December 2000, RFC 3030. [IMAP] "INTERNET MESSAGE ACCESS PROTOCOL -- VERSION 4rev1", M. Crispin, March 2003, RFC 3501. [mailbox referrals] "IMAP4 Mailbox Referrals", M. Gahrns, September 1997, RFC 2193. [message submission] "Message Submission", R. Gellens, J. Klensin, December 1998, RFC 2476. Gellens [Page 9] Expires December 2003 Internet Draft IMAP Submit Without Download June 2003 [URL access-type] "Definition of the URL MIME External-Body Access-Type", N. Freed, K. Moore, A. Cargille, October 1996, RFC 2017. 9. Informative References [SMTP] "Simple Mail Transfer Protocol", J. Klensin, Ed., April 2001, RFC 2821. 10. 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. Gellens [Page 10] Expires December 2003 Internet Draft IMAP Submit Without Download June 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. Gellens [Page 11] Expires December 2003