From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5550.txt | 2299 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2299 insertions(+) create mode 100644 doc/rfc/rfc5550.txt (limited to 'doc/rfc/rfc5550.txt') diff --git a/doc/rfc/rfc5550.txt b/doc/rfc/rfc5550.txt new file mode 100644 index 0000000..6c4bb59 --- /dev/null +++ b/doc/rfc/rfc5550.txt @@ -0,0 +1,2299 @@ + + + + + + +Network Working Group D. Cridland, Ed. +Request for Comments: 5550 A. Melnikov, Ed. +Obsoletes: 4550 Isode Limited +Updates: 4469, 4467 S. Maes, Ed. +Category: Standards Track Oracle + August 2009 + + + The Internet Email to + Support Diverse Service Environments (Lemonade) Profile + +Abstract + + This document describes a profile (a set of required extensions, + restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail + submission, and Sieve protocols. This profile allows clients + (especially those that are constrained in memory, bandwidth, + processing power, or other areas) to efficiently use IMAP and + Submission to access and submit mail. This includes the ability to + forward received mail without needing to download and upload the + mail, to optimize submission, and to efficiently resynchronize in + case of loss of connectivity with the server. + + The Lemonade Profile relies upon several extensions to IMAP, Sieve, + and Mail Submission protocols. The document also defines a new IMAP + extension and registers several new IMAP keywords. + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + + + + + +Cridland, et al. Standards Track [Page 1] + +RFC 5550 Lemonade Profile August 2009 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions Used in This Document ...............................4 + 3. Summary of the Required Support .................................4 + 3.1. Lemonade Submission Servers ................................4 + 3.2. Lemonade Message Stores ....................................5 + 3.3. Lemonade Message Delivery Agents ...........................7 + 4. Lemonade Submission Servers .....................................7 + 4.1. Forward without Download ...................................7 + 4.2. Pipelining .................................................8 + 4.3. DSN Support ................................................8 + 4.4. Message Size Declaration ...................................8 + 4.5. Enhanced Status Code Support ...............................8 + 4.6. Encryption and Compression .................................8 + 5. Lemonade Message Stores .........................................9 + 5.1. Quick Resynchronization ....................................9 + 5.2. Message Part Handling ......................................9 + 5.3. Compression ...............................................10 + 5.4. Notifications .............................................10 + 5.5. Searching and View Filters ................................12 + 5.6. Mailbox Handling ..........................................12 + 5.7. Forward without Download ..................................12 + 5.8. Additional IMAP Extensions ................................13 + 5.9. Registration of $Forwarded IMAP Keyword ...................13 + 5.10. Registration of $SubmitPending and $Submitted + IMAP Keywords ............................................13 + 5.11. Related IMAP Extensions ..................................14 + 6. Lemonade Message Delivery Agents ...............................14 + 7. Lemonade Message User Agents ...................................15 + 8. Forward without Download .......................................16 + 8.1. Motivations ...............................................16 + 8.2. Message Sending Overview ..................................16 + 8.3. Traditional Strategy ......................................17 + 8.4. A New Strategy ............................................18 + 8.5. Security Considerations for Pawn-Tickets ..................27 + + + +Cridland, et al. Standards Track [Page 2] + +RFC 5550 Lemonade Profile August 2009 + + + 8.6. Copies of Sent Messages: The fcc Problem ..................27 + 9. Deployment Considerations ......................................28 + 10. Security Considerations .......................................28 + 10.1. Confidentiality Protection of Submitted Messages .........28 + 10.2. TLS ......................................................29 + 10.3. Additional Extensions and Deployment Models ..............29 + 11. IANA Considerations ...........................................30 + 12. Changes since RFC 4550 ........................................30 + 13. Acknowledgements ..............................................31 + 14. References ....................................................31 + 14.1. Normative References .....................................31 + 14.2. Informative References ...................................35 + Appendix A. Errata ..............................................37 + +1. Introduction + + The Lemonade Profile, or simply Lemonade, provides enhancements to + Internet email to support diverse service environments. Lemonade + mail servers provide both a Lemonade Submission Server and a Lemonade + Message Store, which are based on the existing [SUBMIT] and [IMAP] + protocols, respectively. They MAY also include a Lemonade Message + Delivery Agent, which provides delivery-time filtering services based + on [SIEVE]. + + This document describes the Lemonade Profile that includes: + + o General common enhancements to Internet Mail, described in 5 and + 4. + + o "Forward without download" that describes exchanges between + Lemonade clients and servers to allow submitting new email + messages incorporating content that resides on locations external + to the client, described in Section 8. + + o Quick mailbox resynchronization, described in Section 5.1. + + o Extensions to support more precise, and broader, notifications + from the store in support of notifications and view filters, + described in 5.4.1 and 5.5. + + o Delivery-time filtering in support of typical mail management use + cases, as described in Section 3.3. + + The LEMONADE WG used the architecture shown in [LEMONADE-ARCH] to + develop the Lemonade Profile. + + + + + + +Cridland, et al. Standards Track [Page 3] + +RFC 5550 Lemonade Profile August 2009 + + + It is intended that the Lemonade Profile support realizations of the + OMA's mobile email enabler (MEM) (see [OMA-MEM-REQ] and + [OMA-MEM-ARCH]) using Internet Mail protocols defined by the IETF. + +2. Conventions Used in This Document + + In examples, "M:", "I:", and "S:" indicate lines sent by the client + Message User Agent, IMAP email server, and SMTP submit server, + respectively. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [KEYWORDS]. + + Other capitalized words are typically names of extensions or commands + -- these are uppercased for clarity only, and are case-insensitive. + + This document uses terminology defined in [RFC5598]. See [RFC5598] + for further details on Email Architecture. + + All examples in this document are optimized for Lemonade use and + might not represent examples of proper protocol usage for a general + use Submit/IMAP client. In particular, examples assume that Submit + and IMAP servers support all Lemonade extensions described in this + document, so they do not demonstrate fallbacks in the absence of an + extension. + +3. Summary of the Required Support + +3.1. Lemonade Submission Servers + + Lemonade Submission Servers MUST provide a service as described in + [SUBMIT], and MUST support the following. Note that the Lemonade + Profile imposes further requirements for some cases, detailed in the + sections cited. + + + + + + + + + + + + + + + + +Cridland, et al. Standards Track [Page 4] + +RFC 5550 Lemonade Profile August 2009 + + + +---------------------+--------------------+--------------+ + | SMTP extension | Reference | Requirements | + +---------------------+--------------------+--------------+ + | 8BITMIME | [SMTP-8BITMIME] | [SMTP-BURL] | + | AUTH | [SMTP-AUTH] | [SUBMIT] | + | BINARYMIME | [SMTP-BINARYMIME] | Section 4.1 | + | BURL imap | [SMTP-BURL] | Section 8 | + | CHUNKING | [SMTP-BINARYMIME] | Section 4.1 | + | DSN | [SMTP-DSN] | Section 4.3 | + | ENHANCEDSTATUSCODES | [SMTP-STATUSCODES] | Section 4.5 | + | PIPELINING | [SMTP-PIPELINING] | Section 4.2 | + | SIZE | [SMTP-SIZE] | Section 4.4 | + | STARTTLS | [SMTP-TLS] | Section 4.6 | + +---------------------+--------------------+--------------+ + +3.2. Lemonade Message Stores + + Lemonade Message Stores MUST provide a service as described in + [IMAP], and MUST support the following. Note that the Lemonade + Profile imposes further requirements for some cases, detailed in the + sections cited. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cridland, et al. Standards Track [Page 5] + +RFC 5550 Lemonade Profile August 2009 + + + +------------------------+------------------+---------------+ + | IMAP extension | Reference | Requirements | + +------------------------+------------------+---------------+ + | BINARY | [IMAP-BINARY] | Section 5.2 | + | CATENATE | [IMAP-CATENATE] | Section 5.7 | + | COMPRESS=DEFLATE | [IMAP-COMPRESS] | Section 5.3 | + | CONDSTORE | [IMAP-CONDSTORE] | Section 5.1 | + | CONTEXT=SEARCH | [IMAP-CONTEXT] | Section 5.5 | + | CONTEXT=SORT | [IMAP-CONTEXT] | Section 5.5 | + | CONVERT | [IMAP-CONVERT] | Section 5.2 | + | ENABLE | [IMAP-ENABLE] | Section 5.1 | + | ESEARCH | [IMAP-ESEARCH] | Section 5.5 | + | ESORT | [IMAP-CONTEXT] | Section 5.5 | + | I18NLEVEL=1 | [IMAP-I18N] | Section 5.8 | + | IDLE | [IMAP-IDLE] | Section 5.4.1 | + | LITERAL+ | [IMAP-LITERAL+] | Section 5.8 | + | NAMESPACE | [IMAP-NAMESPACE] | Section 5.6 | + | NOTIFY | [IMAP-NOTIFY] | Section 5.4.1 | + | QRESYNC | [IMAP-QRESYNC] | Section 5.1 | + | SASL-IR | [IMAP-SASL-IR] | Section 5.8 | + | SORT | [IMAP-SORT] | Section 5.5 | + | STARTTLS | [IMAP] | - | + | UIDPLUS | [IMAP-UIDPLUS] | Section 5.7 | + | URLAUTH | [IMAP-URLAUTH] | Section 5.7 | + | URL-PARTIAL | Section 5.7.1 | Section 5.7 | + | $Forwarded keyword | - | Section 5.9 | + | $SubmitPending keyword | - | Section 5.10 | + | $Submitted keyword | - | Section 5.10 | + +------------------------+------------------+---------------+ + + In addition to this list, any Lemonade Message Stores MUST send the + CAPABILITY response code (see Section 7.1 of [IMAP]) in the initial + server greeting and after the LOGIN/AUTHENTICATE commands. + + + + + + + + + + + + + + + + + + +Cridland, et al. Standards Track [Page 6] + +RFC 5550 Lemonade Profile August 2009 + + +3.3. Lemonade Message Delivery Agents + + Lemonade Message Delivery Agents MUST support Sieve mail filtering + language as described in [SIEVE], and MUST support the following + Sieve extensions. Note that the Lemonade Profile imposes further + requirements for some cases, detailed in the sections cited. + + +------------------------------+--------------------+--------------+ + | Sieve extension | Reference | Requirements | + +------------------------------+--------------------+--------------+ + | ENOTIFY | [SIEVE-NOTIFY] | Section 6 | + | IMAP4FLAGS | [SIEVE-IMAP4FLAGS] | Section 6 | + | RELATIONAL | [SIEVE-RELATIONAL] | Section 6 | + | VACATION | [SIEVE-VACATION] | Section 6 | + | VARIABLES | [SIEVE-VARIABLES] | Section 6 | + | comparator-i;unicode-casemap | [UNICODE-CASEMAP] | Section 6 | + +------------------------------+--------------------+--------------+ + + Lemonade Message Delivery Agents should also consider supporting a + Sieve script management protocol, such as [MANAGESIEVE]. + +4. Lemonade Submission Servers + + All Lemonade Submission Servers implement the Mail Submission + protocol described in [SUBMIT], which is in turn a specific profile + of [ESMTP]. Therefore, any MUA designed to submit email via [SUBMIT] + or [ESMTP] will interoperate with Lemonade Submission Servers. + + In addition, Lemonade Submission Servers implement the following set + of SMTP and Submission extensions to increase message submission + efficiency. + +4.1. Forward without Download + + In order to optimize network usage for the typical case where message + content is copied to, or sourced from, the IMAP store, Lemonade + provides support for a suite of extensions collectively known as + "forward without download", discussed in detail in Section 8. + + Lemonade Submission Servers MUST support BURL [SMTP-BURL], 8BITMIME + [SMTP-8BITMIME], BINARYMIME [SMTP-BINARYMIME], and CHUNKING + [SMTP-BINARYMIME] SMTP extensions. + + BURL MUST support URLAUTH type URLs [IMAP-URLAUTH], and thus MUST + advertise the "imap" option following the BURL EHLO keyword (see + [SMTP-BURL] for more details). + + + + + +Cridland, et al. Standards Track [Page 7] + +RFC 5550 Lemonade Profile August 2009 + + +4.2. Pipelining + + Some clients regularly use networks with a relatively high latency, + such as mobile or satellite-based networks. Avoidance of round trips + within a transaction has a great advantage for the reduction in both + bandwidth and total transaction time. For this reason, Lemonade- + compliant mail Submission Servers MUST support the SMTP service + extensions for command pipelining [SMTP-PIPELINING]. + +4.3. DSN Support + + Lemonade-compliant mail Submission Servers MUST support SMTP service + extensions for delivery status notifications [SMTP-DSN]. + +4.4. Message Size Declaration + + There is a distinct advantage in detecting failure cases as early as + possible in many cases, such as where the user is charged per octet, + or where bandwidth is low. This is especially true of large message + sizes. + + Lemonade Submission Servers MUST support the SMTP service extension + for message size declaration [SMTP-SIZE]. + + Lemonade Submission Servers MUST expand all BURL parts before + evaluating if the supplied message size is acceptable. + + A Lemonade-capable client SHOULD use message size declaration. In + particular, the client MUST NOT send a message to a mail Submission + Server if it knows that the message exceeds the maximal message size + advertised by the Submission Server. When including a message size + in the MAIL FROM command, the client MUST use a value that is at + least as large as the size of the assembled message data after + resolution of all BURL parts. + +4.5. Enhanced Status Code Support + + Lemonade-compliant mail Submission Servers MUST support the SMTP + service extension for returning enhanced error codes + [SMTP-STATUSCODES]. These allow a client to determine the precise + cause of failure. + +4.6. Encryption and Compression + + Lemonade-compliant mail Submission Servers MUST support the SMTP + service extension for secure SMTP over Transport Layer Security (TLS) + [SMTP-TLS]. + + + + +Cridland, et al. Standards Track [Page 8] + +RFC 5550 Lemonade Profile August 2009 + + + Support for the DEFLATE compression method, as described in + [TLS-COMP], is RECOMMENDED. + +5. Lemonade Message Stores + + All Lemonade Message Stores implement the Internet Message Access + Protocol, as defined in [IMAP]. Therefore, any MUA written to access + messages using the facilities described in [IMAP] will interoperate + with a Lemonade Message Store. + + In addition, Lemonade Message Stores provide a set of extensions to + address the limitations of some clients and networks. + +5.1. Quick Resynchronization + + Resynchronization is a costly part of an IMAP session, and mobile + networks are generally more prone to unintended disconnection, which + in turn makes this problem more acute. Therefore, Lemonade Message + Stores provide a suite of extensions to reduce the synchronization + cost. + + Lemonade-compliant IMAP servers MUST support the CONDSTORE + [IMAP-CONDSTORE], the QRESYNC [IMAP-QRESYNC], and the ENABLE + [IMAP-ENABLE] extensions. These allow a client to quickly + resynchronize any mailbox by asking the server to return all flag + changes and expunges that have occurred since a previously recorded + state. This can also speed up client reconnect in case the transport + layer is cut, whether accidentally or as part of a change in network. + + When implementing QRESYNC [IMAP-QRESYNC], client and servers need to + also comply with errata submitted for this document (see Appendix A). + + [IMAP-SYNC-HOWTO] details how clients perform efficient mailbox + resynchronization. + +5.2. Message Part Handling + + The handling of message parts, especially attachments, represents a + set of challenges to limited devices, both in terms of the bandwidth + used and the capability of the device. + + Lemonade-compliant IMAP servers MUST support the BINARY [IMAP-BINARY] + extension. This moves MIME body part decoding operations from the + client to the server. The decoded data is equal to or less in size + than the encoded representation, so this reduces bandwidth + effectively. + + + + + +Cridland, et al. Standards Track [Page 9] + +RFC 5550 Lemonade Profile August 2009 + + + [IMAP-BINARY] allows for servers to refuse to accept uploaded + messages containing binary data, by not accepting the Binary content- + transfer-encoding; however, Lemonade-compliant IMAP servers SHALL + always accept binary encoded MIME messages in APPEND commands for any + folder. + + [IMAP-CONVERT] MUST also be supported by servers, which allows + clients to request conversions between media types, and allows for + scaling images, etc. This provides the ability to view attachments + (and sometimes body parts) without the facility to cope with a wide + range of media types, or to efficiently view attachments. + +5.3. Compression + + Lemonade Message Stores SHOULD support the Deflate compression + algorithm for TLS, as defined in [TLS-COMP], in order to facilitate + compression at as low a level as possible. + + However, the working group acknowledges that for many endpoints, this + is a rarely deployed technology, and as such, Lemonade Message Stores + MUST provide [IMAP-COMPRESS] support for fallback application-level + stream compression, where TLS is not actively providing compression. + +5.4. Notifications + + The addition of server-to-client notifications transforms the + Lemonade Profile into an event-based synchronization protocol. + Whenever an event occurs that interests the MUA, a notification can + be generated. The Lemonade WG used the notifications architecture + shown in [LEMONADE-NOTIFICATIONS] to develop the Lemonade Profile. + + If the MUA is connected to the IMAP server, inband notifications are + generated using the facilities outlined in Section 5.4.1. + + When the MUA is not connected, the notification filter generates an + outband notification. The notification filter may be considered as + acting on a push email repository. + + If the MUA is not connected, and outband notification is disabled, + the client must perform a quick-sync on reconnect to determine + mailbox changes, using the mechanisms outlined in Section 5.1. + + + + + + + + + + +Cridland, et al. Standards Track [Page 10] + +RFC 5550 Lemonade Profile August 2009 + + +5.4.1. IMAP Notifications + + Lemonade Message Stores MUST support the IDLE [IMAP-IDLE] extension. + The extension allows clients to receive unsolicited notifications + about changes in the selected mailbox, without needing to poll for + changes. The responses forming these notifications MUST be sent in a + timely manner when such changes happen. + + Lemonade Message Stores also provide the NOTIFY extension described + in [IMAP-NOTIFY], which allows clients to request specific event + types to be sent immediately to the client, both for the currently + selected folder and others. Such event types include message + delivery and mailbox renames. + +5.4.2. External Notifications + + Lemonade and TCP provide for long-lived idle connections between the + client and mail store, allowing the server to push notifications + within IMAP. Some mobile networks support dormancy, which shuts down + the radio traffic channel during idle periods to conserve handset and + network resources, while maintaining IP and TCP state. (See the + [LEMONADE-DEPLOYMENTS] document for more information.) + + However, there are environments where the email client cannot remain + active indefinitely, or where it is not advisable (or even always + possible) for TCP connections to the server to remain up while idle + for extended periods. In these situations, a good user experience + requires that when "interesting" events occur in the mail store, the + client be informed so that it can connect and resynchronize. At an + absolute minimum, this requires that at least the arrival of new mail + generate some sort of wake-up to the email client. A number of + vendors have implemented various solutions to this. As examples of + what has been done, for many years (long pre-dating cellular + handsets) the technique described in [FINGER-HACK] has been + supported. Today, a number of email vendors include facilities to + send SMS or other simple non-stream messages to clients on handsets + when new mail arrives. The Open Mobile Alliance (OMA) has published + a mechanism that uses WAP PUSH to send a basic message containing a + URL [OMA-EMN]. The IETF is investigating ways to standardize + enhanced functionality in this area. + + A "push email" user experience can be achieved using any number of + techniques, ranging from always-on TCP connectivity to the server and + the NOTIFY extension described above, to OMA EMN, or even a non- + standard trigger message over SMS. In any technique, the client + learns of the existence of new mail, and decides to fetch information + about it, some part of it, or all of it, and then presents this to + the user. + + + +Cridland, et al. Standards Track [Page 11] + +RFC 5550 Lemonade Profile August 2009 + + +5.5. Searching and View Filters + + Lemonade Message Stores MUST support the ESEARCH [IMAP-ESEARCH] + extension. The extension allows clients to efficiently find the + first or last messages, find a count of matching messages, and obtain + a list of matching messages in a considerably more compact + representation. + + Lemonade Message Stores also provide a mechanism for clients to avoid + handling an entire mailbox, instead accessing a view of the mailbox. + This technique, common in many desktop clients as a client-side + capability, is useful for constrained clients to minimize the + quantity of messages and notification data. + + Lemonade Message Stores therefore MUST implement the CONTEXT=SEARCH, + ESORT, and CONTEXT=SORT extensions defined in [IMAP-CONTEXT], as well + as the SORT extension defined in [IMAP-SORT]. + +5.6. Mailbox Handling + + Lemonade Message Stores MUST support the NAMESPACE [IMAP-NAMESPACE] + extension. The extension allows clients to discover shared mailboxes + and mailboxes belonging to other users, and provide a normalized + hierarchy view of the mailboxes available. + + Lemonade Message Stores MUST support the I18NLEVEL= [IMAP-I18N] + extension, with having the value 1 or 2. It adds support for + non-English (internationalized) search and sort functions. (Note + that I18NLEVEL=2 implies support for I18NLEVEL=1, so a Lemonade- + compliant client that makes use of this extension MUST recognize + either one.) + +5.7. Forward without Download + + In order to optimize network usage for the typical case where message + content is copied to, or sourced from, the IMAP store, Lemonade + provides support for a suite of extensions collectively known as + "forward without download", discussed in detail in Section 8. + + Lemonade Message Stores MUST support CATENATE [IMAP-CATENATE], + UIDPLUS [IMAP-UIDPLUS], and URLAUTH [IMAP-URLAUTH]. Lemonade Message + Stores MUST also support URL-PARTIAL as described in Section 5.7.1. + +5.7.1. Support for PARTIAL in CATENATE and URLAUTH + + [IMAP-URL] introduced a new syntactic element for referencing a byte + range of a message/body part. This is done using the ;PARTIAL= + field. If an IMAP server supports PARTIAL in IMAP URL used in + + + +Cridland, et al. Standards Track [Page 12] + +RFC 5550 Lemonade Profile August 2009 + + + CATENATE and URLAUTH extensions, then it MUST advertise the URL- + PARTIAL capability in both the CAPABILITY response and the equivalent + response-code. + +5.8. Additional IMAP Extensions + + Lemonade Message Stores MUST support the LITERAL+ [IMAP-LITERAL+] + extension. The extension allows clients to save a round trip each + time a non-synchronizing literal is sent. + + Lemonade Message Stores MUST also implement the SASL-IR + [IMAP-SASL-IR] extension, which allows clients to save a round trip + during authentication, potentially pipelining the entire + authentication sequence. + + Lemonade-compliant IMAP servers MUST support IMAP over TLS [IMAP] as + required by [IMAP]. As noted above in Section 5.3, servers SHOULD + support the deflate compression algorithm for TLS, as specified in + [TLS-COMP]. + +5.9. Registration of $Forwarded IMAP Keyword + + The $Forwarded IMAP keyword is used by several IMAP clients to + specify that the marked message was forwarded to another email + address, embedded within or attached to a new message. A mail client + sets this keyword when it successfully forwards the message to + another email address. Typical usage of this keyword is to show a + different (or additional) icon for a message that has been forwarded. + Once set, the flag SHOULD NOT be cleared. + + Lemonade Message Stores MUST be able to store the $Forwarded keyword. + They MUST preserve it on the COPY operation. The servers MUST + support the SEARCH KEYWORD $Forwarded. + +5.10. Registration of $SubmitPending and $Submitted IMAP Keywords + + The $SubmitPending IMAP keyword designates the message as awaiting to + be submitted. This keyword allows storing messages waiting to be + submitted in the same mailbox where messages that were already + submitted and/or are being edited are stored. A mail client sets + this keyword when it decides that the message needs to be sent out. + When a client (it might be a different client from the one that + decided that the message is pending submission) starts sending the + message, it atomically (using "STORE (UNCHANGEDSINCE)") adds the + $Submitted keyword. Once submission is successful, the + $SubmitPending keyword is atomically cleared. The two keywords allow + messages being actively submitted (messages that have both $Submitted + and $SubmitPending keywords set) to be distinguished from messages + + + +Cridland, et al. Standards Track [Page 13] + +RFC 5550 Lemonade Profile August 2009 + + + awaiting to be submitted, or from messages already submitted. They + also allow all messages that were supposed to be submitted to be + found, if the client submitting them crashes or quits before + submitting them. + + Lemonade Message Stores MUST be able to store the $SubmitPending and + the $Submitted keyword. Lemonade Message Stores MUST preserve them + on the COPY operation. The servers MUST support the SEARCH KEYWORD + $SubmitPending and SEARCH KEYWORD $Submitted. + +5.11. Related IMAP Extensions + + Section 5.11 is non-normative. + + Server implementations targeting to fulfill OMA MEM requirements + [OMA-MEM-REQ] should consider implementing the [IMAP-FILTERS], which + provides a way to persist definition of virtual mailboxes on the + server. They should also consider implementing the METADATA-SERVER + [METADATA] extension, which provides a way of storing user-defined + data associated with a user account. + +6. Lemonade Message Delivery Agents + + Lemonade Message Delivery Agents MUST support the [SIEVE] filtering + language at the point of delivery, allowing the user to control which + messages are accepted, and where they are filed. + + Lemonade Message Delivery Agents MUST support the Sieve Vacation + extension [SIEVE-VACATION], which allows the client to set up an + auto-responder, typically to report being on vacation (thus the name + of the Sieve extension). + + Lemonade Message Delivery Agents MUST support the Sieve Enotify + extension [SIEVE-NOTIFY], which allows a Sieve script to generate + notifications (such as XMPP, SIP, or email) about received messages. + + Lemonade Message Delivery Agents MUST support the Sieve Variables + extension [SIEVE-VARIABLES], which adds support for variables to the + Sieve scripting language. This extension is typically used with + Sieve Enotify or Vacation to customize responses/notifications. + + Lemonade Message Delivery Agents MUST support the Sieve Relational + extension [SIEVE-RELATIONAL], which adds support for relational + comparisons to the Sieve scripting language. This extension is + typically used together with Sieve Enotify. + + + + + + +Cridland, et al. Standards Track [Page 14] + +RFC 5550 Lemonade Profile August 2009 + + + Lemonade Message Delivery Agents MUST support the Sieve Imap4Flags + extension [SIEVE-IMAP4FLAGS], which allows a Sieve script to set IMAP + flags/keywords when delivering a message to a mailbox. For example, + this can be used to automatically mark certain messages as + interesting, urgent, etc. + + Lemonade Message Delivery Agents MUST support the i;unicode-casemap + comparator in Sieve [UNICODE-CASEMAP], which is declared as + "comparator-i;unicode-casemap" in the Sieve "require" statement. The + comparator allows for case-insensitive matching of Unicode + characters. + + Lemonade Message Delivery Agents should consider supporting Sieve + script management using the [MANAGESIEVE] protocol. If they do, they + MUST also advertise in [MANAGESIEVE] all Sieve extensions listed in + this section. + +7. Lemonade Message User Agents + + Although all existing IMAP MUAs are Lemonade compliant in as much as + all Lemonade services are based on the existing [IMAP] and [SUBMIT] + protocols, client implementors are encouraged to take full advantage + of the facilities provided by Lemonade Submission Servers and + Lemonade Message Stores, as described in 4 and 5, respectively. + + When opening a connection to the Submission Server, clients MUST do + so using port 587 unless explicitly configured to use an alternate + port [RFC5068]. (Note that this requirement is somewhat stronger + than the one specified in [SUBMIT], as [SUBMIT] didn't prescribe the + exact procedure to be used by submission clients.) If the TCP + connection to the submission server fails to open using port 587, the + client MAY then immediately retry using a different port, such as 25. + See [SUBMIT] for information on why using port 25 is likely to fail + depending on the current location of the client, and may result in a + failure code during the SMTP transaction. + + In addition, some specifications are useful to support interoperable + messaging with an enhanced user experience. + + Lemonade-capable clients SHOULD support the Format and DelSp + parameters to the text/plain media type described in [FLOWED], and + generate this format for messages. + + Lemonade-capable clients SHOULD support, and use, the $Forwarded + keyword described in Section 5.9. + + + + + + +Cridland, et al. Standards Track [Page 15] + +RFC 5550 Lemonade Profile August 2009 + + +8. Forward without Download + +8.1. Motivations + + The advent of client/server email using the [IMAP] and [SUBMIT] + protocols changed what formerly were local disk operations to become + repetitive network data transmissions. + + Lemonade "forward without download" makes use of the [SMTP-BURL] + extension to enable access to external sources during the submission + of a message. In combination with the [IMAP-URLAUTH] extension, + inclusion of message parts or even entire messages from the IMAP mail + store is possible with a minimal trust relationship between the IMAP + and SMTP SUBMIT servers. + + Lemonade "forward without download" has the advantage of maintaining + one submission protocol, and thus avoids the risk of having multiple + parallel and possibly divergent mechanisms for submission. The + client can use [SUBMIT] extensions without these being added to IMAP. + Furthermore, by keeping the details of message submission in the SMTP + SUBMIT server, Lemonade "forward without download" can work with + other message retrieval protocols such as POP, NNTP, or whatever else + may be designed in the future. + +8.2. Message Sending Overview + + The act of sending an email message can be thought of as involving + multiple steps: initiation of a new draft, draft editing, message + assembly, and message submission. + + Initiation of a new draft and draft editing takes place in the MUA. + Frequently, users choose to save more complex messages on an [IMAP] + server (via the APPEND command with the \Draft flag) for later recall + by the MUA and resumption of the editing process. + + Message assembly is the process of producing a complete message from + the final revision of the draft and external sources. At assembly + time, external data is retrieved and inserted in the message. + + Message submission is the process of inserting the assembled message + into the [ESMTP] infrastructure, typically using the [SUBMIT] + protocol. + + + + + + + + + +Cridland, et al. Standards Track [Page 16] + +RFC 5550 Lemonade Profile August 2009 + + +8.3. Traditional Strategy + + Traditionally, messages are initiated, edited, and assembled entirely + within an MUA, although drafts may be saved to an [IMAP] server and + later retrieved from the server. The completed text is then + transmitted to a Message Submission Agent (MSA) for delivery. + + There is often no clear boundary between the editing and assembly + processes. If a message is forwarded, its content is often retrieved + immediately and inserted into the message text. Similarly, when + external content is inserted or attached, the content is usually + retrieved immediately and made part of the draft. + + As a consequence, each save of a draft and subsequent retrieval of + the draft transmits that entire (possibly large) content, as does + message submission. + + In the past, this was not much of a problem, because drafts, external + data, and the message submission mechanism were typically located on + the same system as the MUA. The most common problem was running out + of disk quota. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cridland, et al. Standards Track [Page 17] + +RFC 5550 Lemonade Profile August 2009 + + +8.4. A New Strategy + + The model distinguishes between a Message User Agent (MUA), an + IMAPv4Rev1 Server ([IMAP]), and an SMTP submit server ([SUBMIT]), as + illustrated in Figure 1. + + +--------------------+ +--------------+ + | | <------------ | | + | MUA (M) | | IMAPv4Rev1 | + | | | Server | + | | ------------> | (Server I) | + +--------------------+ +--------------+ + ^ | ^ | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | v + | | +--------------+ + | |----------------------> | SMTP | + | | Submit | + |-----------------------------| Server | + | (Server S) | + +--------------+ + + Figure 1: Lemonade "forward without download" + + Lemonade "forward without download" allows a Message User Agent to + compose and forward an email combining fragments that are located in + an IMAP server, without having to download these fragments to the + client. + + This section informatively describes two ways to perform "forward + without download" based on where the message assembly takes place. + The first uses the extended APPEND command [IMAP-CATENATE] to edit a + draft message in the message store and cause the message assembly on + the IMAP server. This is most often used when a copy of the message + is to be retained on the IMAP server, as discussed in Section 8.6. + + The second uses a succession of BURL and BDAT commands to submit and + assemble through concatenation, message data from the client and + external data fetched from the provided URL. The two subsequent + sections provide step-by-step instructions on how "forward without + download" is achieved. + + + + + + +Cridland, et al. Standards Track [Page 18] + +RFC 5550 Lemonade Profile August 2009 + + +8.4.1. Message Assembly Using IMAP CATENATE Extension + + In the [SMTP-BURL]/[IMAP-CATENATE] variant of the Lemonade "forward + without download" strategy, messages are initially composed and + edited within an MUA. The [IMAP-CATENATE] extension to [IMAP] is + then used to create the messages on the IMAP server by transmitting + new text and assembling them. The UIDPLUS [IMAP-UIDPLUS] IMAP + extension is used by the client in order to learn the UID of the + created messages. Finally, an [IMAP-URLAUTH] format URL is given to + a [SUBMIT] server for submission using the BURL [SMTP-BURL] + extension. + + The flow involved to support such a use case consists of: + + M: {to I -- Optional} The client connects to the IMAP server, + optionally starts TLS (if data confidentiality is required), + authenticates, opens a mailbox ("INBOX" in the example below), and + fetches body structures (see [IMAP]). + + Example: + + M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) + I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" + ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( + "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" + "trip.txt") + "<960723163407.20117h@washington.example.com>" + "Your trip details" "BASE64" 4554 73) "MIXED")) + I: A0051 OK completed + + M: {to I} The client invokes CATENATE (see [IMAP-CATENATE] for + details of the semantics and steps) -- this allows the MUA to create + messages on the IMAP server using new data combined with one or more + message parts already present on the IMAP server. + + Note that the example for this step doesn't use the LITERAL+ + [IMAP-LITERAL+] extension. Without LITERAL+ the new message is + constructed using three round trips. If LITERAL+ is used, the new + message can be constructed using one round trip. + + + + + + + + + + + + +Cridland, et al. Standards Track [Page 19] + +RFC 5550 Lemonade Profile August 2009 + + + M: A0052 APPEND Sent FLAGS (\Draft \Seen $MDNSent) + CATENATE (TEXT {475} + I: + Ready for literal data + M: Message-ID: <419399E1.6000505@caernarfon.example.org> + M: Date: Thu, 12 Nov 2004 16:57:05 +0000 + M: From: Bob Ar + M: MIME-Version: 1.0 + M: To: foo@example.net + M: Subject: About our holiday trip + M: Content-Type: multipart/mixed; + M: boundary="------------030308070208000400050907" + M: + M: --------------030308070208000400050907 + M: Content-Type: text/plain; format=flowed + M: + M: Our travel agent has sent the updated schedule. + M: + M: Cheers, + M: Bob + M: --------------030308070208000400050907 + M: URL "/INBOX;UIDVALIDITY=385759045/; + UID=25627/;Section=2.MIME" URL "/INBOX; + UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44} + I: + Ready for literal data + M: + M: --------------030308070208000400050907-- + M: ) + I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed + + M: {to I} The client uses the GENURLAUTH command to request a URLAUTH + URL (see [IMAP-URLAUTH]). + I: {to M} The IMAP server returns a URLAUTH URL suitable for later + retrieval with URLFETCH (see [IMAP-URLAUTH] for details of the + semantics and steps). + + M: A0053 GENURLAUTH "imap://bob.ar@example.org/Sent; + UIDVALIDITY=387899045/;uid=45;expire=2005-10- + 28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL + I: * GENURLAUTH "imap://bob.ar@example.org/Sent; + UIDVALIDITY=387899045/;uid=45;expire= + 2005-10-28T23:59:59Z;urlauth=submit+bob.ar: + internal:91354a473744909de610943775f92038" + I: A0053 OK GENURLAUTH completed + + M: {to S} The client connects to the mail Submission Server and + starts a new mail transaction. It uses BURL to let the SMTP submit + server fetch the content of the message from the IMAP server (see + [IMAP-URLAUTH] for details of the semantics and steps -- this allows + + + +Cridland, et al. Standards Track [Page 20] + +RFC 5550 Lemonade Profile August 2009 + + + the MUA to authorize the SMTP submit server to access the message + composed as a result of the CATENATE step). Note that the second + EHLO command is required after a successful STARTTLS command. Also + note that there might be a third required EHLO command if the second + EHLO response doesn't list any BURL options. Section 8.4.2 + demonstrates this. + + S: 220 owlry.example.org ESMTP + M: EHLO potter.example.org + S: 250-owlry.example.com + S: 250-8BITMIME + S: 250-BINARYMIME + S: 250-PIPELINING + S: 250-BURL imap + S: 250-CHUNKING + S: 250-AUTH PLAIN + S: 250-DSN + S: 250-SIZE 10240000 + S: 250-STARTTLS + S: 250 ENHANCEDSTATUSCODES + M: STARTTLS + S: 220 Ready to start TLS + ...TLS negotiation, subsequent data is encrypted... + M: EHLO potter.example.org + S: 250-owlry.example.com + S: 250-8BITMIME + S: 250-BINARYMIME + S: 250-PIPELINING + S: 250-BURL imap + S: 250-CHUNKING + S: 250-AUTH PLAIN + S: 250-DSN + S: 250-SIZE 10240000 + S: 250 ENHANCEDSTATUSCODES + M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= + M: MAIL FROM: + M: RCPT TO: + S: 235 2.7.0 PLAIN authentication successful. + S: 250 2.5.0 Address Ok. + S: 250 2.1.5 foo@example.net OK. + M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/; + uid=45/;urlauth=submit+bar:internal: + 91354a473744909de610943775f92038 LAST + + S: {to I} The mail Submission Server uses URLFETCH to fetch the + message to be sent. (See [IMAP-URLAUTH] for details of the semantics + and steps. The so-called "pawn-ticket" authorization mechanism uses + a URI that contains its own authorization credentials.) + + + +Cridland, et al. Standards Track [Page 21] + +RFC 5550 Lemonade Profile August 2009 + + + I: {to S} Provides the message composed as a result of the CATENATE + step). + + The mail Submission Server opens an IMAP connection to the IMAP + server: + + I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ + CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com + IMAP server ready + S: a000 STARTTLS + I: a000 Start TLS negotiation now + ...TLS negotiation, if successful - subsequent data + is encrypted... + S: a001 LOGIN submitserver secret + I: a001 OK submitserver logged in + S: a002 URLFETCH "imap://bob.ar@example.org/Sent; + UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: + internal:91354a473744909de610943775f92038" + I: * URLFETCH "imap://bob.ar@example.org/Sent; + UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: + internal:91354a473744909de610943775f92038" {15065} + ...message body follows... + I: a002 OK URLFETCH completed + S: a003 LOGOUT + I: * BYE See you later + I: a003 OK Logout successful + + Note that if data confidentiality is not required, the mail + Submission Server may omit the STARTTLS command before issuing the + LOGIN command. + + S: {to M} Submission server assembles the complete message; if the + assembly succeeds, it returns OK to the MUA: + + S: 250 2.5.0 Ok. + + M: {to I} The client marks the message containing the forwarded + attachment on the IMAP server. + + M: A0054 UID STORE 25627 +FLAGS.SILENT ($Forwarded) + I: * 215 FETCH (UID 25627 MODSEQ (12121231000)) + I: A0054 OK STORE completed + + Note: the UID STORE command shown above will only work if the marked + message is in the currently selected mailbox; otherwise, it requires + a SELECT. This command can be omitted, as it simply changes non- + operational metadata not essential to client operations or + + + + +Cridland, et al. Standards Track [Page 22] + +RFC 5550 Lemonade Profile August 2009 + + + interoperability. The untagged FETCH response is due to + [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in + Section 5.9. + +8.4.2. Message Assembly Using SMTP CHUNKING and BURL Extensions + + In the [IMAP-URLAUTH]/[SMTP-BURL] variant of the Lemonade "forward + without download" strategy, messages are initially composed and + edited within an MUA. During submission [SUBMIT], BURL [SMTP-BURL] + and BDAT [SMTP-BINARYMIME] commands are used to create the messages + from multiple parts. New body parts are supplied using BDAT + commands, while existing body parts are referenced using + [IMAP-URLAUTH] format URLs in BURL commands. + + The flow involved to support such a use case consists of: + M: {to I -- Optional} The client connects to the IMAP server, + optionally starts TLS (if data confidentiality is required), + authenticates, opens a mailbox ("INBOX" in the example below), and + fetches body structures (see [IMAP]). + + Example: + + M: B0051 UID FETCH 25627 (UID BODYSTRUCTURE) + I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" + ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( + "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" + "trip.txt") + "<960723163407.20117h@washington.example.com>" + "Your trip details" "BASE64" 4554 73) "MIXED")) + I: B0051 OK completed + + M: {to I} The client uses the GENURLAUTH command to request URLAUTH + URLs (see [IMAP-URLAUTH]) referencing pieces of the message to be + assembled. + I: {to M} The IMAP server returns URLAUTH URLs suitable for later + retrieval with URLFETCH (see [IMAP-URLAUTH] for details of the + semantics and steps). + + + + + + + + + + + + + + +Cridland, et al. Standards Track [Page 23] + +RFC 5550 Lemonade Profile August 2009 + + + M: B0052 GENURLAUTH "imap://bob.ar@example.org/INBOX; + UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; + expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" + INTERNAL "imap://bob.ar@example.org/INBOX; + UIDVALIDITY=385759045/;UID=25627/;Section=2; + expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL + I: * GENURLAUTH "imap://bob.ar@example.org/INBOX; + UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; + expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: + internal:A0DEAD473744909de610943775f9BEEF" + "imap://bob.ar@example.org/INBOX; + UIDVALIDITY=385759045/;UID=25627/;Section=2; + expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: + internal:BEEFA0DEAD473744909de610943775f9" + I: B0052 OK GENURLAUTH completed + + M: {to S} The client connects to the mail Submission Server and + starts a new mail transaction. It uses BURL to instruct the SMTP + submit server to fetch from the IMAP server pieces of the message to + be sent (see [SMTP-BURL] for details of the semantics and steps). + + Note that the second EHLO command is required after a successful + STARTTLS command. The third EHLO command is required if and only if + the second EHLO response doesn't list any BURL options. See + Section 8.4.1 for an example of submission where the third EHLO + command/response is not present. + + S: 220 owlry.example.org ESMTP + M: EHLO potter.example.org + S: 250-owlry.example.com + S: 250-8BITMIME + S: 250-BINARYMIME + S: 250-PIPELINING + S: 250-BURL + S: 250-CHUNKING + S: 250-AUTH DIGEST-MD5 + S: 250-DSN + S: 250-SIZE 10240000 + S: 250-STARTTLS + S: 250 ENHANCEDSTATUSCODES + M: STARTTLS + S: 220 Ready to start TLS + ...TLS negotiation, subsequent data is encrypted... + M: EHLO potter.example.org + S: 250-owlry.example.com + S: 250-8BITMIME + S: 250-BINARYMIME + S: 250-PIPELINING + + + +Cridland, et al. Standards Track [Page 24] + +RFC 5550 Lemonade Profile August 2009 + + + S: 250-BURL + S: 250-CHUNKING + S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL + S: 250-DSN + S: 250-SIZE 10240000 + S: 250 ENHANCEDSTATUSCODES + M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= + S: 235 2.7.0 PLAIN authentication successful. + M: EHLO potter.example.org + S: 250-owlry.example.com + S: 250-8BITMIME + S: 250-BINARYMIME + S: 250-PIPELINING + S: 250-BURL imap imap://imap.example.org + S: 250-CHUNKING + S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL + S: 250-DSN + S: 250-SIZE 10240000 + S: 250 ENHANCEDSTATUSCODES + M: MAIL FROM: BODY=BINARY + S: 250 2.5.0 Address Ok. + M: RCPT TO: + S: 250 2.1.5 foo@example.net OK. + M: BDAT 475 + M: Message-ID: <419399E1.6000505@caernarfon.example.org> + M: Date: Thu, 12 Nov 2004 16:57:05 +0000 + M: From: Bob Ar + M: MIME-Version: 1.0 + M: To: foo@example.net + M: Subject: About our holiday trip + M: Content-Type: multipart/mixed; + M: boundary="------------030308070208000400050907" + M: + M: --------------030308070208000400050907 + M: Content-Type: text/plain; format=flowed + M: + M: Our travel agent has sent the updated schedule. + M: + M: Cheers, + M: Bob + M: --------------030308070208000400050907 + S: 250 2.5.0 OK + M: BURL imap://bob.ar@example.org/INBOX; + UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; + expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: + internal:A0DEAD473744909de610943775f9BEEF + S: 250 2.5.0 OK + M: BURL imap://bob.ar@example.org/INBOX; + + + +Cridland, et al. Standards Track [Page 25] + +RFC 5550 Lemonade Profile August 2009 + + + UIDVALIDITY=385759045/;UID=25627/;Section=2; + expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: + internal:BEEFA0DEAD473744909de610943775f9 + S: 250 2.5.0 OK + M: BDAT 44 LAST + M: + M: --------------030308070208000400050907-- + + S: {to I} The mail Submission Server uses URLFETCH to fetch the + pieces of the message to be sent. (See [SMTP-BURL] for details of + the semantics and steps. The so-called "pawn-ticket" authorization + mechanism uses a URI which contains its own authorization + credentials.). + I: {to S} Returns the requested body parts. + + The mail Submission Server opens an IMAP connection to the IMAP + server: + + I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ + CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com + IMAP server ready + S: b000 STARTTLS + I: b000 Start TLS negotiation now + ...TLS negotiation, if successful - subsequent data + is encrypted... + S: b001 LOGIN submitserver secret + I: b001 OK submitserver logged in + S: b002 URLFETCH "imap://bob.ar@example.org/INBOX; + UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; + expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: + internal:A0DEAD473744909de610943775f9BEEF" "imap:// + bob.ar@example.org/INBOX; + UIDVALIDITY=385759045/;UID=25627/;Section=2; + expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: + internal:BEEFA0DEAD473744909de610943775f9" + I: * URLFETCH "imap://bob.ar@example.org/INBOX; + UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; + expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: + internal:A0DEAD473744909de610943775f9BEEF" {84} + ...message section follows... + "imap://bob.ar@example.org/INBOX; + UIDVALIDITY=385759045/;UID=25627/;Section=2; + expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: + internal:BEEFA0DEAD473744909de610943775f9" {15065} + ...message section follows... + I: b002 OK URLFETCH completed + S: b003 LOGOUT + I: * BYE See you later + + + +Cridland, et al. Standards Track [Page 26] + +RFC 5550 Lemonade Profile August 2009 + + + I: b003 OK Logout successful + + Note that if data confidentiality is not required, the mail + Submission Server may omit the STARTTLS command before issuing the + LOGIN command. + + S: {to M} Submission Server assembles the complete message; if the + assembly succeeds, it acknowledges acceptance of the message by + sending 250 response to the last BDAT command: + + S: 250 2.5.0 Ok, message accepted. + + M: {to I} The client marks the message containing the forwarded + attachment on the IMAP server. + + M: B0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) + I: * 215 FETCH (UID 25627 MODSEQ (12121231000)) + I: B0053 OK STORE completed + + Note: the UID STORE command shown above will only work if the marked + message is in the currently selected mailbox; otherwise, it requires + a SELECT. As in the previous example, this command is not critical, + and can be omitted. The untagged FETCH response is due to + [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in + Section 5.9. + +8.5. Security Considerations for Pawn-Tickets + + The so-called "pawn-ticket" authorization mechanism uses a URI, which + contains its own authorization credentials using [IMAP-URLAUTH]. The + advantage of this mechanism is that the SMTP submit [SUBMIT] server + cannot access any data on the [IMAP-URLAUTH] server without a "pawn- + ticket" created by the client. + + The "pawn-ticket" grants access only to the specific data that the + SMTP submit [SUBMIT] server is authorized to access, can be revoked + by the client, and can have a time-limited validity. + +8.6. Copies of Sent Messages: The fcc Problem + + The "fcc problem" refers to delivering a copy of a message to a + mailbox, or "file carbon copy". By far, the most common case of fcc + is a client leaving a copy of outgoing mail in a "Sent Mail" or + "Outbox" mailbox. + + In the traditional strategy, the MUA duplicates the effort spent in + transmitting to the MSA by writing the message to the fcc destination + in a separate step. This may be a write to a local disk file or an + + + +Cridland, et al. Standards Track [Page 27] + +RFC 5550 Lemonade Profile August 2009 + + + APPEND to a mailbox on an IMAP server. The latter is one of the + "repetitive network data transmissions" that represents the "problem" + aspect of the "fcc problem". + + The BURL [SMTP-BURL] extension can be used to eliminate the + additional transmission. The final message is uploaded to the + mailbox designed for outgoing mail by the APPEND command of [IMAP]. + Note that when doing so, the client ought to use the $SubmitPending + and $Submitted IMAP keywords described in Section 5.10. Also note + that APPEND, including when enhanced by [IMAP-CATENATE], can only + create a single copy of the message and this is only of use on the + server that stages the outgoing message for submission. Additional + copies of the message on the same server can be created by using one + or more COPY commands. + +9. Deployment Considerations + + Deployment considerations are discussed extensively in + [LEMONADE-DEPLOYMENTS]. + +10. Security Considerations + + Implementors are advised to examine the security considerations of + all the referenced documents. This section merely highlights these, + and advises implementors on specific issues relating to the + combination of extensions. + + Security considerations on Lemonade "forward without download" are + discussed throughout Section 8. Additional security considerations + can be found in [IMAP], [SUBMIT], [SIEVE], and other documents + describing other SMTP, IMAP, and Sieve extension comprising the + Lemonade Profile. + + Note that the mandatory-to-implement authentication mechanism for + SMTP submission is described in [SMTP-AUTH]. The mandatory-to- + implement authentication mechanism for IMAP is described in [IMAP]. + +10.1. Confidentiality Protection of Submitted Messages + + When clients submit new messages, link protection such as [TLS] + guards against an eavesdropper seeing the contents of the submitted + message. It is worth noting, however, that even if TLS is not used, + the security risks are no worse if BURL is used to reference the text + than if the text is submitted directly. If BURL is not used, an + eavesdropper gains access to the full text of the message. If BURL + is used, the eavesdropper may or may not be able to gain such access, + + + + + +Cridland, et al. Standards Track [Page 28] + +RFC 5550 Lemonade Profile August 2009 + + + depending on the form of BURL used. For example, some forms restrict + use of the URL to an entity authorized as a Submission Server or a + specific user. + +10.2. TLS + + When Lemonade clients use the BURL extension for mail submission, an + extension that requires sending a URLAUTH token to the mail + Submission Server, such a token should be protected from interception + to avoid a replay attack that may disclose the contents of the + message to an attacker. [TLS]-based encryption of both the IMAP + session that issues GENURLAUTH and the mail submission path will + provide protection against this attack. + + Lemonade-compliant mail Submission Servers SHOULD use TLS-protected + IMAP connections when fetching message content using the URLAUTH + token provided by the Lemonade client. + + When a client uses SMTP STARTTLS to send a BURL command that + references non-public information, there is a user expectation that + the entire message content will be treated confidentially. To meet + this expectation, the message Submission Server SHOULD use STARTTLS + or a mechanism providing equivalent data confidentiality when + fetching the content referenced by that URL. + +10.3. Additional Extensions and Deployment Models + + This specification provides no additional security measures beyond + those in the referenced Internet Mail and Lemonade documents. + + We note, however, the security risks associated with: + + o Outband notifications + + o Server configuration by client + + o Client configuration by server + + o Presence of proxy servers + + o Presence of servers as intermediaries + + o In general, the deployment models considered by OMA MEM that are + not conventional IETF deployment models + + o Measures to address a perceived need to traverse firewalls and + mobile network intermediaries + + + + +Cridland, et al. Standards Track [Page 29] + +RFC 5550 Lemonade Profile August 2009 + + + Deployments that provide these additional services or operate in + these environments need to consult the security considerations for + the relevant standards and organizational security practices. + +11. IANA Considerations + + IMAP4 capabilities are registered by IETF Review, as defined in + [RFC5226]. This document defines the URL-PARTIAL IMAP capability + (Section 5.7.1). IANA added this extension to the IANA IMAP + Capability registry. + +12. Changes since RFC 4550 + + When compared to RFC 4550, this document adds the following + additional requirements on a Lemonade compliant IMAP server: + + IMAP extensions: BINARY, COMPRESS=DEFLATE, CONTEXT=SEARCH, + CONTEXT=SORT, CONVERT, ENABLE, ESEARCH, ESORT, I18NLEVEL=1, + NOTIFY, QRESYNC, SASL-IR, SORT, URL-PARTIAL; + + IMAP keywords: $SubmitPending, $Submitted. + + Other requirements: Require any Lemonade compliant IMAP server to + support the CAPABILITY response code. + + When compared to RFC 4550, this document adds the following new + requirements on a Lemonade compliant Message Delivery Agents: + + Support for the Sieve filtering language, together with the following + Sieve extensions: + + ENOTIFY, IMAP4FLAGS, RELATIONAL, VACATION, VARIABLES, comparator- + i;unicode-casemap. + + When compared to RFC 4550, this document recommends use of the + DEFLATE compression method for TLS. All other requirements remain + the same. + + Additionally, the following changes/improvments were done to RFC 4550 + (the list might be incomplete): + + A new section with some additional requirements on Lemonade Mail + User Agents was added, in particular they are required to support + Format=flowed parameter to the text/plain media type. + + Usage of the $Forwarded IMAP keyword was clarified. + + Forward-without-download examples were corrected and extended. + + + +Cridland, et al. Standards Track [Page 30] + +RFC 5550 Lemonade Profile August 2009 + + + Added a new section describing in-band and out-of-band + notifications from a Lemonade compliant mailstore. + +13. Acknowledgements + + The editors acknowledge and appreciate the work and comments of the + IETF Lemonade working group and the OMA MEM working group. + + In particular, the editors would like to thank Eric Burger, Glenn + Parsons, Randall Gellens, Filip Navara, Zoltan Ordogh, Greg + Vaudreuil, and Fan Xiaohui for their comments and reviews. + +14. References + +14.1. Normative References + + [FLOWED] Gellens, R., "The Text/Plain Format and DelSp Parameters", + RFC 3676, February 2004. + + [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, March 2003. + + [IMAP-BINARY] + Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, + April 2003. + + [IMAP-CATENATE] + Resnick, P., "Internet Message Access Protocol (IMAP) + CATENATE Extension", RFC 4469, April 2006. + + [IMAP-COMPRESS] + Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, + August 2007. + + [IMAP-CONDSTORE] + Melnikov, A. and S. Hole, "IMAP Extension for Conditional + STORE Operation or Quick Flag Changes Resynchronization", + RFC 4551, June 2006. + + [IMAP-CONTEXT] + Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, + July 2008. + + [IMAP-CONVERT] + Melnikov, A. and P. Coates, "Internet Message Access + Protocol - CONVERT Extension", RFC 5259, July 2008. + + + + + +Cridland, et al. Standards Track [Page 31] + +RFC 5550 Lemonade Profile August 2009 + + + [IMAP-ENABLE] + Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE + Extension", RFC 5161, March 2008. + + [IMAP-ESEARCH] + Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH + Command for Controlling What Kind of Information Is + Returned", RFC 4731, November 2006. + + [IMAP-I18N] + Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet + Message Access Protocol Internationalization", RFC 5255, + June 2008. + + [IMAP-IDLE] + Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. + + [IMAP-LITERAL+] + Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, + January 1997. + + [IMAP-NAMESPACE] + Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, + May 1998. + + [IMAP-NOTIFY] + Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP + NOTIFY Extension", RFC 5465, February 2009. + + [IMAP-QRESYNC] + Melnikov, A., Cridland, D., and C. Wilson, "IMAP4 + Extensions for Quick Mailbox Resynchronization", RFC 5162, + March 2008. + + [IMAP-SASL-IR] + Siemborski, R. and A. Gulbrandsen, "IMAP Extension for + Simple Authentication and Security Layer (SASL) Initial + Client Response", RFC 4959, September 2007. + + [IMAP-SORT] + Crispin, M. and K. Murchison, "Internet Message Access + Protocol - SORT and THREAD Extensions", RFC 5256, + June 2008. + + [IMAP-UIDPLUS] + Crispin, M., "Internet Message Access Protocol (IMAP) - + UIDPLUS extension", RFC 4315, December 2005. + + + + +Cridland, et al. Standards Track [Page 32] + +RFC 5550 Lemonade Profile August 2009 + + + [IMAP-URL] + Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, + November 2007. + + [IMAP-URLAUTH] + Crispin, M., "Internet Message Access Protocol (IMAP) - + URLAUTH Extension", RFC 4467, May 2006. + + [KEYWORDS] + Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering + Language", RFC 5228, January 2008. + + [SIEVE-IMAP4FLAGS] + Melnikov, A., "Sieve Email Filtering: Imap4flags + Extension", RFC 5232, January 2008. + + [SIEVE-NOTIFY] + Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, + "Sieve Email Filtering: Extension for Notifications", + RFC 5435, January 2009. + + [SIEVE-RELATIONAL] + Segmuller, W. and B. Leiba, "Sieve Email Filtering: + Relational Extension", RFC 5231, January 2008. + + [SIEVE-VACATION] + Showalter, T. and N. Freed, "Sieve Email Filtering: + Vacation Extension", RFC 5230, January 2008. + + [SIEVE-VARIABLES] + Homme, K., "Sieve Email Filtering: Variables Extension", + RFC 5229, January 2008. + + [SMTP-8BITMIME] + Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. + Crocker, "SMTP Service Extension for 8bit-MIMEtransport", + RFC 1652, July 1994. + + [SMTP-AUTH] + Siemborski, R. and A. Melnikov, "SMTP Service Extension + for Authentication", RFC 4954, July 2007. + + + + + + + +Cridland, et al. Standards Track [Page 33] + +RFC 5550 Lemonade Profile August 2009 + + + [SMTP-BINARYMIME] + Vaudreuil, G., "SMTP Service Extensions for Transmission + of Large and Binary MIME Messages", RFC 3030, + December 2000. + + [SMTP-BURL] + Newman, C., "Message Submission BURL Extension", RFC 4468, + May 2006. + + [SMTP-DSN] + Moore, K., "Simple Mail Transfer Protocol (SMTP) Service + Extension for Delivery Status Notifications (DSNs)", + RFC 3461, January 2003. + + [SMTP-PIPELINING] + Freed, N., "SMTP Service Extension for Command + Pipelining", STD 60, RFC 2920, September 2000. + + [SMTP-SIZE] + Klensin, J., Freed, N., and K. Moore, "SMTP Service + Extension for Message Size Declaration", STD 10, RFC 1870, + November 1995. + + [SMTP-STATUSCODES] + Freed, N., "SMTP Service Extension for Returning Enhanced + Error Codes", RFC 2034, October 1996. + + [SMTP-TLS] + Hoffman, P., "SMTP Service Extension for Secure SMTP over + the Transport Layer Security", RFC 3207, February 2002. + + [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", + RFC 4409, April 2006. + + [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [TLS-COMP] + Hollenbeck, S., "Transport Layer Security Protocol + Compression Methods", RFC 3749, May 2004. + + [UNICODE-CASEMAP] + Crispin, M., "i;unicode-casemap - Simple Unicode Collation + Algorithm", RFC 5051, October 2007. + + + + + + + +Cridland, et al. Standards Track [Page 34] + +RFC 5550 Lemonade Profile August 2009 + + +14.2. Informative References + + [ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + + [Err1807] RFC Errata, Errata ID 1807, RFC 5162, + . + + [Err1808] RFC Errata, Errata ID 1808, RFC 5162, + . + + [Err1809] RFC Errata, Errata ID 1809, RFC 5162, + . + + [Err1810] RFC Errata, Errata ID 1810, RFC 5162, + . + + [FINGER-HACK] + Gellens, R., "Simple New Mail Notification", RFC 4146, + August 2005. + + [IMAP-FILTERS] + Melnikov, A. and C. King, "IMAP4 Extension for Named + Searches (Filters)", RFC 5466, February 2009. + + [IMAP-SYNC-HOWTO] + Melnikov, A., "Synchronization Operations for Disconnected + IMAP4 Clients", RFC 4549, June 2006. + + [LEMONADE-ARCH] + Burger, E. and G. Parsons, "LEMONADE Architecture - + Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) + Using Internet Mail", RFC 5442, March 2009. + + [LEMONADE-DEPLOYMENTS] + Gellens, R., "Deployment Considerations for Lemonade- + Compliant Mobile Email", BCP 143, RFC 5383, October 2008. + + [LEMONADE-NOTIFICATIONS] + Gellens, R., Ed., "Lemonade Notifications Architecture", + RFC 5551, August 2009. + + [MANAGESIEVE] + Melnikov, A. and T. Martin, "A Protocol for Remotely + Managing Sieve Scripts", Work in Progress, September 2008. + + + + + + +Cridland, et al. Standards Track [Page 35] + +RFC 5550 Lemonade Profile August 2009 + + + [METADATA] + Daboo, C., "The IMAP METADATA Extension", RFC 5464, + February 2009. + + [OMA-EMN] Open Mobile Alliance, "Open Mobile Alliance Email + Notification Version 1.0", OMA http:// + www.openmobilealliance.org/Technical/release_program/ + emn_v10.aspx, October 2007. + + [OMA-MEM-ARCH] + Open Mobile Alliance, "Mobile Email Architecture + Document", OMA (Work in Progress), + http://www.openmobilealliance.org/, October 2005. + + [OMA-MEM-REQ] + Open Mobile Alliance, "Mobile Email Requirements + Document", OMA http://www.openmobilealliance.org/ + release_program/docs/RD/ + OMA-RD-MobileEmail-V1_0_20051018-C.pdf, Oct 2005. + + [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. + Finch, "Email Submission Operations: Access and + Accountability Requirements", BCP 134, RFC 5068, + November 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, + July 2009. + + + + + + + + + + + + + + + + + + + + +Cridland, et al. Standards Track [Page 36] + +RFC 5550 Lemonade Profile August 2009 + + +Appendix A. Errata + + Errata ID: 1807 [Err1807] + + Status: Verified + Type: Technical + + Reported By: Timo Sirainen + Date Reported: 2009-07-14 + Verifier Name: Alexey Melnikov + Date Verified: 2009-07-18 + + Section 1 says: + + It should say: + + Once a "CONDSTORE enabling command" is issued by the client, the + server MUST automatically include both UID and mod-sequence data in + all subsequent untagged FETCH responses (until the connection is + closed), whether they were caused by a regular STORE/UID STORE, a + STORE/UID STORE with UNCHANGEDSINCE modifier, or an external agent. + Note that this rule doesn't affect untagged FETCH responses caused by + a FETCH command that doesn't include UID and/or MODSEQ FETCH data + item, or UID FETCH without the MODSEQ FETCH data item. + + Notes: + + Rationale: + + It's very difficult for clients to make use of unsolicited FETCH + responses without the UID field. This is made even worse by the text + that says "servers SHOULD NOT send UIDs for previously expunged + messages [in VANISHED replies]". Since it's not a MUST NOT, a + conversation with an RFC compliant server could be for example: + + A1 NOOP + * 0 EXISTS + A1 OK + A2 NOOP + * 10 EXISTS + * VANISHED 1000:2000 + * 3 FETCH (FLAGS (\Seen) MODSEQ (14749)) + * 5 FETCH (FLAGS (\Seen) MODSEQ (14749)) + * VANISHED 2000:3000 + A2 OK NOOP Completed + + The client couldn't do anything with the information from FETCH + replies, because it can't know what messages they refer to. + + + +Cridland, et al. Standards Track [Page 37] + +RFC 5550 Lemonade Profile August 2009 + + + Errata ID: 1808 [Err1808] + + Status: Verified + Type: Technical + + Reported By: Timo Sirainen + Date Reported: 2009-07-14 + Verifier Name: Alexey Melnikov + Date Verified: 2009-07-18 + + Section 3.4 says: + + If at least one message got expunged, the server MUST send + the updated per-mailbox modification + sequence using the HIGHESTMODSEQ response code (defined in + [CONDSTORE]) in the tagged OK response. + + Example: C: A202 CLOSE + S: A202 OK [HIGHESTMODSEQ 20010715194045319] done + + It should say: + + The server MUST NOT send the updated per-mailbox modification + sequence using the HIGHESTMODSEQ response code (defined in + [CONDSTORE]) in the tagged OK response, as this might cause loss of + synchronization on the client. + + Example: C: A202 CLOSE + S: A202 OK done + + Notes: + + Rationale: + + The HIGHESTMODSEQ can't be used reliably unless server sends to client + all changes done by other clients. Even then it's difficult for both + clients and servers to implement this. For example: + + C1: 2 STORE 1 +FLAGS.SILENT \Deleted + S1: * 1 FETCH (MODSEQ 1) + S1: 2 OK + + C2: 1 STORE 2 +FLAGS.SILENT \Deleted + S1: * 2 FETCH (MODSEQ 2) + S2: 1 OK + + C1: 3 CLOSE + S1: 3 [HIGHESTMODSEQ 3] + + + +Cridland, et al. Standards Track [Page 38] + +RFC 5550 Lemonade Profile August 2009 + + + The client probably thought that only message 1 was expunged, so it + doesn't register the second expunge. And it probably never will if it + uses QRESYNC to find out only about new expunges. + + And even worse example would be if the second client had also removed + the \Deleted flag from message 1. Then the first client would have + registered wrong message to be expunged. + + + Errata ID: 1809 [Err1809] + + Status: Verified + Type: Technical + + Reported By: Timo Sirainen + Date Reported: 2009-07-14 + Verifier Name: Alexey Melnikov + Date Verified: 2009-07-18 + + Section 5 says: + + After completing a full synchronization, the client MUST also take + note of any unsolicited MODSEQ FETCH data items received from the + server. Whenever the client receives a tagged response to a command, + it calculates the highest value among all MODSEQ FETCH data items + received since the last tagged response. If this value is bigger + than the client's copy of the HIGHESTMODSEQ value, then the client + MUST use this value as its new HIGHESTMODSEQ value. + + Note: It is not safe to update the client's copy of the HIGHESTMODSEQ + value with a MODSEQ FETCH data item value as soon as it is received + because servers are not required to send MODSEQ FETCH data items in + increasing modseqence order. This can lead to the client missing + some changes in case of connectivity loss. + + It should say: + + After completing a full synchronization, the client MUST also take + note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ + response codes received from the server. Whenever the client receives + a tagged response to a command, it checks the received unsolicited + responses to calculate the new HIGHESTMODSEQ value. If the + HIGHESTMODSEQ response code is received, the client MUST use it even + if it has seen higher mod-sequences. Otherwise, the client calculates + the highest value among all MODSEQ FETCH data items received since the + last tagged response. If this value is bigger than the client's copy + of the HIGHESTMODSEQ value, then the client MUST use this value as its + new HIGHESTMODSEQ value. + + + +Cridland, et al. Standards Track [Page 39] + +RFC 5550 Lemonade Profile August 2009 + + + Example: C: A1 STORE 1:2 (UNCHANGEDSINCE 96) +FLAGS.SILENT \Seen + S: * 1 FETCH (UID 6 MODSEQ (103)) + S: * 2 FETCH (UID 7 MODSEQ (101)) + S: * OK [HIGHESTMODSEQ 99] VANISHED reply with + MODSEQ 100 is delayed + S: A1 OK [MODIFIED 3] done + + C: A2 STORE 3 +FLAGS.SILENT \Seen + S: * 3 FETCH (UID 8 MODSEQ (104)) + S: A2 OK [HIGHESTMODSEQ 99] Still delaying VANISHED + + C: A3 NOOP + S: * VANISHED 8 + S: A3 OK [HIGHESTMODSEQ 104] done + + Note: It is not safe to update the client's copy of the HIGHESTMODSEQ + value with a MODSEQ FETCH data item value as soon as it is received + because servers are not required to send MODSEQ FETCH data items in + increasing modseqence order. Some commands may also delay EXPUNGE + (or VANISHED) replies with smaller mod-sequences. These can lead to + the client missing some changes in case of connectivity loss. + + Notes: + + Rationale: + + Otherwise clients could lose changes in case of connectivity loss. + + Errata ID: 1810 [Err1810] + + Status: Verified + Type: Technical + + Reported By: Timo Sirainen + Date Reported: 2009-07-14 + Verifier Name: Alexey Melnikov + Date Verified: 2009-07-18 + + Section 1 says: + + It should say: + + Server implementing QRESYNC MUST send untagged events to client in a + way that client doesn't lose any changes in case of connectivity loss. + In particular this means that if server sends MODSEQ FETCH data items + while EXPUNGE (or VANISHED) replies with lower mod-sequences are being + delayed, the server MUST send HIGHESTMODSEQ response code with a lower + value than the EXPUNGE's mod-sequence. See example in section 5. + + + +Cridland, et al. Standards Track [Page 40] + +RFC 5550 Lemonade Profile August 2009 + + + Notes: + + This is related to the other errata in section 5, which describes what + the client's behavior should be. This describes what the server's + behavior should be. Would have been nice to put them into the same + section, but that probably would require larger changes. + +Authors' Addresses + + Dave Cridland (editor) + Isode Limited + 5 Castle Business Village + 36 Station Road + Hampton, Middlesex TW12 2BX + UK + + EMail: dave.cridland@isode.com + + + Alexey Melnikov (editor) + Isode Limited + 5 Castle Business Village + 36 Station Road + Hampton, Middlesex TW12 2BX + UK + + EMail: Alexey.Melnikov@isode.com + + + Stephane H. Maes (editor) + Oracle + MS 4op634, 500 Oracle Parkway + Redwood Shores, CA 94539 + USA + + Phone: +1-203-300-7786 + EMail: stephane.maes@oracle.com + + + + + + + + + + + + + + +Cridland, et al. Standards Track [Page 41] + -- cgit v1.2.3