idnits 2.17.1 draft-crispin-lemonade-pull-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 497 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 65 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 2004) is 7376 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: 'URLAUTH' is mentioned on line 288, but not defined == Unused Reference: 'IMAPURL' is defined on line 381, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) == Outdated reference: A later version (-01) exists of draft-newman-lemonade-compose-00 -- Possible downref: Normative reference to a draft: ref. 'BURL' == Outdated reference: A later version (-05) exists of draft-ietf-lemonade-catenate-01 ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2192 (ref. 'IMAPURL') (Obsoleted by RFC 5092) -- Possible downref: Normative reference to a draft: ref. 'LEMONADE' ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2476 (ref. 'SUBMIT') (Obsoleted by RFC 4409) -- Possible downref: Normative reference to a draft: ref. 'PUSH' ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Crispin 2 INTERNET DRAFT: Message Submission University of Washington 3 Document: draft-crispin-lemonade-pull-01.txt February 2004 5 Message Submission 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC 2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Abstract 30 This document describes a set of strategies to allow clients to 31 submit new email messages incorporating content which resides on 32 locations external to the client. This is the so-called "IMAP 33 Pull" approach currently being considered by the LEMONADE working 34 group as one solution to the "forward without download" problem 35 (that is, as a means for clients to send new messages consisting of 36 or containing all or parts of previously received messages without 37 having to download and upload the data). Some of the strategies 38 in this document rely upon extensions to other protocols; 39 specifically URLAUTH and CATENATE in the IMAP protocol (RFC 3501) 40 and BURL in the SUBMIT protocol (RFC 2476). 42 This document describes the strategies in multiple variants, as well 43 as the implications on authorization and the "fcc problem". 45 Conventions Used in this Document 47 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 48 in this document are to be interpreted as described in [KEYWORDS]. 50 The formal syntax use the Augmented Backus-Naur Form (ABNF) 51 notation including the core rules defined in Appendix A of [ABNF]. 53 In examples, "C:" and "S:" indicate lines sent by the client and 54 server respectively. If a single "C:" or "S:" label applies to 55 multiple lines, then the line breaks between those lines are for 56 editorial clarity only and are not part of the actual protocol 57 exchange. 59 Introduction 61 The advent of client/server email using the [IMAP] and [SMTP] 62 protocols has changed what formerly were local disk operations to 63 become excessive and repetitive network data transmissions. As 64 noted in [LEMONADE], this is an onerous burden for clients 65 operating over low-bandwidth or high-latency links. 67 Two major approach were identified in [LEMONADE] to address this 68 problem: "pull" and "push". The strategy used to implement the push 69 approach is the subject of another document ([PUSH]). This document 70 discusses the pull approach, and describes three strategies in which 71 the pull approach can be implemented. 73 All three of the pull strategies discussed below make use of the [BURL] 74 SUBMIT extension to enable access to external sources during the 75 submission of a message. In combination with the IMAP [URLAUTH] 76 extension, inclusion of message parts or even entire messages from the 77 IMAP mail store is possible with a minimal trust relationship between 78 the IMAP and SUBMIT servers. 80 Pull has the distinct advantage of maintaining one submission protocol, 81 and thus avoids the risk of having multiple parallel and possible 82 divergent mechanisms for submission. Furthermore, by keeping the 83 details of message submission in the SUBMIT server, the pull 84 strategies are prepared to work with other message retrieval protocols 85 such as POP, NNTP, or whatever else may be designed in the future. 87 Message Sending Overview 89 The act of sending an email message is best thought of as involving 90 multiple steps: initiation of a new draft, draft editing, message 91 assembly, and message submission. 93 Initiation of a new draft and draft editing take place on the MUA. 94 Frequently, users choose to save more complex and/or time-consuming 95 messages on an [IMAP] server (via the APPEND command with the \Draft 96 flag) for later recall by the MUA and resumption of the editing process. 98 Message assembly is the process of producing a complete message from 99 the final revision of the draft and external sources. At assembly 100 time, external data is retrieved and inserted in the message. 102 Message submission is the process of inserting the assembled message 103 into the [SMTP] infrastructure, typically using the [SUBMIT] protocol. 105 It should be noted that another way of handling external data is to 106 send a pointer to the data, rather than the data itself, to the 107 recipient. To be useful, this pointer must be something that the 108 recipient can resolve and has authorization to reference. Common 109 examples of this are the MESSAGE/EXTERNAL-BODY subtype defined in 110 [MEDIA] and the practice of including public-access URLs in message 111 texts. 113 Traditional Strategy 115 Traditionally, messages are initiated, edited, and assembled entirely 116 within an MUA, although drafts may be saved to an [IMAP] server and 117 later retrieved from the server. The completed text is then 118 transmitted to an MSA for delivery. 120 There is often no clear boundary between the editing and assembly 121 process. If a message is forwarded, its content is often retrieved 122 immediately and inserted into the message text. Similarly, once 123 external content is inserted or attached, the content is usually 124 retrieved immediately and made part of the draft. 126 As a consequence, each save of a draft and subsequent retrieve of 127 the draft transmits that entire (possibly large) content, as does 128 message submission. 130 In the past, this was not much of a problem, because drafts, 131 external data, and the message submission mechanism were typically 132 located on the same system as the MUA. The most common problem was 133 running out of disk quota. 135 [PUSH] Strategy 137 The [PUSH] strategy is the topic of another document, but bears brief 138 mention for comparison purposes. In the [PUSH] strategy, messages are 139 initiated and edited within an MUA. The proposed [CATENATE] extension 140 to [IMAP] is then used to upload the message to the IMAP server and 141 assemble it, and finally the proposed SUBMIT extension in [PUSH] is 142 used to pass the message to an MSA. 144 [PUSH] explicitly limits external content to other messages in the 145 currently selected mailbox on the IMAP server, although there is some 146 discussion about allowing other content in [CATENATE] via URLs. The 147 result of such an extension could be thought of as a hybrid pull-push 148 model, since the IMAP server is used both to pull external references 149 and push the resulting message to the MSA. 151 From the point of view of the "fcc problem" (see below) an advantage 152 (and disadvantage) of this strategy is that a fully-assembled copy of 153 the message is left on the IMAP server. 155 Pull Strategy -- [BURL] Variant 157 In the [BURL] variant of the pull strategy, messages are initiated 158 and edited within an MUA. The MUA then uploads the message 159 to a [SUBMIT] server with the [BURL] extension. Among the types of 160 URIs that can be passed to the [BURL] command are [URLAUTH] format 161 URLs, this satisfying the [LEMONADE] forward-without-download 162 requirement. 164 Note that the assembly and submission operations are done in a single 165 step, as opposed to the two-step process in the [PUSH] strategy; and 166 that external content is not limited to other messages in the currently 167 selected mailbox on the IMAP server. 169 The main disadvantage of this variant is that it does not address the 170 "fcc problem" (see below) intrinsically, although it is suitable with 171 a generalized solution to the fcc problem. 173 Pull Strategy -- [BURL]/[CATENATE] Variant 175 In the [BURL]/[CATENATE] variant of the pull strategy, messages are 176 initiated and edited within an MUA. The proposed [CATENATE] extension 177 to [IMAP] is then used to upload the message to the IMAP server and 178 assemble it, and finally a [URLAUTH] format URL is given to a [SUBMIT] 179 server with the [BURL] extension for submission. 181 If this strategy is chosen over the pure [BURL] variant, it is possible 182 to simplify the [BURL] specification so that a single BURL command 183 defines the message data without any BDAT. 185 This is another form of a hybrid pull-push model. As with the [PUSH] 186 strategy, from the point of view of the "fcc problem" (see below) an 187 advantage (and disadvantage) of this strategy is that a fully-assembled 188 copy of the message is left on the IMAP server. 190 As noted under the [PUSH] strategy, to be fully useful the proposed 191 [CATENATE] extension has to allow arbitrary URLs. 193 Pull Strategy -- [BURL]/Embedded URI Variant 195 In the embedded URI variant of the pull strategy, messages are initiated 196 and edited within an MUA, and saved on the [IMAP] server via an APPEND 197 command. External data is indicated by URIs which are embedded in the 198 message in some easily-identifiable form, perhaps as an added parameter 199 to the [MIME] Content-Type header. A [URLAUTH] format URL is given to 200 a [SUBMIT] server with the [BURL] extension for assembly and submission. 202 If this strategy is chosen over the pure [BURL] variant, it is possible 203 to simplify the [BURL] specification so that a single BURL command 204 defines the message data without any BDAT. 206 The advantage of this strategy is that the client does not deal with 207 message assembly at all; the entire burden is on the [SUBMIT] server. 209 This is the only strategy which is specifically draft-friendly, since 210 drafts with pointers to the external data are suitable for submission 211 without requiring the MUA to break up the draft between texts and 212 pointers for message assembly. The client can simply download the draft 213 from the IMAP server and re-edit it, without the burden of downloading 214 the external data (since it hasn't yet been incorporated into the 215 message) or fetching the message structure, parsing it, and then fetching 216 the editable parts. 218 From the point of view of the "fcc problem" (see below) an advantage 219 (and disadvantage) of this strategy is that a copy of the message 220 with references to external content (but not the external content itself) 221 is left on the IMAP server. 223 Authorization Strategies 225 In any of these strategies, authorization is necessary. It should be 226 noted that in all strategies (including [PUSH]), the [SUBMIT] server 227 is trusted with the data. 229 In the traditional strategy, authorization comes from authentication; 230 the client authenticates to the [IMAP] server as a userid that is 231 authorized to access the data, fetches the data from the [IMAP] server, 232 authenticates to the [SUBMIT] server as a userid that is authorized to 233 submit a message, and then sends the data to the [SUBMIT] server. 235 The [PUSH] strategy multiplexes authorization from a single credential 236 derived from authentication to the [IMAP] server; that credential is 237 assumed to be sufficient to access all data and to submit the data. 238 There is no provision in [PUSH] for differential authorization; for 239 example, it is not possible in [PUSH] to have authentication to the 240 [IMAP] server using a general "role" account (e.g., "helpdesk") for 241 access authorization, but submit as a specific individual. 243 The Pull strategies allow a wide range of authorization mechanisms to 244 obtain data from the pulled URI: 246 (1) The simplest mechanism is a public-access URI. External data is 247 commonly handled today this way, e.g., the MESSAGE/EXTERNAL-BODY subtype 248 defined in [MEDIA] and the practice of including public-access URLs in 249 message texts. 251 (2) Another simple mechanism is one in which the [IMAP] server trusts the 252 [SUBMIT] server. The [SUBMIT] server is authenticated by the [IMAP] 253 server by one of several means (e.g., IP address, Kerberos, SSL/TLS 254 certificate validation, or special account), and is subsequently 255 authorized by the [IMAP] server to access any data on the server. 256 This is the trust model that the [PUSH] model uses, only in reverse. 258 (3) A variant of the trust mechanism is one in which the [SUBMIT] 259 server uses a [SASL] authentication identity on the [IMAP] server that 260 is permitted to use another identity as the authorization identity. The 261 authorization identity passed to the [IMAP] server is the authentication 262 identity used by the client to access the [SUBMIT] server. The advantage 263 of this variant is that the [SUBMIT] server is only responsible for 264 asserting the client's identity but not the client's authorization. Many 265 existing webmail systems work this way today. 267 (4) The so-called "pawn-ticket" authorization mechanism uses a URI which 268 contains its own authorization credentials using a scheme such as 269 [URLAUTH]. The advantage of this mechanism is that the [SUBMIT] server 270 can not access any data on the [IMAP] server without a "pawn-ticket" 271 created by the client. The "pawn-ticket" grants acces only to the specific 272 data that the [SUBMIT] server is authorized to access, can be revoked by 273 the client, and can have a time-limited validity. 275 (5) A variant of the "pawn-ticket" authorization mechanism adds a 276 requirement that a trust relationship, as described in mechanism (2) 277 above, be established in order for the pawn-ticket to be accepted. The 278 advantage of this variant is that even if an attacker learns the 279 "pawn-ticket", it is useless to him because the attacker does not have 280 the trust relationship. The AUTHID and AUTHROLE extensions in [URLAUTH] 281 provide a means for doing this. 283 Of the above mechanisms, (5) is recommended, since it requires that an 284 attacker must both discover a "pawn-ticket" and use the trust relationship 285 of the [SUBMIT] server. 287 The "pawn-ticket" can be further secured by using the optional userid 288 argument in AUTHROLE=compose in a [URLAUTH] format URL. For example, if 289 example.com's [SUBMIT] server is given a URL of 290 imap://joe@example.com/INBOX;uid=20;section=1.2;authrole=submit:smith 291 then the [SUBMIT] server MUST require that smith is the userid 292 authenticated to the [SUBMIT] server. This allows the [SUBMIT] and the 293 [IMAP] servers to be in different authentication realms; in the above 294 example, the user is "joe" on the [IMAP] server and "smith" on the 295 [SUBMIT] server. 297 Note that, even if the user doesn't authenticate to the [SUBMIT] server, 298 there is no added risk over the push strategy. The "pawn-ticket" ensures 299 authorized access to the desired data, and only that data. 301 The fcc Problem 303 The "fcc problem" refers to a frequent need to deliver a copy of the 304 message to a "file carbon copy" receipient. By far, the most common 305 case of fcc is a client leaving a copy of outgoing mail in a "sent 306 messages" or "outbox" mailbox. 308 In the traditional strategy, the MUA duplicates the effort spent in 309 transmitting to the MSA by writing the message to the fcc destination 310 in a separate step. This may be a write to a local disk file or an 311 APPEND to a mailbox on an IMAP server. The latter is one of the 312 "excessive and repretitive network data transmissions" which [LEMONADE] 313 seeks to reduce or eliminate; and represents the "problem" aspect of 314 the "fcc problem". 316 The proposed [CATENATE] extension to [IMAP] is a potentional solution 317 to the fcc problem. It requires making several simplifying assumptions: 318 (1a) there is one, and only one, fcc destination on a single server 319 (2a) the server which holds the fcc is the same as the server which 320 stages the outgoing message for submission 321 (3a) it is desired that the fcc be a copy of the complete message text 322 with all external data inserted in the message 323 As noted above, [CATENATE] is used by the [PUSH] strategy and by the 324 [BURL]/[CATENATE] variant of the pull strategy. 326 The Embedded URI variant of the pull strategy represents an alternative 327 potentional solution to the fcc problem. It requires making several 328 simplifying assumptions: 329 (1b) there is one, and only one, fcc destination on a single server 330 (2b) the server which holds the fcc is the same as the server which 331 stages the outgoing message for submission 332 (3b) it is desired that the fcc be a copy of the message with all 333 external data pointed to by URI references. 335 It can be noted that the first two simplifying assumptions are the same 336 in both potential solutions. The difference is in the third assumption, 337 which are complete opposites. Thus, the preferred solution to the fcc 338 problems depends upon one's preferences in the third assumption. 340 Neither of these two potential solutions are satisfactory if the first 341 two simplifying assumptions can not be made, or if it is a requirement 342 that the third assumption be a matter of user preference. The developers 343 of at least one MUA (Pine) found that it is very important for users to 344 control whether the sent messages mailbox contains external data. 346 A more general solution to the fcc problem is possible with the [BURL] 347 and Embedded URI variants of the pull strategy. The agent which does 348 the message assembly is given the fcc (or fccs) as part of the list of 349 message recipients, along with authorization information and whether the 350 fcc should include external data or pointers. This simplifies to "no 351 action needed" in the Embedded URI variant if the user wants pointers 352 in the fcc. 354 Security Considerations 356 Security considerations are discussed throughout this memo. 358 Acknowledgements 360 Thanks to Randall Gellens and Rob Siemborski for numerous helpful 361 suggestions. 363 References 365 The following references are normative: 367 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 368 Specifications: ABNF", RFC 2234, November 1997. 370 [BURL] Newman, C., "Message Composition", 371 draft-newman-lemonade-compose-00.txt (work in progress), 372 June 2003. 374 [CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) 375 CATENATE Extension", draft-ietf-lemonade-catenate-01 376 (work in progress), January 2004. 378 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 379 4rev1", RFC 3501, March 2003. 381 [IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 383 [LEMONADE] Gellens, R., "IMAP Submit Without Download", 384 draft-ietf-lemonade-submit-01.txt (work in progress), 385 October 2003. 387 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, March 1997. 390 [MEDIA] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet 391 Mail Extensions) Part Two: Media Types", RFC 2046, 392 November 1996. 394 [MIME] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet 395 Mail Extensions) Part One: Format of Internet Message 396 Bodies", RFC 2045, November 1996. 398 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", 399 RFC 2222, October 1997. 401 [SUBMIT] Gellens, R. and Klensin, J., "Message Submission", RFC 2476, 402 December 1998. 404 The following references are informative: 406 [PUSH] Gellens, R., "IMAP Message Submission", 407 draft-gellens-lemonade-push-00.txt (work in progress), 408 December 2003. 410 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 411 April 2001. 413 Author's Address 415 Mark R. Crispin 416 Networks and Distributed Computing 417 University of Washington 418 4545 15th Avenue NE 419 Seattle, WA 98105-4527 421 Phone: (206) 543-5762 422 EMail: MRC@CAC.Washington.EDU 424 Intellectual Property Statement 426 The IETF takes no position regarding the validity or scope of any 427 intellectual property or other rights that might be claimed to 428 pertain to the implementation or use of the technology described in 429 this document or the extent to which any license under such rights 430 might or might not be available; neither does it represent that it 431 has made any effort to identify any such rights. Information on the 432 IETF's procedures with respect to rights in standards-track and 433 standards-related documentation can be found in BCP-11. Copies of 434 claims of rights made available for publication and any assurances 435 of licenses to be made available, or the result of an attempt made 436 to obtain a general license or permission for the use of such 437 proprietary rights by implementors or users of this specification 438 can be obtained from the IETF Secretariat. 440 The IETF invites any interested party to bring to its attention any 441 copyrights, patents or patent applications, or other proprietary 442 rights which may cover technology that may be required to practice 443 this standard. Please address the information to the IETF Executive 444 Director. 446 Full Copyright Statement 448 Copyright (C) The Internet Society 2003. All Rights Reserved. 450 This document and translations of it may be copied and furnished to 451 others, and derivative works that comment on or otherwise explain it 452 or assist in its implementation may be prepared, copied, published 453 and distributed, in whole or in part, without restriction of any 454 kind, provided that the above copyright notice and this paragraph 455 are included on all such copies and derivative works. However, this 456 document itself may not be modified in any way, such as by removing 457 the copyright notice or references to the Internet Society or other 458 Internet organizations, except as needed for the purpose of 459 developing Internet standards in which case the procedures for 460 copyrights defined in the Internet Standards process must be 461 followed, or as required to translate it into languages other than 462 English. 464 The limited permissions granted above are perpetual and will not be 465 revoked by the Internet Society or its successors or assigns. 467 This document and the information contained herein is provided on an 468 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 469 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 470 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 471 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 472 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 474 Acknowledgement 476 Funding for the RFC Editor function is currently provided by the 477 Internet Society.