Lemonade Internet Draft: LDELIVER S. H. Maes Document: draft-maes-lemonade-deliver-00 C. Kuang R. Lima R. Cromwell V. Ha E. Chiu J. Day R. Ahad Oracle Corporation Wook-Hyun Jeong Samsung Electronics Co., LTD Gustaf Rosell Sony Ericsson J. Sini Symbol Technologies Sung-Mu Son LGE Fan Xiaohui Zhao Lijun China Mobile Expires: January 2006 July 2005 LDELIVER Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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. 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." Maes [Page 1] July 2005 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. Abstract LDELIVER is a LEMONADE extension to the IMAP protocol (P-IMAP) defines extensions to the IMAPv4 Rev1 protocol [RFC3501] to enable sending email as an IMAP command. It provides simple ways to provide reply and forward without download with a gateway to the email and submit servers. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocol(s) it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for a protocol is said to be "unconditionally compliant" to that protocol; one that satisfies all the MUST level requirements but not all the SHOULD level requirements is said to be "conditionally compliant." When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. Table of Contents Status of this Memo .......................................... 1 Abstract...................................................... 2 Conventions used in this document............................. 2 Table of Contents............................................. 2 1. Introduction............................................... 3 2. Relation with other E-mail specifications.................. 4 3. Interactions between the Client and Server when supporting LDELIVER...................................................... 4 4. The CAPABILITY Command..................................... 4 5. Specification details...................................... 5 5.1. the LDELIVER command.................................. 5 Maes Expires û January 2006 [Page 2] July 2005 5.2. Content-External-Location, IMAP URL, and Server based attachments................................................ 7 6. Note on LDELIVER, SMTP and Lemonade Profile................ 8 Security Considerations....................................... 8 References.................................................... 9 Future Work...................................................10 TBD.....................................................10 Version History...............................................10 Acknowledgments...............................................10 Authors Addresses.............................................10 Intellectual Property Statement...............................12 Full Copyright Statement......................................13 1. Introduction LDELIVER is a LEMONADE extension to the IMAP protocol (P-IMAP) defines extensions to the IMAPv4 Rev1 protocol [RFC3501] to enable sending email as an IMAP command. This provides simple ways to provide reply and forward without download with a gateway to the email and submit servers. LDELIVER is not intended to replace SMTP [RFC2821]. Instead it is envisaged as a simple way to implement gateways that support features like reply and forward without downloading complete messages whe the email and submit servers may not support the commands described in [LEMONADEPROFILE] to support such capabilities. Of course, LDELIVER also allows reducing the amount of protocols to support on the client, port to use and parameters to set or provisions. All these are important features required in particular to support mobile email use cases [MEMAIL][OMA-ME-RD]: - Forward and reply without download - Ease of provisioning over the air - Ease of manual provisioning - Reduction of resources on the client - Ease of implementation and deployment with existing email and submit server - The server that supports LDELIVER can be used to send email, thus eliminating the need for the client to connect to a separate SMTP server. When forwarding/replying to a message from the client, the end user may choose to reattach the original's message attachments by just specifying the UID of the original message and specifiers for the required bodyparts. The client need not download the attachments of Maes Expires û January 2006 [Page 3] July 2005 the original message itself. This is an expected behavior of a server that supports LDELIVER. The client may also edit portions of these fields and re-compose the edited body parts (addressees, body, attachments) using IMAP URL [RFC2192] and a MIME header proposal, Content-External-Location which accomplishes the same functionality as Lemonade CATENATE/BURL [BURL] proposals. 2. Relation with other E-mail specifications LDELIVER can be seen as a command that allows optimization of IMAP for mobile clients. The Lemonade Profile [LEMONADEPROFILE] specifies the Lemonade Pull Model that governs the exchanges among mail servers or between desktop mail client and mail servers. Lemonade investigates adding mobile optimizations for the next version of the profile. LDELIVER should be seen as a way to address the issues of mobile optimization and an input to the Lemonade Profile work as a alternative suitable for fast support of forward, reply and edit without download. Clients and servers MAY support other Lemonade extensions and behaviors. This document assumes that clients MUST be compliant to LDELIVER, if they decide to use LDELIVER. The server that advertises support for LDELIVER via CAPABILITY MUST be compliant to LDELIVER for its exchanges with the mobile client. 3. Interactions between the Client and Server when supporting LDELIVER A compliant server must support all IMAPv4Rev1 commands from client devices following the syntax defined in [RFC3501]. Thus, a client may issue any existing IMAP commands to the server, and both the server and client must behave as specified in [RFC3501]. 4. The CAPABILITY Command The CAPABILITY command is defined in [RFC3501], section 6.1.1. The client sends a CAPABILITY command so it can query the server to find out what commands it supports. In [RFC3501], the IMAP server is allowed to specify additional capabilities not included in that specification. A server that supports LDELIVER conforms to that requirement, and MUST list that it supports LDELIVER. Maes Expires û January 2006 [Page 4] July 2005 A server can also enumerate individually the other commands that it supports. capability_cmd = tag SP "CAPABILITY" Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT Responses: REQUIRED untagged response: CAPABILITY Result: OK - capability completed BAD - command unknown or arguments invalid Example: A server that implements LDELIVER. C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LDELIVER S: a001 OK CAPABILITY completed 5. Specification details 5.1. the LDELIVER command The LDELIVER command can be used for creating new messages, or replying to/forwarding an existing message. The first argument after the command name indicates whether this is a new message "N", a reply "R" or a forward "F" of an existing message. When replying/forwarding a message, the client must specify the UID validity (See [IMAP-DISC]) and UID of the message being replied to or forwarded and whether or not to include the attachments of the original message in the reply/forward, by indicating either "Y" or "N" after the UID parameter. If nothing is mentioned, the text of the message being replied to/forwarded is automatically appended to the end of the new message regardless. Edits of part of the message (including reply address fields also treated as a body part, body or attachments) can be performed by the client. Composition on the server is then done using Content-External-Location. If the user wishes to save a copy of this message to some folder, it can specify that next by using "SAVETO" followed by the name of the folder. If and only if SAVETO is specified, the server will return an LDELIVERUID response code with the UID validity and then the UID of that saved message in that folder. If the message cannot be saved to the server, an okay response will still be returned, but without a UID. The ENVELOPE argument specifies the list of recipients that this message is delivered to, analogous to the SMTP RCPT TO envelop. The last argument of the LDELIVER command is a number in braces that denotes the number of bytes in the message (conforming to [RFC2822]) that is to follow. A "+" before the closing braces means the client will send a CRLF and then the message immediately, without waiting for a continuance response from the server. The server continues to wait until it receives the number of bytes specified, and then waits for an additional CRLF. If more bytes were input before this additional CRLF than was specified, the server returns an error. Thus, the Maes Expires û January 2006 [Page 5] July 2005 client should input exactly the number of bytes specified for the Internet Address, and then one final CRLF to terminate the LDELIVER. The ldeliver command can used after the client has been authenticated. This command will not disturb the current IMAP connection, meaning that the server will not send back any untagged responses, (such as EXISTS, EXPUNGE, etc.) as a response to LDELIVER. ldeliver_cmd = tag SP "LDELIVER" SP ("N") / (("R"/"F") SP folder SP uid-validity SP uid SP ("Y" / "N)) [SP "SAVETO=" folder] SP ENVELOPE recipient-list "{" number ["+"] "}" internet_msg recipient-list = ô(ô 1*address ô)ö / nil address = defined in RFC3501 Section 9 (Formal Syntax) Valid States: AUTHENTICATED, SELECTED Responses: no responses Result: OK - mail delivered successfully by the SMTP server, LDELIVERUID response code included if the SAVETO is included in the command. BAD - invalid arguments, for example missing parameter. NO - when the envelope information is invalid Example: new message C: A001 LDELIVER N SAVETO=~/Sent ENVELOPE (ôMoochö NIL ômoochö ôowatagu.siam.eduö)){299} Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) From: Fred Foobar Subject: afternoon meeting To: mooch@owatagu.siam.edu Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hello Joe, do you think we can meet at 3:30 tomorrow? A new message is prepared and sent. S: A001 OK LDELIVER [LDELIVERUID 1 140] completed Example: reply message C: A001 LDELIVER R Inbox 1 203 Y ENVELOPE (ôMoochö NIL ômoochö ôowatagu.siam.eduö)) {299} Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) From: Fred Foobar Subject: afternoon meeting To: mooch@owatagu.siam.edu Maes Expires û January 2006 [Page 6] July 2005 Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hello Joe, do you think we can meet at 3:30 tomorrow? A reply message for message 203 is prepared and includes all original attachments. S: A001 OK LDELIVER completed 5.2. Content-External-Location, IMAP URL, and Server based attachments A LDELIVER compliant client may support adding attachments from either local storage, or re-attaching remote attachments stored in another IMAP message. On replying to or forwarding a message, the client allows the user to compose the body of the message as well it may offer the user the option to re-attach remote attachments. It may do so, by issuing a BODYSTRUCTURE request, and allowing the user to choose which attachment parts of the original message to re-attach. Instead of then downloading those attachments in full and re- attaching them locally, the client may form an IMAP URL [RFC2192] such as ôimap://server/INBOX/;uid=100;section=1.2ö and then add an attachment to the composed message that includes this URL in a Content-External-Location header. Example message From: sender@sender.org To: receiver@receiver.org Subject: those attachments that originator@originator.org sent Content-Type: multipart/mixed; boundary=myboundary --myboundary Content-Type: text/plain I donÆt like this photo that Originator took. --myboundary Content-Type: image/jpeg Content-External-Location: imap://server/INBOX/;uid=100;section=1.2 Text here is attached as a placeholder if the fetch fails --myboundaryù Maes Expires û January 2006 [Page 7] July 2005 The server, upon receiving the LDELIVERed message, replaces any MIME parts containing Content-External-Location by fetching the IMAP URLs (if possible) and replacing the content of the placeholder attachment with the content of the fetched attachment. 6. Note on LDELIVER, SMTP and Lemonade Profile A server MAY always rather support SMTP instead of LDELIVER. A client MAY then select to rely on SMTP instead of LDELIVER. This of course may reduce the forward / reply without download capabilities that may be available. A server MAY also advertise via capability support for Lemonade Profile [LEMONADEPROFILE] or the subset of commands (see [LEMONADEPROFILE] needed to support forward without download. In such case, the client MAY rely on the Lemonade profile forward without download mechanisms. When it comes to mobile clients, it is generally not expected that mobile clients will run mailing list services from mobile devices, utilize large distribution lists, or run automated mail notification services. Therefore, LDELIVER is not designed to support SMTP functions which take advantage of full control of the SMTP envelop, or SMTP extensions like NOTARY. In general, because of mobile device resource constraints, and corporate firewall and security policies, LDELIVER is easier to deploy for mobile devices, than exposing and restricting SMTP services to mobile devices, especially those devices without VPN functionality. Security Considerations The protocol calls for the same security requirements as IMAP and [LEMONADEPROFILE]. It is also recommended that clients be explicitly registered with the server through separate channels / application. Exchanges should then be paired, encrypted and signed as deemed appropriate by the user and administrators. When an implementation is based on gateways, this may create new security issues. In some implementations, the client may connect to a proxy that sits in an operator network, but the backend email storage server sits in a separate enterprise network. The enterprise network is assumed to be secure, but the operator network may not be trusted. If Maes Expires û January 2006 [Page 8] July 2005 unencrypted information lies in the operator network, that information is vulnerable to attacks. If the LDELIVER server is implemented in the enterprise network, then the proxy on the carrier should be an encrypted SSL pass-through proxy. The proxy is unaware of the encryption keys and thus cannot encrypt any data. Without the encryption key, this proxy cannot see any of the information sent from the client, nor can it send any bogus commands to the backend enterprise email server to corrupt the user's mailbox. The additional cost for this design is that the backend enterprise email server and the client devices must have additional processing to handle this encryption. If the LDELIVER server is implemented as a backend IMAP server with additional command processing done on it, there are more complex security issues. This proxy must be able to send commands to the backend server to accomplish its tasks, as well as read information coming from the backend server. An attacker thus can send commands to the backend. This proxy may also send bogus responses back to the client. Clearly, this setup is not an ideal issue and many complications that make this problem complex to solve. The suggestion recommended is to rely on encrypted messages to be decrypted at the backend submit server before being sent by it. The key exchange for encryption should not occur through the proxy. It has to be done through another channel: manually entered by user (e.g. password), or via an HTTP SSL request to the enterprise server. References [BURL] Newman, C., "Message Composition", draft-ietf-lemonade-burl-xx (work in progress). [IMAP-DISC] Austein, R. "Synchronization Operations For Disconnected Imap4 Clients", IMAP-DISC, November 1994. http://asg.web.cmu.edu/cyrus/rfc/draft-ietf-imap-disc-01.html [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", draft-ietf-lemonade-profile-XX.txt, (work in progress). [MEMAIL] Maes, S.H., ôLemonade and Mobile e-mail", draft-maes- lemonade-mobile-email-xx.txt, (work in progress). [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, (Work in progress). http://www.openmobilealliance.org/ [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP Maes Expires û January 2006 [Page 9] July 2005 Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in progress). [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119 [RFC2192] Newman, C. ôIMAP URL Schemeö, RFC 2192, September 1997. http://www.faqs.org/rfcs/rfc2192.html [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P. "Internet Message Format", RFC 2822, April 2001. http://www.ietf.org/rfc/rfc2822 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 Future Work TBD Version History Release 00 Initial release published in June 2005 Acknowledgments The authors want to thank all who have contributed key insight and extensively reviewed and discussed the concepts of LDELIVER and its early introduction as XDELIVER in P-IMAP [P-IMAP]. Authors Addresses Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA Phone: +1-650-607-6296 Email: stephane.maes@oracle.com Rafiul Ahad Oracle Corporation Maes Expires û January 2006 [Page 10] July 2005 500 Oracle Parkway Redwood Shores, CA 94065 USA Eugene Chiu Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Ray Cromwell Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Jia-der Day Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Vida Ha Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Wook-Hyun Jeong Samsung Electronics,CO., LTD 416, Maetan-3dong, Yeongtong-gu, Suwon-city, Gyeonggi-do, Korea 442-600 Tel: +82-31-279-8289 E-mail: wh75.jeong@samsung.com Chang Kuang Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Rodrigo Lima Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Gustaf Rosell Maes Expires û January 2006 [Page 11] July 2005 Sony Ericsson P.O. Box 64 SE-164 94 Kista, Sweden Tel: +46 8 508 780 00 Jean Sini Symbol Technologies 6480 Via Del Oro San Jose, CA 95119 USA Sung-Mu Son LG Electronics Mobile Communication Technology Research Lab. Tel: +82-31-450-1910 E-Mail: sungmus@lge.com Fan Xiaohui Product Development Division R&D CENTER CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC) ADD: 53A, Xibianmennei Ave.,Xuanwu District, Beijing,100053 China TEL:+86 10 66006688 EXT 3137 Zhao Lijun CMCC R&D ADD: 53A, Xibianmennei Ave.,Xuanwu District, Beijing,100053 China TEL:.8610.66006688.3041 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. Maes Expires û January 2006 [Page 12] July 2005 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. 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. 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. 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. Maes Expires û January 2006 [Page 13]