idnits 2.17.1 draft-royer-lemonade-submit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([E]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 71: '...t this extension MUST list the keyword...' RFC 2119 keyword, line 123: '...message. This argument MUST be in the...' RFC 2119 keyword, line 126: '...it data properly MUST be able to rever...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 14, 2003) is 7615 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC-822' on line 124 looks like a reference -- Missing reference section? 'MIME-IMB' on line 127 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Royer 3 Internet-Draft INET-Consulting 4 Expires: December 13, 2003 June 14, 2003 6 IMAP-PROXY service for mobile clients to do submitting and forwarding 7 draft-royer-lemonade-submit-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on December 13, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This memo describes a method that allows mobile clients to use the 39 IMAP protocol and submit messages to a IMAP-PROXY service that 40 understands [E]SMTP and IMAP. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 3. SUBMIT command . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 4. CAPABILITY interception . . . . . . . . . . . . . . . . . . . . 6 48 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 49 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 7 51 1. Introduction 53 As many mobile devices are both memory and bandwidth limited there 54 needs to be a way for mobile devices to forward and include existing 55 messages and body parts to others using email without downloading. 57 This is a memo released as part of the discussions on the 'LEMONADE' 58 working group. The idea is that a IMAP-PROXY service can sit on top 59 of an IMAP and [E]SMTP server in order to allow mobile devices the 60 ability to submit and retrieve e-mail through one port. 62 The basic idea is that the IMAP aware client sends normal IMAP 63 commands to the IMAP server and gets normal IMAP responses. The IMAP 64 client can not tell that it is passing through a IMAP-PROXY and 65 submit service. 67 How the messages and body part are included is not described in the 68 memo. The memo concentrates on the IMAP-PROXY service itself at the 69 functional level. 71 IMAP-PROXY servers that support this extension MUST list the keyword 72 CAN-SUBMIT in their CAPABILITY response. No client action is needed 73 to invoke the CAN-SUBMIT capability in a server. 75 2. Overview 77 The IMAP-PROXY service sits on top of both IMAP and an SMTP service. 79 +---------+ +---------+ 80 | STANDARD| | SUBMIT | 81 | IMAP | | IMAP | 82 | CLIENT | | CLIENT | 83 +---------+ +---------+ 84 \ / 85 \ / 86 . . 87 . . 88 . 89 | 90 | 91 +----------+ 92 | PROXY | 93 +----------+ 94 / \ 95 / \ 96 | | 97 +------+ +------+ 98 | IMAP | | SMTP | 99 |SERVER| |SERVER| 100 +------+ +------+ 102 The IMAP-PROXY passes all IMAP commands (except SUBMIT) to the IMAP 103 server and passes all IMAP responses back to both the standard and 104 submit IMAP clients. 106 The SUBMIT command is intercepted by the IMAP-PROXY server. It reads 107 the contents of the message sent by the submit aware IMAP client, 108 includes or forward any messages as specified in the content of the 109 submit message. And send SUBMIT responses back to the SUBMIT aware 110 client. 112 3. SUBMIT command 114 Arguments: message literal 116 Responses: no specific responses for this command 118 Result: OK - append completed 119 NO - append error: can't send message. 120 BAD - command unknown or arguments invalid 122 The SUBMIT command submits the literal argument as a new message to 123 the users specified in the message. This argument MUST be in the 124 format of an [RFC-822] message. 8-bit characters are permitted in 125 the message. A server implementation that is unable to preserve 8- 126 bit data properly MUST be able to reversibly convert 8-bit SUBMIT 127 data to 7-bit using a [MIME-IMB] content transfer encoding. 129 The IMAP-PROXY service may check and alter the SMTP headers to ensure 130 they conform to site requirements. This may include making sure the 131 'From:' line is valid within the site. Might include replacing the 132 Message-Id, removing any Received-By lines, Date, and so on. 134 A successful submit simply means that the SMTP server accepted all 135 recipients and the message for submission. Just like with any other 136 SMTP submission recipient errors will bounce back to the users INBOX. 138 Example: C: A003 SUBMIT {356} 139 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 140 C: From: Fred Foobar 141 C: Subject: afternoon meeting 142 C: To: mooch@owatagu.siam.edu,badUser@example.com, 143 unknownUser@example.com 144 C: Message-Id: 145 C: MIME-Version: 1.0 146 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 147 C: 148 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 149 C: 150 S: A003 OK SUBMIT completed 152 If there is an SMTP error the IMAP-PROXY service returns any message 153 followed by any unacceptable recipients. The message is a comma 154 separated string with the non-recipient errors listed first followed 155 by one or more recipients that are invalid. A NO response indicates 156 that no message was sent to any recipient. 158 This example two users were rejected. The first message 159 section is empty (message starts with a comma). 161 S: A123 NO ,badUser@example.com,unknownUser@example.com 163 An error message not specific to any user. The non 164 recipient part of the message must not include a comma 165 as a comma separates the parts of the error message. 166 And the comma is not part of the message itself. 168 S: A445 NO MX server not responding, 170 4. CAPABILITY interception 172 The IMAP-PROXY intercepts the CAPABILITY response from the IMAP 173 server and adds the CAN-SUBMIT capability to the list. 175 Author's Address 177 Doug Royer 178 INET-Consulting.com 179 1795 W. Broadway #266 180 Idaho Falls, Idaho 83402 181 US 183 Phone: 208-520-4044 184 Fax: 866-594-8574 185 EMail: Doug@Royer.com 186 URI: http://Royer.com/People/Doug 188 Full Copyright Statement 190 Copyright (C) The Internet Society (2003). All Rights Reserved. 192 This document and translations of it may be copied and furnished to 193 others, and derivative works that comment on or otherwise explain it 194 or assist in its implementation may be prepared, copied, published 195 and distributed, in whole or in part, without restriction of any 196 kind, provided that the above copyright notice and this paragraph are 197 included on all such copies and derivative works. However, this 198 document itself may not be modified in any way, such as by removing 199 the copyright notice or references to the Internet Society or other 200 Internet organizations, except as needed for the purpose of 201 developing Internet standards in which case the procedures for 202 copyrights defined in the Internet Standards process must be 203 followed, or as required to translate it into languages other than 204 English. 206 The limited permissions granted above are perpetual and will not be 207 revoked by the Internet Society or its successors or assigns. 209 This document and the information contained herein is provided on an 210 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 211 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 212 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 213 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 214 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 216 Acknowledgement 218 Funding for the RFC Editor function is currently provided by the 219 Internet Society.