7Network Working Group S. Maes
8Request for Comments: 4550 Oracle
9Category: Standards Track A. Melnikov
14 Internet Email to Support Diverse Service Environments
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
27 Copyright (C) The Internet Society (2006).
31 This document describes a profile (a set of required extensions,
32 restrictions, and usage modes) of the IMAP and mail submission
33 protocols. This profile allows clients (especially those that are
34 constrained in memory, bandwidth, processing power, or other areas)
35 to efficiently use IMAP and Submission to access and submit mail.
36 This includes the ability to forward received mail without needing to
37 download and upload the mail, to optimize submission, and to
38 efficiently resynchronize in case of loss of connectivity with the
41 The Internet Email to Support Diverse Service Environments (Lemonade)
42 profile relies upon extensions to IMAP and Mail Submission protocols;
43 specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501)
44 extensions and the BURL extension to the SUBMIT protocol (RFC 4409).
58Maes & Melnikov Standards Track [Page 1]
60RFC 4550 Lemonade Profile June 2006
65 1. Introduction ....................................................3
66 1.1. Conventions Used in This Document ..........................3
67 2. Forward without Download ........................................3
68 2.1. Motivations ................................................3
69 2.2. Message Sending Overview ...................................4
70 2.3. Traditional Strategy .......................................4
71 2.4. Step-by-Step Description ...................................5
72 2.4.1. Message Assembly Using IMAP CATENATE Extension ......6
73 2.4.2. Message Assembly Using SMTP CHUNKING and
74 BURL Extensions ....................................10
75 2.5. Normative Statements Related to Forward without Download ..14
76 2.6. Security Considerations for "pawn-tickets" ................14
77 2.7. The fcc Problem ...........................................15
78 2.8. Registration of $Forwarded IMAP Keyword ...................15
79 3. Message Submission .............................................15
80 3.1. Pipelining ................................................16
81 3.2. DSN Support ...............................................16
82 3.3. Message Size Declaration ..................................16
83 3.4. Enhanced Status Code Support ..............................16
84 3.5. TLS .......................................................16
85 4. Quick Resynchronization ........................................16
86 5. Additional IMAP Extensions .....................................17
87 6. Summary of the Required IMAP and SMTP Extensions ...............17
88 7. Future work ....................................................18
89 8. Security Considerations ........................................18
90 8.1. Confidentiality Protection of Submitted Messages ..........19
91 8.2. TLS .......................................................19
92 9. References .....................................................20
93 9.1. Normative References ......................................20
94 9.2. Informative References ....................................21
95 10. Acknowledgements ..............................................21
114Maes & Melnikov Standards Track [Page 2]
116RFC 4550 Lemonade Profile June 2006
121 Lemonade provides enhancements to Internet email to support diverse
122 service environments.
124 This document describes the Lemonade profile, which includes:
126 - "forward without download", which describes exchanges between
127 Lemonade clients and servers to allow new email messages to be
128 submitted incorporating content that resides on locations
129 external to the client.
131 - Quick mailbox resynchronization using [CONDSTORE].
133 - Several IMAP and SMTP extensions that save bandwidth and/or
134 number of round-trips required to send/receive data.
136 The organization of this document is as follows. Section 2 describes
137 "forward without download". Section 3 describes additional SMTP
138 extensions that must be supported by all Lemonade Submission servers.
139 Section 4 describes IMAP quick resynchronization.
1411.1. Conventions Used in This Document
143 In examples, "M:", "I:", and "S:" indicate lines sent by the client
144 messaging user agent, IMAP e-mail server, and SMTP submit server,
147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
149 document are to be interpreted as described in [RFC2119].
151 All examples in this document are optimized for Lemonade use and
152 might not represent examples of proper protocol usage for a general
153 use Submit/IMAP client. In particular, examples assume that Lemonade
154 Submit and IMAP servers support all Lemonade extensions described in
155 this document, so they don't show how to deal with absence of an
1582. Forward without Download
162 The advent of client/server email using the [RFC3501], [RFC2821], and
163 [SUBMIT] protocols has changed what formerly were local disk
164 operations into repetitive network data transmissions.
170Maes & Melnikov Standards Track [Page 3]
172RFC 4550 Lemonade Profile June 2006
175 Lemonade "forward without download" makes use of the [BURL] SUBMIT
176 extension to enable access to external sources during the submission
177 of a message. In combination with the IMAP [URLAUTH] extension,
178 inclusion of message parts or even entire messages from the IMAP mail
179 store is possible with a minimal trust relationship between the IMAP
180 and SMTP SUBMIT servers.
182 Lemonade "forward without download" has the advantage of maintaining
183 one submission protocol, and thus avoids the risk of having multiple
184 parallel and possibly divergent mechanisms for submission. The
185 client can use Submit/SMTP [SUBMIT] extensions without these being
186 added to IMAP. Furthermore, by keeping the details of message
187 submission in the SMTP SUBMIT server, Lemonade "forward without
188 download" can work with other message retrieval protocols such as
189 Post Office Protocol (POP), Network News Transfer Protocol (NNTP), or
190 whatever else may be designed in the future.
1922.2. Message Sending Overview
194 The act of sending an email message can be thought of as involving
195 multiple steps: initiation of a new draft, draft editing, message
196 assembly, and message submission.
198 Initiation of a new draft and draft editing takes place in the Mail
199 User Agent (MUA). Frequently, users choose to save more complex
200 messages on an [RFC3501] server (via the APPEND command with the
201 \Draft flag) for later recall by the MUA and resumption of the
204 Message assembly is the process of producing a complete message from
205 the final revision of the draft and external sources. At assembly
206 time, external data is retrieved and inserted in the message.
208 Message submission is the process of inserting the assembled message
209 into the [RFC2821] infrastructure, typically using the [SUBMIT]
2122.3. Traditional Strategy
214 Traditionally, messages are initiated, edited, and assembled entirely
215 within an MUA, although drafts may be saved to an [RFC3501] server
216 and later retrieved from the server. The completed text is then
217 transmitted to a Message Submission Agent (MSA) for delivery.
226Maes & Melnikov Standards Track [Page 4]
228RFC 4550 Lemonade Profile June 2006
231 There is often no clear boundary between the editing and assembly
232 process. If a message is forwarded, its content is often retrieved
233 immediately and inserted into the message text. Similarly, when
234 external content is inserted or attached, the content is usually
235 retrieved immediately and made part of the draft.
237 As a consequence, each save of a draft and subsequent retrieve of the
238 draft transmits that entire (possibly large) content, as does message
241 In the past, this was not much of a problem, because drafts, external
242 data, and the message submission mechanism were typically located on
243 the same system as the MUA. The most common problem was running out
2462.4. Step-by-Step Description
248 The model distinguishes among a Mail User Agent (MUA), an IMAP4Rev1
249 Server ([RFC3501]), and a SMTP submit server ([SUBMIT]), as
250 illustrated in Figure 1.
252 +--------------------+ +--------------+
253 | | <------------ | |
254 | MUA (M) | | IMAPv4Rev1 |
256 | | ------------> | (Server I) |
257 +--------------------+ +--------------+
266 | |----------------------> | SMTP |
268 |-----------------------------| Server |
272 Figure 1: Lemonade "forward without download"
274 Lemonade "forward without download" allows a Messaging User Agent to
275 compose and forward an e-mail combining fragments that are located in
276 an IMAP server, without having to download these fragments to the
282Maes & Melnikov Standards Track [Page 5]
284RFC 4550 Lemonade Profile June 2006
287 There are two ways to perform "forward without download", based on
288 where the message assembly takes place. The first uses an extended
289 APPEND command [CATENATE] to edit a draft message in the message
290 store and cause the message assembly on the IMAP server. The second
291 uses a succession of BURL and BDAT commands to submit and assemble
292 (through concatenation) message data from the client and external
293 data fetched from the provided URL. The two subsequent sections
294 provide step-by-step instructions on how "forward without download"
2972.4.1. Message Assembly Using IMAP CATENATE Extension
299 In the [BURL]/[CATENATE] variant of the Lemonade "forward without
300 download" strategy, messages are initially composed and edited within
301 an MUA. The [CATENATE] extension to [RFC3501] is then used to create
302 the messages on the IMAP server by transmitting new text and
303 assembling them. The [UIDPLUS] IMAP extension is used by the client
304 in order to learn the Unique Identifier (UID) of the created
305 messages. Finally, a [URLAUTH] format URL is given to a [SUBMIT]
306 server for submission using the [BURL] extension.
308 The flow involved to support such a use case consists of:
310 M: {to I -- Optional} The client connects to the IMAP server,
311 optionally starts TLS (if data confidentiality is required),
312 authenticates, opens a mailbox ("INBOX" in the example below) and
313 fetches body structures (See [RFC3501]).
317 M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
318 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
319 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
320 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
322 "<960723163407.20117h@washington.example.com>"
323 "Your trip details" "BASE64" 4554 73) "MIXED"))
324 I: A0051 OK completed
326 M: {to I} The client invokes CATENATE (See [CATENATE] for details
327 of the semantics and steps) -- this allows the MUA to create
328 messages on the IMAP server using new data combined with one or
329 more message parts already present on the IMAP server.
331 Note that the example for this step doesn't use the LITERAL+
332 [LITERAL+] extension. Without LITERAL+, the new message is
333 constructed using 3 round-trips. If LITERAL+ is used, the new
334 message can be constructed using one round-trip.
338Maes & Melnikov Standards Track [Page 6]
340RFC 4550 Lemonade Profile June 2006
343 M: A0052 APPEND Sent FLAGS (\Seen $MDNSent)
345 I: + Ready for literal data
346 M: Message-ID: <419399E1.6000505@caernarfon.example.org>
347 M: Date: Thu, 12 Nov 2004 16:57:05 +0000
348 M: From: Bob Ar <bar@example.org>
350 M: To: foo@example.net
351 M: Subject: About our holiday trip
352 M: Content-Type: multipart/mixed;
353 M: boundary="------------030308070208000400050907"
355 M: --------------030308070208000400050907
356 M: Content-Type: text/plain; format=flowed
358 M: Our travel agent has sent the updated schedule.
362 M: --------------030308070208000400050907
363 M: URL "/INBOX;UIDVALIDITY=385759045/;
364 UID=25627/;Section=2.MIME" URL "/INBOX;
365 UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44}
366 I: + Ready for literal data
368 M: --------------030308070208000400050907--
370 I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed
372 M: {to I} The client uses GENURLAUTH command to request a URLAUTH
375 I: {to M} The IMAP server returns a URLAUTH URL suitable for later
376 retrieval with URLFETCH (see [URLAUTH] for details of the
377 semantics and steps).
379 M: A0054 GENURLAUTH "imap://bob.ar@example.org/Sent;
380 UIDVALIDITY=387899045/;uid=45;expire=2005-10-
381 28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
382 I: * GENURLAUTH "imap://bob.ar@example.org/Sent;
383 UIDVALIDITY=387899045/;uid=45;expire=
384 2005-10-28T23:59:59Z;urlauth=submit+bob.ar:
385 internal:91354a473744909de610943775f92038"
386 I: A0054 OK GENURLAUTH completed
388 M: {to S} The client connects to the mail submission server and
389 starts a new mail transaction. It uses BURL to let the SMTP
390 submit server fetch the content of the message from the IMAP
394Maes & Melnikov Standards Track [Page 7]
396RFC 4550 Lemonade Profile June 2006
399 server. (See [BURL] for details of the semantics and steps.)
400 This allows the MUA to authorize the SMTP submit server to access
401 the message composed as a result of the CATENATE step. Note that
402 the second EHLO command is required after a successful STARTTLS
403 command. Also note that there might be a third required EHLO
404 command if the second EHLO response doesn't list any BURL options.
405 Section 2.4.2 demonstrates this.
407 S: 220 owlry.example.org ESMTP
408 M: EHLO potter.example.org
409 S: 250-owlry.example.com
419 S: 250 ENHANCEDSTATUSCODES
421 S: 220 Ready to start TLS
422 ...TLS negotiation, subsequent data is encrypted...
423 M: EHLO potter.example.org
424 S: 250-owlry.example.com
433 S: 250 ENHANCEDSTATUSCODES
434 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
435 S: 235 2.7.0 PLAIN authentication successful.
436 M: MAIL FROM:<bob.ar@example.org>
437 S: 250 2.5.0 Address Ok.
438 M: RCPT TO:<foo@example.net>
439 S: 250 2.1.5 foo@example.net OK.
440 M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;
441 uid=45/;urlauth=submit+bar:internal:
442 91354a473744909de610943775f92038 LAST
450Maes & Melnikov Standards Track [Page 8]
452RFC 4550 Lemonade Profile June 2006
455 S: {to I} The mail submission server uses URLFETCH to fetch the
456 message to be sent. (See [URLAUTH] for details of the semantics
457 and steps. The so-called "pawn-ticket" authorization mechanism
458 uses a URI that contains its own authorization credentials.)
460 I: {to S} Provides the message composed as a result of the
463 Mail submission server opens IMAP connection to the IMAP server:
465 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
466 CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
469 I: a000 Start TLS negotiation now
470 ...TLS negotiation, if successful - subsequent data
472 S: a001 LOGIN submitserver secret
473 I: a001 OK submitserver logged in
474 S: a002 URLFETCH "imap://bob.ar@example.org/Sent;
475 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
476 internal:91354a473744909de610943775f92038"
477 I: * URLFETCH "imap://bob.ar@example.org/Sent;
478 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
479 internal:91354a473744909de610943775f92038" {15065}
480 ...message body follows...
481 S: a002 OK URLFETCH completed
483 S: * BYE See you later
484 S: a003 OK Logout successful
486 Note that if the IMAP server doesn't send CAPABILITY response code
487 in the greeting, the mail submission server must issue the
488 CAPABILITY command to learn about supported IMAP extensions as
489 described in RFC 3501.
491 Also, if data confidentiality is not required, the mail submission
492 server may omit the STARTTLS command before issuing the LOGIN
495 S: {to M} Submission server assembles the complete message, and if
496 the assembly succeeds, it returns OK to the MUA:
500 M: {to I} The client marks the message containing the forwarded
501 attachment on the IMAP server.
506Maes & Melnikov Standards Track [Page 9]
508RFC 4550 Lemonade Profile June 2006
511 M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
512 I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
513 I: A0053 OK STORE completed
515 Note: the UID STORE command shown above will only work if the
516 marked message is in the currently selected mailbox; otherwise, it
517 requires a SELECT. This command can be omitted. The untagged
518 FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword
519 is described in Section 2.8.
5212.4.2. Message Assembly Using SMTP CHUNKING and BURL Extensions
523 In the [BURL]/[CHUNKING] variant of the Lemonade "forward without
524 download" strategy, messages are initially composed and edited within
525 an MUA. During submission [SUBMIT], BURL [BURL] and BDAT [CHUNKING]
526 commands are used to create the messages from multiple parts. New
527 body parts are supplied using BDAT commands, while existing body
528 parts are referenced using [URLAUTH] format URLs in BURL commands.
530 The flow involved to support such a use case consists of:
532 M: {to I -- Optional} The client connects to the IMAP server,
533 optionally starts TLS (if data confidentiality is required),
534 authenticates, opens a mailbox ("INBOX" in the example below), and
535 fetches body structures (see [RFC3501]).
539 M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
540 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
541 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
542 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
544 "<960723163407.20117h@washington.example.com>"
545 "Your trip details" "BASE64" 4554 73) "MIXED"))
546 I: A0051 OK completed
548 M: {to I} The client uses GENURLAUTH command to request URLAUTH
549 URLs (see [URLAUTH]) referencing pieces of the message to be
552 I: {to M} The IMAP server returns URLAUTH URLs suitable for later
553 retrieval with URLFETCH (see [URLAUTH] for details of the
554 semantics and steps).
556 M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX;
557 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
558 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar"
562Maes & Melnikov Standards Track [Page 10]
564RFC 4550 Lemonade Profile June 2006
567 INTERNAL "imap://bob.ar@example.org/INBOX;
568 UIDVALIDITY=385759045/;UID=25627/;Section=2;
569 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
570 I: * GENURLAUTH "imap://bob.ar@example.org/INBOX;
571 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
572 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
573 internal:A0DEAD473744909de610943775f9BEEF"
574 "imap://bob.ar@example.org/INBOX;
575 UIDVALIDITY=385759045/;UID=25627/;Section=2;
576 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
577 internal:BEEFA0DEAD473744909de610943775f9"
578 I: A0054 OK GENURLAUTH completed
580 M: {to S} The client connects to the mail submission server and
581 starts a new mail transaction. It uses BURL to instruct the SMTP
582 submit server to fetch from the IMAP server pieces of the message
583 to be sent (see [BURL] for details of the semantics and steps).
584 Note that the second EHLO command is required after a successful
585 STARTTLS command. The third EHLO command is required if and only
586 if the second EHLO response doesn't list any BURL options. See
587 Section 2.4.1 for an example of submission where the third EHLO
588 command/response is not present.
590 S: 220 owlry.example.org ESMTP
591 M: EHLO potter.example.org
592 S: 250-owlry.example.com
598 S: 250-AUTH DIGEST-MD5
602 S: 250 ENHANCEDSTATUSCODES
604 S: 220 Ready to start TLS
605 ...TLS negotiation, subsequent data is encrypted...
606 M: EHLO potter.example.org
607 S: 250-owlry.example.com
613 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
618Maes & Melnikov Standards Track [Page 11]
620RFC 4550 Lemonade Profile June 2006
624 S: 250 ENHANCEDSTATUSCODES
625 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
626 S: 235 2.7.0 PLAIN authentication successful.
627 M: EHLO potter.example.org
628 S: 250-owlry.example.com
632 S: 250-BURL imap imap://imap.example.org
634 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
637 S: 250 ENHANCEDSTATUSCODES
638 M: MAIL FROM:<bob.ar@example.org> BODY=BINARY
639 S: 250 2.5.0 Address Ok.
640 M: RCPT TO:<foo@example.net>
641 S: 250 2.1.5 foo@example.net OK.
643 M: Message-ID: <419399E1.6000505@caernarfon.example.org>
644 M: Date: Thu, 12 Nov 2004 16:57:05 +0000
645 M: From: Bob Ar <bar@example.org>
647 M: To: foo@example.net
648 M: Subject: About our holiday trip
649 M: Content-Type: multipart/mixed;
650 M: boundary="------------030308070208000400050907"
652 M: --------------030308070208000400050907
653 M: Content-Type: text/plain; format=flowed
655 M: Our travel agent has sent the updated schedule.
659 M: --------------030308070208000400050907
661 M: BURL imap://bob.ar@example.org/INBOX;
662 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
663 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
664 internal:A0DEAD473744909de610943775f9BEEF
666 M: BURL imap://bob.ar@example.org/INBOX;
667 UIDVALIDITY=385759045/;UID=25627/;Section=2;
668 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
669 internal:BEEFA0DEAD473744909de610943775f9
674Maes & Melnikov Standards Track [Page 12]
676RFC 4550 Lemonade Profile June 2006
681 M: --------------030308070208000400050907--
683 S: {to I} The mail submission server uses URLFETCH to fetch the
684 pieces of the message to be sent (see [URLAUTH] for details of the
685 semantics and steps). The so-called "pawn-ticket" authorization
686 mechanism uses a URI that contains its own authorization
689 I: {to S} Returns the requested body parts.
691 Mail submission server opens IMAP connection to the IMAP server:
693 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
694 CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
696 S: a001 LOGIN submitserver secret
697 I: a001 OK submitserver logged in
698 S: a002 URLFETCH "imap://bob.ar@example.org/INBOX;
699 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
700 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
701 internal:A0DEAD473744909de610943775f9BEEF" "imap://
702 bob.ar@example.org/INBOX;
703 UIDVALIDITY=385759045/;UID=25627/;Section=2;
704 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
705 internal:BEEFA0DEAD473744909de610943775f9"
706 I: * URLFETCH "imap://bob.ar@example.org/INBOX;
707 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
708 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
709 internal:A0DEAD473744909de610943775f9BEEF" {84}
710 ...message section follows...
711 "imap://bob.ar@example.org/INBOX;
712 UIDVALIDITY=385759045/;UID=25627/;Section=2;
713 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
714 internal:BEEFA0DEAD473744909de610943775f9" {15065}
715 ...message section follows...
716 S: a002 OK URLFETCH completed
718 S: * BYE See you later
719 S: a003 OK Logout successful
721 Note that if the IMAP server doesn't send CAPABILITY response code
722 in the greeting, the mail submission server must issue the
723 CAPABILITY command to learn about supported IMAP extensions as
724 described in RFC 3501.
730Maes & Melnikov Standards Track [Page 13]
732RFC 4550 Lemonade Profile June 2006
735 Also, if data confidentiality is required, the mail submission
736 server should start TLS before issuing the LOGIN command.
738 S: {to M} Submission server assembles the complete message, and if
739 the assembly succeeds, it acknowledges acceptance of the message
740 by sending 250 response to the last BDAT command:
742 S: 250 2.5.0 Ok, message accepted.
744 M: {to I} The client marks the message containing the forwarded
745 attachment on the IMAP server.
747 M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
748 I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
749 I: A0053 OK STORE completed
751 Note: the UID STORE command shown above will only work if the
752 marked message is in the currently selected mailbox; otherwise, it
753 requires a SELECT. This command can be omitted. The untagged
754 FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword
755 is described in Section 2.8.
7572.5. Normative Statements Related to Forward without Download
759 Lemonade-compliant IMAP servers MUST support IMAP4Rev1 [RFC3501],
760 CATENATE [CATENATE], UIDPLUS [UIDPLUS], and URLAUTH [URLAUTH]. This
761 support MUST be declared via CAPABILITY [RFC3501].
763 Lemonade-compliant submit servers MUST support BURL [BURL], 8BITMIME
764 [8BITMIME], BINARYMIME [CHUNKING], and CHUNKING [CHUNKING]. This
765 support MUST be declared via EHLO [RFC2821]. BURL MUST support
766 URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap"
767 option following the BURL EHLO keyword (see [BURL] for more details).
769 Additional normative statements are provided in other sections.
7712.6. Security Considerations for "pawn-tickets"
773 The so-called "pawn-ticket" authorization mechanism uses a URI, which
774 contains its own authorization credentials using [URLAUTH]. The
775 advantage of this mechanism is that the SMTP submit [SUBMIT] server
776 cannot access any data on the [RFC3501] server without a "pawn-
777 ticket" created by the client.
779 The "pawn-ticket" grants access only to the specific data that the
780 SMTP submit [SUBMIT] server is authorized to access, can be revoked
781 by the client, and can have a time-limited validity.
786Maes & Melnikov Standards Track [Page 14]
788RFC 4550 Lemonade Profile June 2006
793 The "fcc problem" refers to delivering a copy of a message to a "file
794 carbon copy" recipient. By far, the most common case of fcc is a
795 client leaving a copy of outgoing mail in a "Sent Mail" or "Outbox"
798 In the traditional strategy, the MUA duplicates the effort spent in
799 transmitting to the MSA by writing the message to the fcc destination
800 in a separate step. This may be a write to a local disk file or an
801 APPEND to a mailbox on an IMAP server. The latter is one of the
802 "repetitive network data transmissions" that represents the "problem"
803 aspect of the "fcc problem".
805 The [CATENATE] extension to [RFC3501] can be used to address the fcc
806 problem. The final message is constructed in the mailbox designed
807 for outgoing mail. Note that the [CATENATE] extension can only
808 create a single message and only on the server that stages the
809 outgoing message for submission. Additional copies of the message
810 can be created on the same server using one or more COPY commands.
8122.8. Registration of $Forwarded IMAP Keyword
814 The $Forwarded IMAP keyword is used by several IMAP clients to
815 specify that the message was resent to another email address,
816 embedded within or attached to a new message. A mail client sets
817 this keyword when it successfully forwards the message to another
818 email address. Typical usage of this keyword is to show a different
819 (or additional) icon for a message that has been forwarded. Once
820 set, the flag SHOULD NOT be cleared.
822 Lemonade-compliant servers MUST be able to store the $Forwarded
823 keyword. They MUST preserve it on the COPY operation. The servers
824 MUST support the SEARCH KEYWORD $Forwarded.
828 Lemonade-compliant mail submission servers are expected to implement
829 the following set of SMTP extensions to make message submission
832 Lemonade clients should take advantage of these features.
842Maes & Melnikov Standards Track [Page 15]
844RFC 4550 Lemonade Profile June 2006
849 Mobile clients regularly use networks with a relatively high latency.
850 Avoidance of round-trips within a transaction has a great advantage
851 for reduction in both bandwidth and total transaction time. For this
852 reason, Lemonade-compliant mail submission servers MUST support the
853 SMTP Service Extensions for Command Pipelining [RFC2920].
855 Clients SHOULD pipeline SMTP commands when possible.
859 Lemonade-compliant mail submission servers MUST support SMTP service
860 extensions for delivery status notifications [RFC3461].
8623.3. Message Size Declaration
864 Lemonade-compliant mail submission servers MUST support the SMTP
865 Service Extension for Message Size Declaration [RFC1870].
867 Lemonade-compliant mail submission servers MUST "expand" all BURL
868 parts before enforcing a message size limit.
870 A Lemonade-compliant client SHOULD use message size declaration. In
871 particular, it MUST NOT send a message to a mail submission server,
872 if the client knows that the message exceeds the maximal message size
873 advertised by the submission server.
8753.4. Enhanced Status Code Support
877 Lemonade-compliant mail submission servers MUST support SMTP Service
878 Extension for Returning Enhanced Error Codes [RFC2034].
882 Lemonade-compliant mail submission servers MUST support SMTP Service
883 Extension for Secure SMTP over TLS [SMTP-TLS].
8854. Quick Resynchronization
887 Lemonade-compliant IMAP servers MUST support the CONDSTORE
888 [CONDSTORE] extension. It allows a client to quickly resynchronize
889 any mailbox by asking the server to return all flag changes that have
890 occurred since the last known mailbox synchronization mark.
892 [IMAP-DISC] shows how to perform quick mailbox resynchronization.
898Maes & Melnikov Standards Track [Page 16]
900RFC 4550 Lemonade Profile June 2006
9035. Additional IMAP Extensions
905 Lemonade-compliant IMAP servers MUST support the NAMESPACE
906 [NAMESPACE] extension. The extension allows clients to discover
907 shared mailboxes and mailboxes belonging to other users.
909 Lemonade-compliant IMAP servers MUST support the LITERAL+ [LITERAL+]
910 extension. The extension allows clients to save a round-trip each
911 time a non-synchronizing literal is sent.
913 Lemonade-compliant IMAP servers MUST support the IDLE [IDLE]
914 extension. The extension allows clients to receive instant
915 notifications about changes in the selected mailbox, without needing
918 Lemonade-compliant IMAP servers MUST support IMAP over TLS [RFC3501]
919 as required by RFC 3501.
9216. Summary of the Required IMAP and SMTP Extensions
923 -----------------------------------------------------|
924 | Name of SMTP extension | Comment |
925 |-------------------------|--------------------------|
926 | PIPELINING | Section 3.1 |
927 |-------------------------|--------------------------|
928 | DSN | Section 3.2 |
929 |-------------------------|--------------------------|
930 | SIZE | Section 3.3 |
931 |-------------------------|--------------------------|
932 | ENHANCEDSTATUSCODES | Section 3.4 |
933 |-------------------------|--------------------------|
934 | STARTTLS | Section 3.5 |
935 |-------------------------|--------------------------|
936 | BURL | Forward without download,|
938 |-------------------------|--------------------------|
939 | URLAUTH support in BURL | Section 2.5 |
940 |-------------------------|--------------------------|
941 | CHUNKING, | Section 2.5 |
942 | BINARYMIME | Section 2.5 |
943 |-------------------------|--------------------------|
944 | 8BITMIME, | Required by BURL |
945 |-------------------------|--------------------------|
946 | AUTH | Required by Submission, |
947 | | See [SMTPAUTH]. |
948 |-------------------------|--------------------------|
954Maes & Melnikov Standards Track [Page 17]
956RFC 4550 Lemonade Profile June 2006
959 -----------------------------------------------------|
960 | Name of IMAP extension | Comment |
962 |-------------------------|--------------------------|
963 | NAMESPACE | Section 5 |
964 |-------------------------|--------------------------|
965 | CONDSTORE | Section 4 |
966 |-------------------------|--------------------------|
967 | STARTTLS |Required by IMAP (RFC3501)|
968 |-------------------------|--------------------------|
969 | URLAUTH, | Forward without download,|
970 | CATENATE, | Section 2 |
972 |-------------------------|--------------------------|
973 | LITERAL+ | Section 5 |
974 |-------------------------|--------------------------|
976 |-------------------------|--------------------------|
977 | $Forwarded IMAP keyword | Section 2.8 |
978 |-------------------------|--------------------------|
982 The Lemonade Working Group is looking into additional issues related
983 to usage of email by mobile devices, possibly including:
985 - Media conversion (static and possibly streamed)
986 - Transport optimization for low or costly bandwidth and less
987 reliable mobile networks (e.g., quick reconnect)
988 - Server to client notifications, possibly outside of the
989 traditional IMAP band
990 - Dealing with firewall and intermediaries
991 - Compression and other bandwidth optimization
993 - Other considerations for mobile clients
9958. Security Considerations
997 Security considerations on Lemonade "forward without download" are
998 discussed throughout Section 2. Additional security considerations
999 can be found in [RFC3501] and other documents describing other SMTP
1000 and IMAP extensions comprising the Lemonade profile.
1002 Note that the mandatory-to-implement authentication mechanism for
1003 SMTP submission is described in [SUBMIT]. The mandatory-to-implement
1004 authentication mechanism for IMAP is described in [RFC3501].
1010Maes & Melnikov Standards Track [Page 18]
1012RFC 4550 Lemonade Profile June 2006
10158.1. Confidentiality Protection of Submitted Messages
1017 When clients submit new messages, link protection such as TLS guards
1018 against an eavesdropper seeing the contents of the submitted message.
1019 It's worth noting, however, that even if TLS is not used, the
1020 security risks are no worse if BURL is used to reference the text
1021 than if the text is submitted directly. If BURL is not used, an
1022 eavesdropper gains access to the full text of the message. If BURL
1023 is used, the eavesdropper may or may not be able to gain such access,
1024 depending on the form of BURL used. For example, some forms restrict
1025 use of the URL to an entity authorized as a submission server or a
1030 When Lemonade clients use the BURL extension to mail submission,
1031 which requires sending a URLAUTH token to the mail submission server,
1032 such a token should be protected from interception to avoid a replay
1033 attack that may disclose the contents of the message to an attacker.
1034 TLS-based encryption of the mail submission path will provide
1035 protection against this attack.
1037 Lemonade clients SHOULD use TLS-protected IMAP and mail submission
1038 channels when using BURL-based message submission to protect the
1039 URLAUTH token from interception.
1041 Lemonade-compliant mail submission servers SHOULD use TLS-protected
1042 IMAP connections when fetching message content using the URLAUTH
1043 token provided by the Lemonade client.
1045 When a client uses SMTP STARTTLS to send a BURL command that
1046 references non-public information, there is a user expectation that
1047 the entire message content will be treated confidentially. To meet
1048 this expectation, the message submission server should use STARTTLS
1049 or a mechanism providing equivalent data confidentiality when
1050 fetching the content referenced by that URL.
1066Maes & Melnikov Standards Track [Page 19]
1068RFC 4550 Lemonade Profile June 2006
10739.1. Normative References
1075 [BURL] Newman, C. "Message Submission BURL Extension", RFC 4468,
1078 [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
1079 Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
1080 RFC 1652, July 1994.
1082 [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission
1083 of Large and Binary MIME Messages", RFC 3030, December
1086 [CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP)
1087 CATENATE Extension", RFC 4469, April 2006.
1089 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) -
1090 UIDPLUS extension", RFC 4315, December 2005.
1092 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1093 Requirement Levels", BCP 14, RFC 2119, March 1997.
1095 [RFC2920] Freed, N., "SMTP Service Extension for Command
1096 Pipelining", STD 60, RFC 2920, September 2000.
1098 [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service
1099 Extension for Message Size Declaration", STD 10, RFC
1100 1870, November 1995.
1102 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for
1103 Mail", RFC 4409, April 2006.
1105 [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
1106 Transport Layer Security", RFC 3207, February 2002.
1108 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
1111 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
1112 4rev1", RFC 3501, March 2003.
1114 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
1115 Extension for Delivery Status Notifications (DSNs)", RFC
1122Maes & Melnikov Standards Track [Page 20]
1124RFC 4550 Lemonade Profile June 2006
1127 [URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) -
1128 URLAUTH Extension", RFC 4467, May 2006.
1130 [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
1131 Error Codes", RFC 2034, October 1996.
1133 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
1136 [SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication",
1137 RFC 2554, March 1999.
1139 [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
1142 [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
1143 STORE Operation or Quick Flag Changes Resynchronization",
1144 RFC 4551, June 2006.
1146 [IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
11489.2. Informative References
1150 [IMAP-DISC] Melnikov, A., "Synchronization operations for
1151 disconnected IMAP4 clients", Work in Progress, October
1156 This document is a product of Lemonade WG. The editors thank the
1157 Lemonade WG members that contributed comments and corrections; in
1158 particular: Randy Gellens, Dave Cridland, and Greg Vaudreuil.
1160 This document borrows some text from "Message Submission" (February
1161 2004) by Mark Crispin, as well as from the trio [BURL], [CATENATE],
1178Maes & Melnikov Standards Track [Page 21]
1180RFC 4550 Lemonade Profile June 2006
1189 Redwood Shores, CA 94065
1192 Phone: +1-650-607-6296
1193 EMail: stephane.maes@oracle.com
1198 5 Castle Business Village
1204 EMail: Alexey.melnikov@isode.com
1234Maes & Melnikov Standards Track [Page 22]
1236RFC 4550 Lemonade Profile June 2006
1239Full Copyright Statement
1241 Copyright (C) The Internet Society (2006).
1243 This document is subject to the rights, licenses and restrictions
1244 contained in BCP 78, and except as set forth therein, the authors
1245 retain all their rights.
1247 This document and the information contained herein are provided on an
1248 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1249 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1250 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1251 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1252 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1255Intellectual Property
1257 The IETF takes no position regarding the validity or scope of any
1258 Intellectual Property Rights or other rights that might be claimed to
1259 pertain to the implementation or use of the technology described in
1260 this document or the extent to which any license under such rights
1261 might or might not be available; nor does it represent that it has
1262 made any independent effort to identify any such rights. Information
1263 on the procedures with respect to rights in RFC documents can be
1264 found in BCP 78 and BCP 79.
1266 Copies of IPR disclosures made to the IETF Secretariat and any
1267 assurances of licenses to be made available, or the result of an
1268 attempt made to obtain a general license or permission for the use of
1269 such proprietary rights by implementers or users of this
1270 specification can be obtained from the IETF on-line IPR repository at
1271 http://www.ietf.org/ipr.
1273 The IETF invites any interested party to bring to its attention any
1274 copyrights, patents or patent applications, or other proprietary
1275 rights that may cover technology that may be required to implement
1276 this standard. Please address the information to the IETF at
1281 Funding for the RFC Editor function is provided by the IETF
1282 Administrative Support Activity (IASA).
1290Maes & Melnikov Standards Track [Page 23]