7Network Working Group D. Cridland, Ed.
8Request for Comments: 5550 A. Melnikov, Ed.
9Obsoletes: 4550 Isode Limited
10Updates: 4469, 4467 S. Maes, Ed.
11Category: Standards Track Oracle
16 Support Diverse Service Environments (Lemonade) Profile
20 This document describes a profile (a set of required extensions,
21 restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail
22 submission, and Sieve protocols. This profile allows clients
23 (especially those that are constrained in memory, bandwidth,
24 processing power, or other areas) to efficiently use IMAP and
25 Submission to access and submit mail. This includes the ability to
26 forward received mail without needing to download and upload the
27 mail, to optimize submission, and to efficiently resynchronize in
28 case of loss of connectivity with the server.
30 The Lemonade Profile relies upon several extensions to IMAP, Sieve,
31 and Mail Submission protocols. The document also defines a new IMAP
32 extension and registers several new IMAP keywords.
36 This document specifies an Internet standards track protocol for the
37 Internet community, and requests discussion and suggestions for
38 improvements. Please refer to the current edition of the "Internet
39 Official Protocol Standards" (STD 1) for the standardization state
40 and status of this protocol. Distribution of this memo is unlimited.
44 Copyright (c) 2009 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents in effect on the date of
49 publication of this document (http://trustee.ietf.org/license-info).
50 Please review these documents carefully, as they describe your rights
51 and restrictions with respect to this document.
58Cridland, et al. Standards Track [Page 1]
60RFC 5550 Lemonade Profile August 2009
63 This document may contain material from IETF Documents or IETF
64 Contributions published or made publicly available before November
65 10, 2008. The person(s) controlling the copyright in some of this
66 material may not have granted the IETF Trust the right to allow
67 modifications of such material outside the IETF Standards Process.
68 Without obtaining an adequate license from the person(s) controlling
69 the copyright in such materials, this document may not be modified
70 outside the IETF Standards Process, and derivative works of it may
71 not be created outside the IETF Standards Process, except to format
72 it for publication as an RFC or to translate it into languages other
77 1. Introduction ....................................................3
78 2. Conventions Used in This Document ...............................4
79 3. Summary of the Required Support .................................4
80 3.1. Lemonade Submission Servers ................................4
81 3.2. Lemonade Message Stores ....................................5
82 3.3. Lemonade Message Delivery Agents ...........................7
83 4. Lemonade Submission Servers .....................................7
84 4.1. Forward without Download ...................................7
85 4.2. Pipelining .................................................8
86 4.3. DSN Support ................................................8
87 4.4. Message Size Declaration ...................................8
88 4.5. Enhanced Status Code Support ...............................8
89 4.6. Encryption and Compression .................................8
90 5. Lemonade Message Stores .........................................9
91 5.1. Quick Resynchronization ....................................9
92 5.2. Message Part Handling ......................................9
93 5.3. Compression ...............................................10
94 5.4. Notifications .............................................10
95 5.5. Searching and View Filters ................................12
96 5.6. Mailbox Handling ..........................................12
97 5.7. Forward without Download ..................................12
98 5.8. Additional IMAP Extensions ................................13
99 5.9. Registration of $Forwarded IMAP Keyword ...................13
100 5.10. Registration of $SubmitPending and $Submitted
101 IMAP Keywords ............................................13
102 5.11. Related IMAP Extensions ..................................14
103 6. Lemonade Message Delivery Agents ...............................14
104 7. Lemonade Message User Agents ...................................15
105 8. Forward without Download .......................................16
106 8.1. Motivations ...............................................16
107 8.2. Message Sending Overview ..................................16
108 8.3. Traditional Strategy ......................................17
109 8.4. A New Strategy ............................................18
110 8.5. Security Considerations for Pawn-Tickets ..................27
114Cridland, et al. Standards Track [Page 2]
116RFC 5550 Lemonade Profile August 2009
119 8.6. Copies of Sent Messages: The fcc Problem ..................27
120 9. Deployment Considerations ......................................28
121 10. Security Considerations .......................................28
122 10.1. Confidentiality Protection of Submitted Messages .........28
123 10.2. TLS ......................................................29
124 10.3. Additional Extensions and Deployment Models ..............29
125 11. IANA Considerations ...........................................30
126 12. Changes since RFC 4550 ........................................30
127 13. Acknowledgements ..............................................31
128 14. References ....................................................31
129 14.1. Normative References .....................................31
130 14.2. Informative References ...................................35
131 Appendix A. Errata ..............................................37
135 The Lemonade Profile, or simply Lemonade, provides enhancements to
136 Internet email to support diverse service environments. Lemonade
137 mail servers provide both a Lemonade Submission Server and a Lemonade
138 Message Store, which are based on the existing [SUBMIT] and [IMAP]
139 protocols, respectively. They MAY also include a Lemonade Message
140 Delivery Agent, which provides delivery-time filtering services based
143 This document describes the Lemonade Profile that includes:
145 o General common enhancements to Internet Mail, described in 5 and
148 o "Forward without download" that describes exchanges between
149 Lemonade clients and servers to allow submitting new email
150 messages incorporating content that resides on locations external
151 to the client, described in Section 8.
153 o Quick mailbox resynchronization, described in Section 5.1.
155 o Extensions to support more precise, and broader, notifications
156 from the store in support of notifications and view filters,
157 described in 5.4.1 and 5.5.
159 o Delivery-time filtering in support of typical mail management use
160 cases, as described in Section 3.3.
162 The LEMONADE WG used the architecture shown in [LEMONADE-ARCH] to
163 develop the Lemonade Profile.
170Cridland, et al. Standards Track [Page 3]
172RFC 5550 Lemonade Profile August 2009
175 It is intended that the Lemonade Profile support realizations of the
176 OMA's mobile email enabler (MEM) (see [OMA-MEM-REQ] and
177 [OMA-MEM-ARCH]) using Internet Mail protocols defined by the IETF.
1792. Conventions Used in This Document
181 In examples, "M:", "I:", and "S:" indicate lines sent by the client
182 Message User Agent, IMAP email server, and SMTP submit server,
185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
187 document are to be interpreted as described in [KEYWORDS].
189 Other capitalized words are typically names of extensions or commands
190 -- these are uppercased for clarity only, and are case-insensitive.
192 This document uses terminology defined in [RFC5598]. See [RFC5598]
193 for further details on Email Architecture.
195 All examples in this document are optimized for Lemonade use and
196 might not represent examples of proper protocol usage for a general
197 use Submit/IMAP client. In particular, examples assume that Submit
198 and IMAP servers support all Lemonade extensions described in this
199 document, so they do not demonstrate fallbacks in the absence of an
2023. Summary of the Required Support
2043.1. Lemonade Submission Servers
206 Lemonade Submission Servers MUST provide a service as described in
207 [SUBMIT], and MUST support the following. Note that the Lemonade
208 Profile imposes further requirements for some cases, detailed in the
226Cridland, et al. Standards Track [Page 4]
228RFC 5550 Lemonade Profile August 2009
231 +---------------------+--------------------+--------------+
232 | SMTP extension | Reference | Requirements |
233 +---------------------+--------------------+--------------+
234 | 8BITMIME | [SMTP-8BITMIME] | [SMTP-BURL] |
235 | AUTH | [SMTP-AUTH] | [SUBMIT] |
236 | BINARYMIME | [SMTP-BINARYMIME] | Section 4.1 |
237 | BURL imap | [SMTP-BURL] | Section 8 |
238 | CHUNKING | [SMTP-BINARYMIME] | Section 4.1 |
239 | DSN | [SMTP-DSN] | Section 4.3 |
240 | ENHANCEDSTATUSCODES | [SMTP-STATUSCODES] | Section 4.5 |
241 | PIPELINING | [SMTP-PIPELINING] | Section 4.2 |
242 | SIZE | [SMTP-SIZE] | Section 4.4 |
243 | STARTTLS | [SMTP-TLS] | Section 4.6 |
244 +---------------------+--------------------+--------------+
2463.2. Lemonade Message Stores
248 Lemonade Message Stores MUST provide a service as described in
249 [IMAP], and MUST support the following. Note that the Lemonade
250 Profile imposes further requirements for some cases, detailed in the
282Cridland, et al. Standards Track [Page 5]
284RFC 5550 Lemonade Profile August 2009
287 +------------------------+------------------+---------------+
288 | IMAP extension | Reference | Requirements |
289 +------------------------+------------------+---------------+
290 | BINARY | [IMAP-BINARY] | Section 5.2 |
291 | CATENATE | [IMAP-CATENATE] | Section 5.7 |
292 | COMPRESS=DEFLATE | [IMAP-COMPRESS] | Section 5.3 |
293 | CONDSTORE | [IMAP-CONDSTORE] | Section 5.1 |
294 | CONTEXT=SEARCH | [IMAP-CONTEXT] | Section 5.5 |
295 | CONTEXT=SORT | [IMAP-CONTEXT] | Section 5.5 |
296 | CONVERT | [IMAP-CONVERT] | Section 5.2 |
297 | ENABLE | [IMAP-ENABLE] | Section 5.1 |
298 | ESEARCH | [IMAP-ESEARCH] | Section 5.5 |
299 | ESORT | [IMAP-CONTEXT] | Section 5.5 |
300 | I18NLEVEL=1 | [IMAP-I18N] | Section 5.8 |
301 | IDLE | [IMAP-IDLE] | Section 5.4.1 |
302 | LITERAL+ | [IMAP-LITERAL+] | Section 5.8 |
303 | NAMESPACE | [IMAP-NAMESPACE] | Section 5.6 |
304 | NOTIFY | [IMAP-NOTIFY] | Section 5.4.1 |
305 | QRESYNC | [IMAP-QRESYNC] | Section 5.1 |
306 | SASL-IR | [IMAP-SASL-IR] | Section 5.8 |
307 | SORT | [IMAP-SORT] | Section 5.5 |
308 | STARTTLS | [IMAP] | - |
309 | UIDPLUS | [IMAP-UIDPLUS] | Section 5.7 |
310 | URLAUTH | [IMAP-URLAUTH] | Section 5.7 |
311 | URL-PARTIAL | Section 5.7.1 | Section 5.7 |
312 | $Forwarded keyword | - | Section 5.9 |
313 | $SubmitPending keyword | - | Section 5.10 |
314 | $Submitted keyword | - | Section 5.10 |
315 +------------------------+------------------+---------------+
317 In addition to this list, any Lemonade Message Stores MUST send the
318 CAPABILITY response code (see Section 7.1 of [IMAP]) in the initial
319 server greeting and after the LOGIN/AUTHENTICATE commands.
338Cridland, et al. Standards Track [Page 6]
340RFC 5550 Lemonade Profile August 2009
3433.3. Lemonade Message Delivery Agents
345 Lemonade Message Delivery Agents MUST support Sieve mail filtering
346 language as described in [SIEVE], and MUST support the following
347 Sieve extensions. Note that the Lemonade Profile imposes further
348 requirements for some cases, detailed in the sections cited.
350 +------------------------------+--------------------+--------------+
351 | Sieve extension | Reference | Requirements |
352 +------------------------------+--------------------+--------------+
353 | ENOTIFY | [SIEVE-NOTIFY] | Section 6 |
354 | IMAP4FLAGS | [SIEVE-IMAP4FLAGS] | Section 6 |
355 | RELATIONAL | [SIEVE-RELATIONAL] | Section 6 |
356 | VACATION | [SIEVE-VACATION] | Section 6 |
357 | VARIABLES | [SIEVE-VARIABLES] | Section 6 |
358 | comparator-i;unicode-casemap | [UNICODE-CASEMAP] | Section 6 |
359 +------------------------------+--------------------+--------------+
361 Lemonade Message Delivery Agents should also consider supporting a
362 Sieve script management protocol, such as [MANAGESIEVE].
3644. Lemonade Submission Servers
366 All Lemonade Submission Servers implement the Mail Submission
367 protocol described in [SUBMIT], which is in turn a specific profile
368 of [ESMTP]. Therefore, any MUA designed to submit email via [SUBMIT]
369 or [ESMTP] will interoperate with Lemonade Submission Servers.
371 In addition, Lemonade Submission Servers implement the following set
372 of SMTP and Submission extensions to increase message submission
3754.1. Forward without Download
377 In order to optimize network usage for the typical case where message
378 content is copied to, or sourced from, the IMAP store, Lemonade
379 provides support for a suite of extensions collectively known as
380 "forward without download", discussed in detail in Section 8.
382 Lemonade Submission Servers MUST support BURL [SMTP-BURL], 8BITMIME
383 [SMTP-8BITMIME], BINARYMIME [SMTP-BINARYMIME], and CHUNKING
384 [SMTP-BINARYMIME] SMTP extensions.
386 BURL MUST support URLAUTH type URLs [IMAP-URLAUTH], and thus MUST
387 advertise the "imap" option following the BURL EHLO keyword (see
388 [SMTP-BURL] for more details).
394Cridland, et al. Standards Track [Page 7]
396RFC 5550 Lemonade Profile August 2009
401 Some clients regularly use networks with a relatively high latency,
402 such as mobile or satellite-based networks. Avoidance of round trips
403 within a transaction has a great advantage for the reduction in both
404 bandwidth and total transaction time. For this reason, Lemonade-
405 compliant mail Submission Servers MUST support the SMTP service
406 extensions for command pipelining [SMTP-PIPELINING].
410 Lemonade-compliant mail Submission Servers MUST support SMTP service
411 extensions for delivery status notifications [SMTP-DSN].
4134.4. Message Size Declaration
415 There is a distinct advantage in detecting failure cases as early as
416 possible in many cases, such as where the user is charged per octet,
417 or where bandwidth is low. This is especially true of large message
420 Lemonade Submission Servers MUST support the SMTP service extension
421 for message size declaration [SMTP-SIZE].
423 Lemonade Submission Servers MUST expand all BURL parts before
424 evaluating if the supplied message size is acceptable.
426 A Lemonade-capable client SHOULD use message size declaration. In
427 particular, the client MUST NOT send a message to a mail Submission
428 Server if it knows that the message exceeds the maximal message size
429 advertised by the Submission Server. When including a message size
430 in the MAIL FROM command, the client MUST use a value that is at
431 least as large as the size of the assembled message data after
432 resolution of all BURL parts.
4344.5. Enhanced Status Code Support
436 Lemonade-compliant mail Submission Servers MUST support the SMTP
437 service extension for returning enhanced error codes
438 [SMTP-STATUSCODES]. These allow a client to determine the precise
4414.6. Encryption and Compression
443 Lemonade-compliant mail Submission Servers MUST support the SMTP
444 service extension for secure SMTP over Transport Layer Security (TLS)
450Cridland, et al. Standards Track [Page 8]
452RFC 5550 Lemonade Profile August 2009
455 Support for the DEFLATE compression method, as described in
456 [TLS-COMP], is RECOMMENDED.
4585. Lemonade Message Stores
460 All Lemonade Message Stores implement the Internet Message Access
461 Protocol, as defined in [IMAP]. Therefore, any MUA written to access
462 messages using the facilities described in [IMAP] will interoperate
463 with a Lemonade Message Store.
465 In addition, Lemonade Message Stores provide a set of extensions to
466 address the limitations of some clients and networks.
4685.1. Quick Resynchronization
470 Resynchronization is a costly part of an IMAP session, and mobile
471 networks are generally more prone to unintended disconnection, which
472 in turn makes this problem more acute. Therefore, Lemonade Message
473 Stores provide a suite of extensions to reduce the synchronization
476 Lemonade-compliant IMAP servers MUST support the CONDSTORE
477 [IMAP-CONDSTORE], the QRESYNC [IMAP-QRESYNC], and the ENABLE
478 [IMAP-ENABLE] extensions. These allow a client to quickly
479 resynchronize any mailbox by asking the server to return all flag
480 changes and expunges that have occurred since a previously recorded
481 state. This can also speed up client reconnect in case the transport
482 layer is cut, whether accidentally or as part of a change in network.
484 When implementing QRESYNC [IMAP-QRESYNC], client and servers need to
485 also comply with errata submitted for this document (see Appendix A).
487 [IMAP-SYNC-HOWTO] details how clients perform efficient mailbox
4905.2. Message Part Handling
492 The handling of message parts, especially attachments, represents a
493 set of challenges to limited devices, both in terms of the bandwidth
494 used and the capability of the device.
496 Lemonade-compliant IMAP servers MUST support the BINARY [IMAP-BINARY]
497 extension. This moves MIME body part decoding operations from the
498 client to the server. The decoded data is equal to or less in size
499 than the encoded representation, so this reduces bandwidth
506Cridland, et al. Standards Track [Page 9]
508RFC 5550 Lemonade Profile August 2009
511 [IMAP-BINARY] allows for servers to refuse to accept uploaded
512 messages containing binary data, by not accepting the Binary content-
513 transfer-encoding; however, Lemonade-compliant IMAP servers SHALL
514 always accept binary encoded MIME messages in APPEND commands for any
517 [IMAP-CONVERT] MUST also be supported by servers, which allows
518 clients to request conversions between media types, and allows for
519 scaling images, etc. This provides the ability to view attachments
520 (and sometimes body parts) without the facility to cope with a wide
521 range of media types, or to efficiently view attachments.
525 Lemonade Message Stores SHOULD support the Deflate compression
526 algorithm for TLS, as defined in [TLS-COMP], in order to facilitate
527 compression at as low a level as possible.
529 However, the working group acknowledges that for many endpoints, this
530 is a rarely deployed technology, and as such, Lemonade Message Stores
531 MUST provide [IMAP-COMPRESS] support for fallback application-level
532 stream compression, where TLS is not actively providing compression.
536 The addition of server-to-client notifications transforms the
537 Lemonade Profile into an event-based synchronization protocol.
538 Whenever an event occurs that interests the MUA, a notification can
539 be generated. The Lemonade WG used the notifications architecture
540 shown in [LEMONADE-NOTIFICATIONS] to develop the Lemonade Profile.
542 If the MUA is connected to the IMAP server, inband notifications are
543 generated using the facilities outlined in Section 5.4.1.
545 When the MUA is not connected, the notification filter generates an
546 outband notification. The notification filter may be considered as
547 acting on a push email repository.
549 If the MUA is not connected, and outband notification is disabled,
550 the client must perform a quick-sync on reconnect to determine
551 mailbox changes, using the mechanisms outlined in Section 5.1.
562Cridland, et al. Standards Track [Page 10]
564RFC 5550 Lemonade Profile August 2009
5675.4.1. IMAP Notifications
569 Lemonade Message Stores MUST support the IDLE [IMAP-IDLE] extension.
570 The extension allows clients to receive unsolicited notifications
571 about changes in the selected mailbox, without needing to poll for
572 changes. The responses forming these notifications MUST be sent in a
573 timely manner when such changes happen.
575 Lemonade Message Stores also provide the NOTIFY extension described
576 in [IMAP-NOTIFY], which allows clients to request specific event
577 types to be sent immediately to the client, both for the currently
578 selected folder and others. Such event types include message
579 delivery and mailbox renames.
5815.4.2. External Notifications
583 Lemonade and TCP provide for long-lived idle connections between the
584 client and mail store, allowing the server to push notifications
585 within IMAP. Some mobile networks support dormancy, which shuts down
586 the radio traffic channel during idle periods to conserve handset and
587 network resources, while maintaining IP and TCP state. (See the
588 [LEMONADE-DEPLOYMENTS] document for more information.)
590 However, there are environments where the email client cannot remain
591 active indefinitely, or where it is not advisable (or even always
592 possible) for TCP connections to the server to remain up while idle
593 for extended periods. In these situations, a good user experience
594 requires that when "interesting" events occur in the mail store, the
595 client be informed so that it can connect and resynchronize. At an
596 absolute minimum, this requires that at least the arrival of new mail
597 generate some sort of wake-up to the email client. A number of
598 vendors have implemented various solutions to this. As examples of
599 what has been done, for many years (long pre-dating cellular
600 handsets) the technique described in [FINGER-HACK] has been
601 supported. Today, a number of email vendors include facilities to
602 send SMS or other simple non-stream messages to clients on handsets
603 when new mail arrives. The Open Mobile Alliance (OMA) has published
604 a mechanism that uses WAP PUSH to send a basic message containing a
605 URL [OMA-EMN]. The IETF is investigating ways to standardize
606 enhanced functionality in this area.
608 A "push email" user experience can be achieved using any number of
609 techniques, ranging from always-on TCP connectivity to the server and
610 the NOTIFY extension described above, to OMA EMN, or even a non-
611 standard trigger message over SMS. In any technique, the client
612 learns of the existence of new mail, and decides to fetch information
613 about it, some part of it, or all of it, and then presents this to
618Cridland, et al. Standards Track [Page 11]
620RFC 5550 Lemonade Profile August 2009
6235.5. Searching and View Filters
625 Lemonade Message Stores MUST support the ESEARCH [IMAP-ESEARCH]
626 extension. The extension allows clients to efficiently find the
627 first or last messages, find a count of matching messages, and obtain
628 a list of matching messages in a considerably more compact
631 Lemonade Message Stores also provide a mechanism for clients to avoid
632 handling an entire mailbox, instead accessing a view of the mailbox.
633 This technique, common in many desktop clients as a client-side
634 capability, is useful for constrained clients to minimize the
635 quantity of messages and notification data.
637 Lemonade Message Stores therefore MUST implement the CONTEXT=SEARCH,
638 ESORT, and CONTEXT=SORT extensions defined in [IMAP-CONTEXT], as well
639 as the SORT extension defined in [IMAP-SORT].
643 Lemonade Message Stores MUST support the NAMESPACE [IMAP-NAMESPACE]
644 extension. The extension allows clients to discover shared mailboxes
645 and mailboxes belonging to other users, and provide a normalized
646 hierarchy view of the mailboxes available.
648 Lemonade Message Stores MUST support the I18NLEVEL=<n> [IMAP-I18N]
649 extension, with <n> having the value 1 or 2. It adds support for
650 non-English (internationalized) search and sort functions. (Note
651 that I18NLEVEL=2 implies support for I18NLEVEL=1, so a Lemonade-
652 compliant client that makes use of this extension MUST recognize
6555.7. Forward without Download
657 In order to optimize network usage for the typical case where message
658 content is copied to, or sourced from, the IMAP store, Lemonade
659 provides support for a suite of extensions collectively known as
660 "forward without download", discussed in detail in Section 8.
662 Lemonade Message Stores MUST support CATENATE [IMAP-CATENATE],
663 UIDPLUS [IMAP-UIDPLUS], and URLAUTH [IMAP-URLAUTH]. Lemonade Message
664 Stores MUST also support URL-PARTIAL as described in Section 5.7.1.
6665.7.1. Support for PARTIAL in CATENATE and URLAUTH
668 [IMAP-URL] introduced a new syntactic element for referencing a byte
669 range of a message/body part. This is done using the ;PARTIAL=
670 field. If an IMAP server supports PARTIAL in IMAP URL used in
674Cridland, et al. Standards Track [Page 12]
676RFC 5550 Lemonade Profile August 2009
679 CATENATE and URLAUTH extensions, then it MUST advertise the URL-
680 PARTIAL capability in both the CAPABILITY response and the equivalent
6835.8. Additional IMAP Extensions
685 Lemonade Message Stores MUST support the LITERAL+ [IMAP-LITERAL+]
686 extension. The extension allows clients to save a round trip each
687 time a non-synchronizing literal is sent.
689 Lemonade Message Stores MUST also implement the SASL-IR
690 [IMAP-SASL-IR] extension, which allows clients to save a round trip
691 during authentication, potentially pipelining the entire
692 authentication sequence.
694 Lemonade-compliant IMAP servers MUST support IMAP over TLS [IMAP] as
695 required by [IMAP]. As noted above in Section 5.3, servers SHOULD
696 support the deflate compression algorithm for TLS, as specified in
6995.9. Registration of $Forwarded IMAP Keyword
701 The $Forwarded IMAP keyword is used by several IMAP clients to
702 specify that the marked message was forwarded to another email
703 address, embedded within or attached to a new message. A mail client
704 sets this keyword when it successfully forwards the message to
705 another email address. Typical usage of this keyword is to show a
706 different (or additional) icon for a message that has been forwarded.
707 Once set, the flag SHOULD NOT be cleared.
709 Lemonade Message Stores MUST be able to store the $Forwarded keyword.
710 They MUST preserve it on the COPY operation. The servers MUST
711 support the SEARCH KEYWORD $Forwarded.
7135.10. Registration of $SubmitPending and $Submitted IMAP Keywords
715 The $SubmitPending IMAP keyword designates the message as awaiting to
716 be submitted. This keyword allows storing messages waiting to be
717 submitted in the same mailbox where messages that were already
718 submitted and/or are being edited are stored. A mail client sets
719 this keyword when it decides that the message needs to be sent out.
720 When a client (it might be a different client from the one that
721 decided that the message is pending submission) starts sending the
722 message, it atomically (using "STORE (UNCHANGEDSINCE)") adds the
723 $Submitted keyword. Once submission is successful, the
724 $SubmitPending keyword is atomically cleared. The two keywords allow
725 messages being actively submitted (messages that have both $Submitted
726 and $SubmitPending keywords set) to be distinguished from messages
730Cridland, et al. Standards Track [Page 13]
732RFC 5550 Lemonade Profile August 2009
735 awaiting to be submitted, or from messages already submitted. They
736 also allow all messages that were supposed to be submitted to be
737 found, if the client submitting them crashes or quits before
740 Lemonade Message Stores MUST be able to store the $SubmitPending and
741 the $Submitted keyword. Lemonade Message Stores MUST preserve them
742 on the COPY operation. The servers MUST support the SEARCH KEYWORD
743 $SubmitPending and SEARCH KEYWORD $Submitted.
7455.11. Related IMAP Extensions
747 Section 5.11 is non-normative.
749 Server implementations targeting to fulfill OMA MEM requirements
750 [OMA-MEM-REQ] should consider implementing the [IMAP-FILTERS], which
751 provides a way to persist definition of virtual mailboxes on the
752 server. They should also consider implementing the METADATA-SERVER
753 [METADATA] extension, which provides a way of storing user-defined
754 data associated with a user account.
7566. Lemonade Message Delivery Agents
758 Lemonade Message Delivery Agents MUST support the [SIEVE] filtering
759 language at the point of delivery, allowing the user to control which
760 messages are accepted, and where they are filed.
762 Lemonade Message Delivery Agents MUST support the Sieve Vacation
763 extension [SIEVE-VACATION], which allows the client to set up an
764 auto-responder, typically to report being on vacation (thus the name
765 of the Sieve extension).
767 Lemonade Message Delivery Agents MUST support the Sieve Enotify
768 extension [SIEVE-NOTIFY], which allows a Sieve script to generate
769 notifications (such as XMPP, SIP, or email) about received messages.
771 Lemonade Message Delivery Agents MUST support the Sieve Variables
772 extension [SIEVE-VARIABLES], which adds support for variables to the
773 Sieve scripting language. This extension is typically used with
774 Sieve Enotify or Vacation to customize responses/notifications.
776 Lemonade Message Delivery Agents MUST support the Sieve Relational
777 extension [SIEVE-RELATIONAL], which adds support for relational
778 comparisons to the Sieve scripting language. This extension is
779 typically used together with Sieve Enotify.
786Cridland, et al. Standards Track [Page 14]
788RFC 5550 Lemonade Profile August 2009
791 Lemonade Message Delivery Agents MUST support the Sieve Imap4Flags
792 extension [SIEVE-IMAP4FLAGS], which allows a Sieve script to set IMAP
793 flags/keywords when delivering a message to a mailbox. For example,
794 this can be used to automatically mark certain messages as
795 interesting, urgent, etc.
797 Lemonade Message Delivery Agents MUST support the i;unicode-casemap
798 comparator in Sieve [UNICODE-CASEMAP], which is declared as
799 "comparator-i;unicode-casemap" in the Sieve "require" statement. The
800 comparator allows for case-insensitive matching of Unicode
803 Lemonade Message Delivery Agents should consider supporting Sieve
804 script management using the [MANAGESIEVE] protocol. If they do, they
805 MUST also advertise in [MANAGESIEVE] all Sieve extensions listed in
8087. Lemonade Message User Agents
810 Although all existing IMAP MUAs are Lemonade compliant in as much as
811 all Lemonade services are based on the existing [IMAP] and [SUBMIT]
812 protocols, client implementors are encouraged to take full advantage
813 of the facilities provided by Lemonade Submission Servers and
814 Lemonade Message Stores, as described in 4 and 5, respectively.
816 When opening a connection to the Submission Server, clients MUST do
817 so using port 587 unless explicitly configured to use an alternate
818 port [RFC5068]. (Note that this requirement is somewhat stronger
819 than the one specified in [SUBMIT], as [SUBMIT] didn't prescribe the
820 exact procedure to be used by submission clients.) If the TCP
821 connection to the submission server fails to open using port 587, the
822 client MAY then immediately retry using a different port, such as 25.
823 See [SUBMIT] for information on why using port 25 is likely to fail
824 depending on the current location of the client, and may result in a
825 failure code during the SMTP transaction.
827 In addition, some specifications are useful to support interoperable
828 messaging with an enhanced user experience.
830 Lemonade-capable clients SHOULD support the Format and DelSp
831 parameters to the text/plain media type described in [FLOWED], and
832 generate this format for messages.
834 Lemonade-capable clients SHOULD support, and use, the $Forwarded
835 keyword described in Section 5.9.
842Cridland, et al. Standards Track [Page 15]
844RFC 5550 Lemonade Profile August 2009
8478. Forward without Download
851 The advent of client/server email using the [IMAP] and [SUBMIT]
852 protocols changed what formerly were local disk operations to become
853 repetitive network data transmissions.
855 Lemonade "forward without download" makes use of the [SMTP-BURL]
856 extension to enable access to external sources during the submission
857 of a message. In combination with the [IMAP-URLAUTH] extension,
858 inclusion of message parts or even entire messages from the IMAP mail
859 store is possible with a minimal trust relationship between the IMAP
860 and SMTP SUBMIT servers.
862 Lemonade "forward without download" has the advantage of maintaining
863 one submission protocol, and thus avoids the risk of having multiple
864 parallel and possibly divergent mechanisms for submission. The
865 client can use [SUBMIT] extensions without these being added to IMAP.
866 Furthermore, by keeping the details of message submission in the SMTP
867 SUBMIT server, Lemonade "forward without download" can work with
868 other message retrieval protocols such as POP, NNTP, or whatever else
869 may be designed in the future.
8718.2. Message Sending Overview
873 The act of sending an email message can be thought of as involving
874 multiple steps: initiation of a new draft, draft editing, message
875 assembly, and message submission.
877 Initiation of a new draft and draft editing takes place in the MUA.
878 Frequently, users choose to save more complex messages on an [IMAP]
879 server (via the APPEND command with the \Draft flag) for later recall
880 by the MUA and resumption of the editing process.
882 Message assembly is the process of producing a complete message from
883 the final revision of the draft and external sources. At assembly
884 time, external data is retrieved and inserted in the message.
886 Message submission is the process of inserting the assembled message
887 into the [ESMTP] infrastructure, typically using the [SUBMIT]
898Cridland, et al. Standards Track [Page 16]
900RFC 5550 Lemonade Profile August 2009
9038.3. Traditional Strategy
905 Traditionally, messages are initiated, edited, and assembled entirely
906 within an MUA, although drafts may be saved to an [IMAP] server and
907 later retrieved from the server. The completed text is then
908 transmitted to a Message Submission Agent (MSA) for delivery.
910 There is often no clear boundary between the editing and assembly
911 processes. If a message is forwarded, its content is often retrieved
912 immediately and inserted into the message text. Similarly, when
913 external content is inserted or attached, the content is usually
914 retrieved immediately and made part of the draft.
916 As a consequence, each save of a draft and subsequent retrieval of
917 the draft transmits that entire (possibly large) content, as does
920 In the past, this was not much of a problem, because drafts, external
921 data, and the message submission mechanism were typically located on
922 the same system as the MUA. The most common problem was running out
954Cridland, et al. Standards Track [Page 17]
956RFC 5550 Lemonade Profile August 2009
961 The model distinguishes between a Message User Agent (MUA), an
962 IMAPv4Rev1 Server ([IMAP]), and an SMTP submit server ([SUBMIT]), as
963 illustrated in Figure 1.
965 +--------------------+ +--------------+
966 | | <------------ | |
967 | MUA (M) | | IMAPv4Rev1 |
969 | | ------------> | (Server I) |
970 +--------------------+ +--------------+
979 | |----------------------> | SMTP |
981 |-----------------------------| Server |
985 Figure 1: Lemonade "forward without download"
987 Lemonade "forward without download" allows a Message User Agent to
988 compose and forward an email combining fragments that are located in
989 an IMAP server, without having to download these fragments to the
992 This section informatively describes two ways to perform "forward
993 without download" based on where the message assembly takes place.
994 The first uses the extended APPEND command [IMAP-CATENATE] to edit a
995 draft message in the message store and cause the message assembly on
996 the IMAP server. This is most often used when a copy of the message
997 is to be retained on the IMAP server, as discussed in Section 8.6.
999 The second uses a succession of BURL and BDAT commands to submit and
1000 assemble through concatenation, message data from the client and
1001 external data fetched from the provided URL. The two subsequent
1002 sections provide step-by-step instructions on how "forward without
1003 download" is achieved.
1010Cridland, et al. Standards Track [Page 18]
1012RFC 5550 Lemonade Profile August 2009
10158.4.1. Message Assembly Using IMAP CATENATE Extension
1017 In the [SMTP-BURL]/[IMAP-CATENATE] variant of the Lemonade "forward
1018 without download" strategy, messages are initially composed and
1019 edited within an MUA. The [IMAP-CATENATE] extension to [IMAP] is
1020 then used to create the messages on the IMAP server by transmitting
1021 new text and assembling them. The UIDPLUS [IMAP-UIDPLUS] IMAP
1022 extension is used by the client in order to learn the UID of the
1023 created messages. Finally, an [IMAP-URLAUTH] format URL is given to
1024 a [SUBMIT] server for submission using the BURL [SMTP-BURL]
1027 The flow involved to support such a use case consists of:
1029 M: {to I -- Optional} The client connects to the IMAP server,
1030 optionally starts TLS (if data confidentiality is required),
1031 authenticates, opens a mailbox ("INBOX" in the example below), and
1032 fetches body structures (see [IMAP]).
1036 M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
1037 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
1038 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
1039 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
1041 "<960723163407.20117h@washington.example.com>"
1042 "Your trip details" "BASE64" 4554 73) "MIXED"))
1043 I: A0051 OK completed
1045 M: {to I} The client invokes CATENATE (see [IMAP-CATENATE] for
1046 details of the semantics and steps) -- this allows the MUA to create
1047 messages on the IMAP server using new data combined with one or more
1048 message parts already present on the IMAP server.
1050 Note that the example for this step doesn't use the LITERAL+
1051 [IMAP-LITERAL+] extension. Without LITERAL+ the new message is
1052 constructed using three round trips. If LITERAL+ is used, the new
1053 message can be constructed using one round trip.
1066Cridland, et al. Standards Track [Page 19]
1068RFC 5550 Lemonade Profile August 2009
1071 M: A0052 APPEND Sent FLAGS (\Draft \Seen $MDNSent)
1072 CATENATE (TEXT {475}
1073 I: + Ready for literal data
1074 M: Message-ID: <419399E1.6000505@caernarfon.example.org>
1075 M: Date: Thu, 12 Nov 2004 16:57:05 +0000
1076 M: From: Bob Ar <bar@example.org>
1077 M: MIME-Version: 1.0
1078 M: To: foo@example.net
1079 M: Subject: About our holiday trip
1080 M: Content-Type: multipart/mixed;
1081 M: boundary="------------030308070208000400050907"
1083 M: --------------030308070208000400050907
1084 M: Content-Type: text/plain; format=flowed
1086 M: Our travel agent has sent the updated schedule.
1090 M: --------------030308070208000400050907
1091 M: URL "/INBOX;UIDVALIDITY=385759045/;
1092 UID=25627/;Section=2.MIME" URL "/INBOX;
1093 UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44}
1094 I: + Ready for literal data
1096 M: --------------030308070208000400050907--
1098 I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed
1100 M: {to I} The client uses the GENURLAUTH command to request a URLAUTH
1101 URL (see [IMAP-URLAUTH]).
1102 I: {to M} The IMAP server returns a URLAUTH URL suitable for later
1103 retrieval with URLFETCH (see [IMAP-URLAUTH] for details of the
1104 semantics and steps).
1106 M: A0053 GENURLAUTH "imap://bob.ar@example.org/Sent;
1107 UIDVALIDITY=387899045/;uid=45;expire=2005-10-
1108 28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
1109 I: * GENURLAUTH "imap://bob.ar@example.org/Sent;
1110 UIDVALIDITY=387899045/;uid=45;expire=
1111 2005-10-28T23:59:59Z;urlauth=submit+bob.ar:
1112 internal:91354a473744909de610943775f92038"
1113 I: A0053 OK GENURLAUTH completed
1115 M: {to S} The client connects to the mail Submission Server and
1116 starts a new mail transaction. It uses BURL to let the SMTP submit
1117 server fetch the content of the message from the IMAP server (see
1118 [IMAP-URLAUTH] for details of the semantics and steps -- this allows
1122Cridland, et al. Standards Track [Page 20]
1124RFC 5550 Lemonade Profile August 2009
1127 the MUA to authorize the SMTP submit server to access the message
1128 composed as a result of the CATENATE step). Note that the second
1129 EHLO command is required after a successful STARTTLS command. Also
1130 note that there might be a third required EHLO command if the second
1131 EHLO response doesn't list any BURL options. Section 8.4.2
1134 S: 220 owlry.example.org ESMTP
1135 M: EHLO potter.example.org
1136 S: 250-owlry.example.com
1144 S: 250-SIZE 10240000
1146 S: 250 ENHANCEDSTATUSCODES
1148 S: 220 Ready to start TLS
1149 ...TLS negotiation, subsequent data is encrypted...
1150 M: EHLO potter.example.org
1151 S: 250-owlry.example.com
1159 S: 250-SIZE 10240000
1160 S: 250 ENHANCEDSTATUSCODES
1161 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
1162 M: MAIL FROM:<bob.ar@example.org>
1163 M: RCPT TO:<foo@example.net>
1164 S: 235 2.7.0 PLAIN authentication successful.
1165 S: 250 2.5.0 Address Ok.
1166 S: 250 2.1.5 foo@example.net OK.
1167 M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;
1168 uid=45/;urlauth=submit+bar:internal:
1169 91354a473744909de610943775f92038 LAST
1171 S: {to I} The mail Submission Server uses URLFETCH to fetch the
1172 message to be sent. (See [IMAP-URLAUTH] for details of the semantics
1173 and steps. The so-called "pawn-ticket" authorization mechanism uses
1174 a URI that contains its own authorization credentials.)
1178Cridland, et al. Standards Track [Page 21]
1180RFC 5550 Lemonade Profile August 2009
1183 I: {to S} Provides the message composed as a result of the CATENATE
1186 The mail Submission Server opens an IMAP connection to the IMAP
1189 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
1190 CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
1193 I: a000 Start TLS negotiation now
1194 ...TLS negotiation, if successful - subsequent data
1196 S: a001 LOGIN submitserver secret
1197 I: a001 OK submitserver logged in
1198 S: a002 URLFETCH "imap://bob.ar@example.org/Sent;
1199 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
1200 internal:91354a473744909de610943775f92038"
1201 I: * URLFETCH "imap://bob.ar@example.org/Sent;
1202 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
1203 internal:91354a473744909de610943775f92038" {15065}
1204 ...message body follows...
1205 I: a002 OK URLFETCH completed
1207 I: * BYE See you later
1208 I: a003 OK Logout successful
1210 Note that if data confidentiality is not required, the mail
1211 Submission Server may omit the STARTTLS command before issuing the
1214 S: {to M} Submission server assembles the complete message; if the
1215 assembly succeeds, it returns OK to the MUA:
1219 M: {to I} The client marks the message containing the forwarded
1220 attachment on the IMAP server.
1222 M: A0054 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
1223 I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
1224 I: A0054 OK STORE completed
1226 Note: the UID STORE command shown above will only work if the marked
1227 message is in the currently selected mailbox; otherwise, it requires
1228 a SELECT. This command can be omitted, as it simply changes non-
1229 operational metadata not essential to client operations or
1234Cridland, et al. Standards Track [Page 22]
1236RFC 5550 Lemonade Profile August 2009
1239 interoperability. The untagged FETCH response is due to
1240 [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in
12438.4.2. Message Assembly Using SMTP CHUNKING and BURL Extensions
1245 In the [IMAP-URLAUTH]/[SMTP-BURL] variant of the Lemonade "forward
1246 without download" strategy, messages are initially composed and
1247 edited within an MUA. During submission [SUBMIT], BURL [SMTP-BURL]
1248 and BDAT [SMTP-BINARYMIME] commands are used to create the messages
1249 from multiple parts. New body parts are supplied using BDAT
1250 commands, while existing body parts are referenced using
1251 [IMAP-URLAUTH] format URLs in BURL commands.
1253 The flow involved to support such a use case consists of:
1254 M: {to I -- Optional} The client connects to the IMAP server,
1255 optionally starts TLS (if data confidentiality is required),
1256 authenticates, opens a mailbox ("INBOX" in the example below), and
1257 fetches body structures (see [IMAP]).
1261 M: B0051 UID FETCH 25627 (UID BODYSTRUCTURE)
1262 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
1263 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
1264 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
1266 "<960723163407.20117h@washington.example.com>"
1267 "Your trip details" "BASE64" 4554 73) "MIXED"))
1268 I: B0051 OK completed
1270 M: {to I} The client uses the GENURLAUTH command to request URLAUTH
1271 URLs (see [IMAP-URLAUTH]) referencing pieces of the message to be
1273 I: {to M} The IMAP server returns URLAUTH URLs suitable for later
1274 retrieval with URLFETCH (see [IMAP-URLAUTH] for details of the
1275 semantics and steps).
1290Cridland, et al. Standards Track [Page 23]
1292RFC 5550 Lemonade Profile August 2009
1295 M: B0052 GENURLAUTH "imap://bob.ar@example.org/INBOX;
1296 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
1297 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar"
1298 INTERNAL "imap://bob.ar@example.org/INBOX;
1299 UIDVALIDITY=385759045/;UID=25627/;Section=2;
1300 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
1301 I: * GENURLAUTH "imap://bob.ar@example.org/INBOX;
1302 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
1303 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
1304 internal:A0DEAD473744909de610943775f9BEEF"
1305 "imap://bob.ar@example.org/INBOX;
1306 UIDVALIDITY=385759045/;UID=25627/;Section=2;
1307 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
1308 internal:BEEFA0DEAD473744909de610943775f9"
1309 I: B0052 OK GENURLAUTH completed
1311 M: {to S} The client connects to the mail Submission Server and
1312 starts a new mail transaction. It uses BURL to instruct the SMTP
1313 submit server to fetch from the IMAP server pieces of the message to
1314 be sent (see [SMTP-BURL] for details of the semantics and steps).
1316 Note that the second EHLO command is required after a successful
1317 STARTTLS command. The third EHLO command is required if and only if
1318 the second EHLO response doesn't list any BURL options. See
1319 Section 8.4.1 for an example of submission where the third EHLO
1320 command/response is not present.
1322 S: 220 owlry.example.org ESMTP
1323 M: EHLO potter.example.org
1324 S: 250-owlry.example.com
1330 S: 250-AUTH DIGEST-MD5
1332 S: 250-SIZE 10240000
1334 S: 250 ENHANCEDSTATUSCODES
1336 S: 220 Ready to start TLS
1337 ...TLS negotiation, subsequent data is encrypted...
1338 M: EHLO potter.example.org
1339 S: 250-owlry.example.com
1346Cridland, et al. Standards Track [Page 24]
1348RFC 5550 Lemonade Profile August 2009
1353 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
1355 S: 250-SIZE 10240000
1356 S: 250 ENHANCEDSTATUSCODES
1357 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
1358 S: 235 2.7.0 PLAIN authentication successful.
1359 M: EHLO potter.example.org
1360 S: 250-owlry.example.com
1364 S: 250-BURL imap imap://imap.example.org
1366 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
1368 S: 250-SIZE 10240000
1369 S: 250 ENHANCEDSTATUSCODES
1370 M: MAIL FROM:<bob.ar@example.org> BODY=BINARY
1371 S: 250 2.5.0 Address Ok.
1372 M: RCPT TO:<foo@example.net>
1373 S: 250 2.1.5 foo@example.net OK.
1375 M: Message-ID: <419399E1.6000505@caernarfon.example.org>
1376 M: Date: Thu, 12 Nov 2004 16:57:05 +0000
1377 M: From: Bob Ar <bar@example.org>
1378 M: MIME-Version: 1.0
1379 M: To: foo@example.net
1380 M: Subject: About our holiday trip
1381 M: Content-Type: multipart/mixed;
1382 M: boundary="------------030308070208000400050907"
1384 M: --------------030308070208000400050907
1385 M: Content-Type: text/plain; format=flowed
1387 M: Our travel agent has sent the updated schedule.
1391 M: --------------030308070208000400050907
1393 M: BURL imap://bob.ar@example.org/INBOX;
1394 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
1395 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
1396 internal:A0DEAD473744909de610943775f9BEEF
1398 M: BURL imap://bob.ar@example.org/INBOX;
1402Cridland, et al. Standards Track [Page 25]
1404RFC 5550 Lemonade Profile August 2009
1407 UIDVALIDITY=385759045/;UID=25627/;Section=2;
1408 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
1409 internal:BEEFA0DEAD473744909de610943775f9
1413 M: --------------030308070208000400050907--
1415 S: {to I} The mail Submission Server uses URLFETCH to fetch the
1416 pieces of the message to be sent. (See [SMTP-BURL] for details of
1417 the semantics and steps. The so-called "pawn-ticket" authorization
1418 mechanism uses a URI which contains its own authorization
1420 I: {to S} Returns the requested body parts.
1422 The mail Submission Server opens an IMAP connection to the IMAP
1425 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
1426 CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
1429 I: b000 Start TLS negotiation now
1430 ...TLS negotiation, if successful - subsequent data
1432 S: b001 LOGIN submitserver secret
1433 I: b001 OK submitserver logged in
1434 S: b002 URLFETCH "imap://bob.ar@example.org/INBOX;
1435 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
1436 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
1437 internal:A0DEAD473744909de610943775f9BEEF" "imap://
1438 bob.ar@example.org/INBOX;
1439 UIDVALIDITY=385759045/;UID=25627/;Section=2;
1440 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
1441 internal:BEEFA0DEAD473744909de610943775f9"
1442 I: * URLFETCH "imap://bob.ar@example.org/INBOX;
1443 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
1444 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
1445 internal:A0DEAD473744909de610943775f9BEEF" {84}
1446 ...message section follows...
1447 "imap://bob.ar@example.org/INBOX;
1448 UIDVALIDITY=385759045/;UID=25627/;Section=2;
1449 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
1450 internal:BEEFA0DEAD473744909de610943775f9" {15065}
1451 ...message section follows...
1452 I: b002 OK URLFETCH completed
1454 I: * BYE See you later
1458Cridland, et al. Standards Track [Page 26]
1460RFC 5550 Lemonade Profile August 2009
1463 I: b003 OK Logout successful
1465 Note that if data confidentiality is not required, the mail
1466 Submission Server may omit the STARTTLS command before issuing the
1469 S: {to M} Submission Server assembles the complete message; if the
1470 assembly succeeds, it acknowledges acceptance of the message by
1471 sending 250 response to the last BDAT command:
1473 S: 250 2.5.0 Ok, message accepted.
1475 M: {to I} The client marks the message containing the forwarded
1476 attachment on the IMAP server.
1478 M: B0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
1479 I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
1480 I: B0053 OK STORE completed
1482 Note: the UID STORE command shown above will only work if the marked
1483 message is in the currently selected mailbox; otherwise, it requires
1484 a SELECT. As in the previous example, this command is not critical,
1485 and can be omitted. The untagged FETCH response is due to
1486 [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in
14898.5. Security Considerations for Pawn-Tickets
1491 The so-called "pawn-ticket" authorization mechanism uses a URI, which
1492 contains its own authorization credentials using [IMAP-URLAUTH]. The
1493 advantage of this mechanism is that the SMTP submit [SUBMIT] server
1494 cannot access any data on the [IMAP-URLAUTH] server without a "pawn-
1495 ticket" created by the client.
1497 The "pawn-ticket" grants access only to the specific data that the
1498 SMTP submit [SUBMIT] server is authorized to access, can be revoked
1499 by the client, and can have a time-limited validity.
15018.6. Copies of Sent Messages: The fcc Problem
1503 The "fcc problem" refers to delivering a copy of a message to a
1504 mailbox, or "file carbon copy". By far, the most common case of fcc
1505 is a client leaving a copy of outgoing mail in a "Sent Mail" or
1508 In the traditional strategy, the MUA duplicates the effort spent in
1509 transmitting to the MSA by writing the message to the fcc destination
1510 in a separate step. This may be a write to a local disk file or an
1514Cridland, et al. Standards Track [Page 27]
1516RFC 5550 Lemonade Profile August 2009
1519 APPEND to a mailbox on an IMAP server. The latter is one of the
1520 "repetitive network data transmissions" that represents the "problem"
1521 aspect of the "fcc problem".
1523 The BURL [SMTP-BURL] extension can be used to eliminate the
1524 additional transmission. The final message is uploaded to the
1525 mailbox designed for outgoing mail by the APPEND command of [IMAP].
1526 Note that when doing so, the client ought to use the $SubmitPending
1527 and $Submitted IMAP keywords described in Section 5.10. Also note
1528 that APPEND, including when enhanced by [IMAP-CATENATE], can only
1529 create a single copy of the message and this is only of use on the
1530 server that stages the outgoing message for submission. Additional
1531 copies of the message on the same server can be created by using one
1532 or more COPY commands.
15349. Deployment Considerations
1536 Deployment considerations are discussed extensively in
1537 [LEMONADE-DEPLOYMENTS].
153910. Security Considerations
1541 Implementors are advised to examine the security considerations of
1542 all the referenced documents. This section merely highlights these,
1543 and advises implementors on specific issues relating to the
1544 combination of extensions.
1546 Security considerations on Lemonade "forward without download" are
1547 discussed throughout Section 8. Additional security considerations
1548 can be found in [IMAP], [SUBMIT], [SIEVE], and other documents
1549 describing other SMTP, IMAP, and Sieve extension comprising the
1552 Note that the mandatory-to-implement authentication mechanism for
1553 SMTP submission is described in [SMTP-AUTH]. The mandatory-to-
1554 implement authentication mechanism for IMAP is described in [IMAP].
155610.1. Confidentiality Protection of Submitted Messages
1558 When clients submit new messages, link protection such as [TLS]
1559 guards against an eavesdropper seeing the contents of the submitted
1560 message. It is worth noting, however, that even if TLS is not used,
1561 the security risks are no worse if BURL is used to reference the text
1562 than if the text is submitted directly. If BURL is not used, an
1563 eavesdropper gains access to the full text of the message. If BURL
1564 is used, the eavesdropper may or may not be able to gain such access,
1570Cridland, et al. Standards Track [Page 28]
1572RFC 5550 Lemonade Profile August 2009
1575 depending on the form of BURL used. For example, some forms restrict
1576 use of the URL to an entity authorized as a Submission Server or a
1581 When Lemonade clients use the BURL extension for mail submission, an
1582 extension that requires sending a URLAUTH token to the mail
1583 Submission Server, such a token should be protected from interception
1584 to avoid a replay attack that may disclose the contents of the
1585 message to an attacker. [TLS]-based encryption of both the IMAP
1586 session that issues GENURLAUTH and the mail submission path will
1587 provide protection against this attack.
1589 Lemonade-compliant mail Submission Servers SHOULD use TLS-protected
1590 IMAP connections when fetching message content using the URLAUTH
1591 token provided by the Lemonade client.
1593 When a client uses SMTP STARTTLS to send a BURL command that
1594 references non-public information, there is a user expectation that
1595 the entire message content will be treated confidentially. To meet
1596 this expectation, the message Submission Server SHOULD use STARTTLS
1597 or a mechanism providing equivalent data confidentiality when
1598 fetching the content referenced by that URL.
160010.3. Additional Extensions and Deployment Models
1602 This specification provides no additional security measures beyond
1603 those in the referenced Internet Mail and Lemonade documents.
1605 We note, however, the security risks associated with:
1607 o Outband notifications
1609 o Server configuration by client
1611 o Client configuration by server
1613 o Presence of proxy servers
1615 o Presence of servers as intermediaries
1617 o In general, the deployment models considered by OMA MEM that are
1618 not conventional IETF deployment models
1620 o Measures to address a perceived need to traverse firewalls and
1621 mobile network intermediaries
1626Cridland, et al. Standards Track [Page 29]
1628RFC 5550 Lemonade Profile August 2009
1631 Deployments that provide these additional services or operate in
1632 these environments need to consult the security considerations for
1633 the relevant standards and organizational security practices.
163511. IANA Considerations
1637 IMAP4 capabilities are registered by IETF Review, as defined in
1638 [RFC5226]. This document defines the URL-PARTIAL IMAP capability
1639 (Section 5.7.1). IANA added this extension to the IANA IMAP
1640 Capability registry.
164212. Changes since RFC 4550
1644 When compared to RFC 4550, this document adds the following
1645 additional requirements on a Lemonade compliant IMAP server:
1647 IMAP extensions: BINARY, COMPRESS=DEFLATE, CONTEXT=SEARCH,
1648 CONTEXT=SORT, CONVERT, ENABLE, ESEARCH, ESORT, I18NLEVEL=1,
1649 NOTIFY, QRESYNC, SASL-IR, SORT, URL-PARTIAL;
1651 IMAP keywords: $SubmitPending, $Submitted.
1653 Other requirements: Require any Lemonade compliant IMAP server to
1654 support the CAPABILITY response code.
1656 When compared to RFC 4550, this document adds the following new
1657 requirements on a Lemonade compliant Message Delivery Agents:
1659 Support for the Sieve filtering language, together with the following
1662 ENOTIFY, IMAP4FLAGS, RELATIONAL, VACATION, VARIABLES, comparator-
1665 When compared to RFC 4550, this document recommends use of the
1666 DEFLATE compression method for TLS. All other requirements remain
1669 Additionally, the following changes/improvments were done to RFC 4550
1670 (the list might be incomplete):
1672 A new section with some additional requirements on Lemonade Mail
1673 User Agents was added, in particular they are required to support
1674 Format=flowed parameter to the text/plain media type.
1676 Usage of the $Forwarded IMAP keyword was clarified.
1678 Forward-without-download examples were corrected and extended.
1682Cridland, et al. Standards Track [Page 30]
1684RFC 5550 Lemonade Profile August 2009
1687 Added a new section describing in-band and out-of-band
1688 notifications from a Lemonade compliant mailstore.
1692 The editors acknowledge and appreciate the work and comments of the
1693 IETF Lemonade working group and the OMA MEM working group.
1695 In particular, the editors would like to thank Eric Burger, Glenn
1696 Parsons, Randall Gellens, Filip Navara, Zoltan Ordogh, Greg
1697 Vaudreuil, and Fan Xiaohui for their comments and reviews.
170114.1. Normative References
1703 [FLOWED] Gellens, R., "The Text/Plain Format and DelSp Parameters",
1704 RFC 3676, February 2004.
1706 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
1707 4rev1", RFC 3501, March 2003.
1710 Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
1714 Resnick, P., "Internet Message Access Protocol (IMAP)
1715 CATENATE Extension", RFC 4469, April 2006.
1718 Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978,
1722 Melnikov, A. and S. Hole, "IMAP Extension for Conditional
1723 STORE Operation or Quick Flag Changes Resynchronization",
1724 RFC 4551, June 2006.
1727 Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
1731 Melnikov, A. and P. Coates, "Internet Message Access
1732 Protocol - CONVERT Extension", RFC 5259, July 2008.
1738Cridland, et al. Standards Track [Page 31]
1740RFC 5550 Lemonade Profile August 2009
1744 Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE
1745 Extension", RFC 5161, March 2008.
1748 Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
1749 Command for Controlling What Kind of Information Is
1750 Returned", RFC 4731, November 2006.
1753 Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
1754 Message Access Protocol Internationalization", RFC 5255,
1758 Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
1761 Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
1765 Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
1769 Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
1770 NOTIFY Extension", RFC 5465, February 2009.
1773 Melnikov, A., Cridland, D., and C. Wilson, "IMAP4
1774 Extensions for Quick Mailbox Resynchronization", RFC 5162,
1778 Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
1779 Simple Authentication and Security Layer (SASL) Initial
1780 Client Response", RFC 4959, September 2007.
1783 Crispin, M. and K. Murchison, "Internet Message Access
1784 Protocol - SORT and THREAD Extensions", RFC 5256,
1788 Crispin, M., "Internet Message Access Protocol (IMAP) -
1789 UIDPLUS extension", RFC 4315, December 2005.
1794Cridland, et al. Standards Track [Page 32]
1796RFC 5550 Lemonade Profile August 2009
1800 Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092,
1804 Crispin, M., "Internet Message Access Protocol (IMAP) -
1805 URLAUTH Extension", RFC 4467, May 2006.
1808 Bradner, S., "Key words for use in RFCs to Indicate
1809 Requirement Levels", BCP 14, RFC 2119, March 1997.
1811 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
1812 Language", RFC 5228, January 2008.
1815 Melnikov, A., "Sieve Email Filtering: Imap4flags
1816 Extension", RFC 5232, January 2008.
1819 Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
1820 "Sieve Email Filtering: Extension for Notifications",
1821 RFC 5435, January 2009.
1824 Segmuller, W. and B. Leiba, "Sieve Email Filtering:
1825 Relational Extension", RFC 5231, January 2008.
1828 Showalter, T. and N. Freed, "Sieve Email Filtering:
1829 Vacation Extension", RFC 5230, January 2008.
1832 Homme, K., "Sieve Email Filtering: Variables Extension",
1833 RFC 5229, January 2008.
1836 Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
1837 Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
1838 RFC 1652, July 1994.
1841 Siemborski, R. and A. Melnikov, "SMTP Service Extension
1842 for Authentication", RFC 4954, July 2007.
1850Cridland, et al. Standards Track [Page 33]
1852RFC 5550 Lemonade Profile August 2009
1856 Vaudreuil, G., "SMTP Service Extensions for Transmission
1857 of Large and Binary MIME Messages", RFC 3030,
1861 Newman, C., "Message Submission BURL Extension", RFC 4468,
1865 Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
1866 Extension for Delivery Status Notifications (DSNs)",
1867 RFC 3461, January 2003.
1870 Freed, N., "SMTP Service Extension for Command
1871 Pipelining", STD 60, RFC 2920, September 2000.
1874 Klensin, J., Freed, N., and K. Moore, "SMTP Service
1875 Extension for Message Size Declaration", STD 10, RFC 1870,
1879 Freed, N., "SMTP Service Extension for Returning Enhanced
1880 Error Codes", RFC 2034, October 1996.
1883 Hoffman, P., "SMTP Service Extension for Secure SMTP over
1884 the Transport Layer Security", RFC 3207, February 2002.
1886 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail",
1887 RFC 4409, April 2006.
1889 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
1890 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1893 Hollenbeck, S., "Transport Layer Security Protocol
1894 Compression Methods", RFC 3749, May 2004.
1897 Crispin, M., "i;unicode-casemap - Simple Unicode Collation
1898 Algorithm", RFC 5051, October 2007.
1906Cridland, et al. Standards Track [Page 34]
1908RFC 5550 Lemonade Profile August 2009
191114.2. Informative References
1913 [ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1916 [Err1807] RFC Errata, Errata ID 1807, RFC 5162,
1917 <http://www.rfc-editor.org>.
1919 [Err1808] RFC Errata, Errata ID 1808, RFC 5162,
1920 <http://www.rfc-editor.org>.
1922 [Err1809] RFC Errata, Errata ID 1809, RFC 5162,
1923 <http://www.rfc-editor.org>.
1925 [Err1810] RFC Errata, Errata ID 1810, RFC 5162,
1926 <http://www.rfc-editor.org>.
1929 Gellens, R., "Simple New Mail Notification", RFC 4146,
1933 Melnikov, A. and C. King, "IMAP4 Extension for Named
1934 Searches (Filters)", RFC 5466, February 2009.
1937 Melnikov, A., "Synchronization Operations for Disconnected
1938 IMAP4 Clients", RFC 4549, June 2006.
1941 Burger, E. and G. Parsons, "LEMONADE Architecture -
1942 Supporting Open Mobile Alliance (OMA) Mobile Email (MEM)
1943 Using Internet Mail", RFC 5442, March 2009.
1945 [LEMONADE-DEPLOYMENTS]
1946 Gellens, R., "Deployment Considerations for Lemonade-
1947 Compliant Mobile Email", BCP 143, RFC 5383, October 2008.
1949 [LEMONADE-NOTIFICATIONS]
1950 Gellens, R., Ed., "Lemonade Notifications Architecture",
1951 RFC 5551, August 2009.
1954 Melnikov, A. and T. Martin, "A Protocol for Remotely
1955 Managing Sieve Scripts", Work in Progress, September 2008.
1962Cridland, et al. Standards Track [Page 35]
1964RFC 5550 Lemonade Profile August 2009
1968 Daboo, C., "The IMAP METADATA Extension", RFC 5464,
1971 [OMA-EMN] Open Mobile Alliance, "Open Mobile Alliance Email
1972 Notification Version 1.0", OMA http://
1973 www.openmobilealliance.org/Technical/release_program/
1974 emn_v10.aspx, October 2007.
1977 Open Mobile Alliance, "Mobile Email Architecture
1978 Document", OMA (Work in Progress),
1979 http://www.openmobilealliance.org/, October 2005.
1982 Open Mobile Alliance, "Mobile Email Requirements
1983 Document", OMA http://www.openmobilealliance.org/
1984 release_program/docs/RD/
1985 OMA-RD-MobileEmail-V1_0_20051018-C.pdf, Oct 2005.
1987 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T.
1988 Finch, "Email Submission Operations: Access and
1989 Accountability Requirements", BCP 134, RFC 5068,
1992 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1993 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1996 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
2018Cridland, et al. Standards Track [Page 36]
2020RFC 5550 Lemonade Profile August 2009
2025 Errata ID: 1807 [Err1807]
2030 Reported By: Timo Sirainen
2031 Date Reported: 2009-07-14
2032 Verifier Name: Alexey Melnikov
2033 Date Verified: 2009-07-18
2039 Once a "CONDSTORE enabling command" is issued by the client, the
2040 server MUST automatically include both UID and mod-sequence data in
2041 all subsequent untagged FETCH responses (until the connection is
2042 closed), whether they were caused by a regular STORE/UID STORE, a
2043 STORE/UID STORE with UNCHANGEDSINCE modifier, or an external agent.
2044 Note that this rule doesn't affect untagged FETCH responses caused by
2045 a FETCH command that doesn't include UID and/or MODSEQ FETCH data
2046 item, or UID FETCH without the MODSEQ FETCH data item.
2052 It's very difficult for clients to make use of unsolicited FETCH
2053 responses without the UID field. This is made even worse by the text
2054 that says "servers SHOULD NOT send UIDs for previously expunged
2055 messages [in VANISHED replies]". Since it's not a MUST NOT, a
2056 conversation with an RFC compliant server could be for example:
2063 * VANISHED 1000:2000
2064 * 3 FETCH (FLAGS (\Seen) MODSEQ (14749))
2065 * 5 FETCH (FLAGS (\Seen) MODSEQ (14749))
2066 * VANISHED 2000:3000
2067 A2 OK NOOP Completed
2069 The client couldn't do anything with the information from FETCH
2070 replies, because it can't know what messages they refer to.
2074Cridland, et al. Standards Track [Page 37]
2076RFC 5550 Lemonade Profile August 2009
2079 Errata ID: 1808 [Err1808]
2084 Reported By: Timo Sirainen
2085 Date Reported: 2009-07-14
2086 Verifier Name: Alexey Melnikov
2087 Date Verified: 2009-07-18
2091 If at least one message got expunged, the server MUST send
2092 the updated per-mailbox modification
2093 sequence using the HIGHESTMODSEQ response code (defined in
2094 [CONDSTORE]) in the tagged OK response.
2096 Example: C: A202 CLOSE
2097 S: A202 OK [HIGHESTMODSEQ 20010715194045319] done
2101 The server MUST NOT send the updated per-mailbox modification
2102 sequence using the HIGHESTMODSEQ response code (defined in
2103 [CONDSTORE]) in the tagged OK response, as this might cause loss of
2104 synchronization on the client.
2106 Example: C: A202 CLOSE
2113 The HIGHESTMODSEQ can't be used reliably unless server sends to client
2114 all changes done by other clients. Even then it's difficult for both
2115 clients and servers to implement this. For example:
2117 C1: 2 STORE 1 +FLAGS.SILENT \Deleted
2118 S1: * 1 FETCH (MODSEQ 1)
2121 C2: 1 STORE 2 +FLAGS.SILENT \Deleted
2122 S1: * 2 FETCH (MODSEQ 2)
2126 S1: 3 [HIGHESTMODSEQ 3]
2130Cridland, et al. Standards Track [Page 38]
2132RFC 5550 Lemonade Profile August 2009
2135 The client probably thought that only message 1 was expunged, so it
2136 doesn't register the second expunge. And it probably never will if it
2137 uses QRESYNC to find out only about new expunges.
2139 And even worse example would be if the second client had also removed
2140 the \Deleted flag from message 1. Then the first client would have
2141 registered wrong message to be expunged.
2144 Errata ID: 1809 [Err1809]
2149 Reported By: Timo Sirainen
2150 Date Reported: 2009-07-14
2151 Verifier Name: Alexey Melnikov
2152 Date Verified: 2009-07-18
2156 After completing a full synchronization, the client MUST also take
2157 note of any unsolicited MODSEQ FETCH data items received from the
2158 server. Whenever the client receives a tagged response to a command,
2159 it calculates the highest value among all MODSEQ FETCH data items
2160 received since the last tagged response. If this value is bigger
2161 than the client's copy of the HIGHESTMODSEQ value, then the client
2162 MUST use this value as its new HIGHESTMODSEQ value.
2164 Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
2165 value with a MODSEQ FETCH data item value as soon as it is received
2166 because servers are not required to send MODSEQ FETCH data items in
2167 increasing modseqence order. This can lead to the client missing
2168 some changes in case of connectivity loss.
2172 After completing a full synchronization, the client MUST also take
2173 note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ
2174 response codes received from the server. Whenever the client receives
2175 a tagged response to a command, it checks the received unsolicited
2176 responses to calculate the new HIGHESTMODSEQ value. If the
2177 HIGHESTMODSEQ response code is received, the client MUST use it even
2178 if it has seen higher mod-sequences. Otherwise, the client calculates
2179 the highest value among all MODSEQ FETCH data items received since the
2180 last tagged response. If this value is bigger than the client's copy
2181 of the HIGHESTMODSEQ value, then the client MUST use this value as its
2182 new HIGHESTMODSEQ value.
2186Cridland, et al. Standards Track [Page 39]
2188RFC 5550 Lemonade Profile August 2009
2191 Example: C: A1 STORE 1:2 (UNCHANGEDSINCE 96) +FLAGS.SILENT \Seen
2192 S: * 1 FETCH (UID 6 MODSEQ (103))
2193 S: * 2 FETCH (UID 7 MODSEQ (101))
2194 S: * OK [HIGHESTMODSEQ 99] VANISHED reply with
2195 MODSEQ 100 is delayed
2196 S: A1 OK [MODIFIED 3] done
2198 C: A2 STORE 3 +FLAGS.SILENT \Seen
2199 S: * 3 FETCH (UID 8 MODSEQ (104))
2200 S: A2 OK [HIGHESTMODSEQ 99] Still delaying VANISHED
2204 S: A3 OK [HIGHESTMODSEQ 104] done
2206 Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
2207 value with a MODSEQ FETCH data item value as soon as it is received
2208 because servers are not required to send MODSEQ FETCH data items in
2209 increasing modseqence order. Some commands may also delay EXPUNGE
2210 (or VANISHED) replies with smaller mod-sequences. These can lead to
2211 the client missing some changes in case of connectivity loss.
2217 Otherwise clients could lose changes in case of connectivity loss.
2219 Errata ID: 1810 [Err1810]
2224 Reported By: Timo Sirainen
2225 Date Reported: 2009-07-14
2226 Verifier Name: Alexey Melnikov
2227 Date Verified: 2009-07-18
2233 Server implementing QRESYNC MUST send untagged events to client in a
2234 way that client doesn't lose any changes in case of connectivity loss.
2235 In particular this means that if server sends MODSEQ FETCH data items
2236 while EXPUNGE (or VANISHED) replies with lower mod-sequences are being
2237 delayed, the server MUST send HIGHESTMODSEQ response code with a lower
2238 value than the EXPUNGE's mod-sequence. See example in section 5.
2242Cridland, et al. Standards Track [Page 40]
2244RFC 5550 Lemonade Profile August 2009
2249 This is related to the other errata in section 5, which describes what
2250 the client's behavior should be. This describes what the server's
2251 behavior should be. Would have been nice to put them into the same
2252 section, but that probably would require larger changes.
2256 Dave Cridland (editor)
2258 5 Castle Business Village
2260 Hampton, Middlesex TW12 2BX
2263 EMail: dave.cridland@isode.com
2266 Alexey Melnikov (editor)
2268 5 Castle Business Village
2270 Hampton, Middlesex TW12 2BX
2273 EMail: Alexey.Melnikov@isode.com
2276 Stephane H. Maes (editor)
2278 MS 4op634, 500 Oracle Parkway
2279 Redwood Shores, CA 94539
2282 Phone: +1-203-300-7786
2283 EMail: stephane.maes@oracle.com
2298Cridland, et al. Standards Track [Page 41]