RFC 5550

The Internet Email to Support Diverse Service Environments (Lemonade) Profile

📅 published August 2009, from ietf

RFC 5550: The Internet Email to Support Diverse Service Environments (Lemonade) Profile 🍋💖

okay bestie, this one is the Lemonade Profile, and it is giving main character energy 💅✨ It's an IETF Standards Track doc from August 2009, written by D. Cridland, A. Melnikov, and S. Maes (all three as editors 🎀). Cridland and Melnikov are from Isode Limited, and Maes is from Oracle. It obsoletes RFC 4550 (so this is the new and improved version 👑) and it updates RFC 4469 and RFC 4467 🌸

Abstract ✨

okay so the Abstract is the "here's what this is about" part 🫶 This doc describes a profile, which is a set of required extensions, restrictions, and usage modes, called Lemonade. It covers IMAP, mail submission, and Sieve. The whole point is letting clients that are low on memory, bandwidth, processing power, or other resources still use IMAP and Submission to access and send mail efficiently 🦋 That includes forwarding received mail without downloading and re-uploading it, optimizing submission, and quickly resyncing after the connection to the server drops 😭

Lemonade relies on several extensions to IMAP, Sieve, and Mail Submission. The doc also defines a new IMAP extension and registers a few new IMAP keywords 🧚

Status of This Memo 📜

This doc specifies an Internet standards track protocol for the Internet community, and it wants your discussion and suggestions for improvements 💜 For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 🌈 Distribution of this memo is unlimited, so share away 🍓

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💅

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as in effect on the publication date. The license info lives at http://trustee.ietf.org/license-info. Read these carefully, because they spell out your rights and restrictions 🙈

This doc may contain material from IETF Documents or IETF Contributions that were published or publicly available before November 10, 2008. Some of that material's copyright holders may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exception is formatting it for publication as an RFC or translating 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
      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 ✨

okay so the Lemonade Profile (or just "Lemonade") gives Internet email some upgrades so it works across all kinds of service environments 🍋 Lemonade mail servers come with a Lemonade Submission Server and a Lemonade Message Store. These are based on the existing [SUBMIT] and [IMAP] protocols, respectively. They MAY also include a Lemonade Message Delivery Agent, which does delivery-time filtering based on [SIEVE] 🧚

This doc describes the Lemonade Profile, which includes:

  • General common enhancements to Internet Mail, described in 5 and 4.
  • "Forward without download," which covers exchanges between Lemonade clients and servers so you can submit new email messages that include content living somewhere outside the client, described in Section 8 📨
  • Quick mailbox resynchronization, described in Section 5.1 ⚡
  • Extensions that support more precise, and broader, notifications from the store, for notifications and view filters, described in 5.4.1 and 5.5 🔔
  • Delivery-time filtering for 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 🏗️

It's intended that the Lemonade Profile supports 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:" show lines sent by the client Message User Agent, the IMAP email server, and the 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]. These are the official requirement words, so read them carefully 🫶

Other capitalized words are usually names of extensions or commands. They're uppercased just for clarity, and they're case-insensitive 🌸

This doc uses terminology defined in [RFC5598]. Check [RFC5598] for further details on Email Architecture 🦋

All examples in this doc are optimized for Lemonade use, and they might not be examples of proper protocol usage for a general use Submit/IMAP client 🙈 In particular, the examples assume that the Submit and IMAP servers support all the Lemonade extensions described here, so they don't show fallbacks for when an extension is missing 💀

3. Summary of the Required Support 🎯

3.1. Lemonade Submission Servers 💌

Lemonade Submission Servers MUST provide a service as described in [SUBMIT], and they MUST support the following. Note that the Lemonade Profile adds further requirements for some cases, which are detailed in the sections cited 🎀

     +---------------------+--------------------+--------------+
     |    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 |
     +---------------------+--------------------+--------------+

Section 3.2 is up next, and it's where the Lemonade Message Stores get their turn 🧚✨

3.2. Lemonade Message Stores 💌

Lemonade Message Stores MUST provide a service as described in [IMAP], and MUST support the following. Quick heads-up: the Lemonade Profile adds extra requirements in some cases, which are detailed in the sections cited 👀

+------------------------+------------------+---------------+
|     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 |
+------------------------+------------------+---------------+

On top of that 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. Don't skip it, bestie 💅

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. Same deal as before: the Lemonade Profile piles on more requirements in some cases, so check 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]. It's a "should consider," so it's giving suggestion energy, not a rule 🌸

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]. So any MUA designed to submit email via [SUBMIT] or [ESMTP] will interoperate with Lemonade Submission Servers. Iconic compatibility 🫶

In addition, Lemonade Submission Servers implement the following set of SMTP and Submission extensions to increase message submission efficiency. Speed, but make it cute 🚀

4.1. Forward without Download 🦋

To optimize network usage in 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." We go deeper on this in Section 8, so stay tuned 👀

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). Lowkey a whole chain of MUSTs, periodt 💅

4.2. Pipelining 🧃

Some clients regularly use networks with a relatively high latency, such as mobile or satellite-based networks. Avoiding round trips within a transaction is a huge win for both bandwidth and total transaction time. That's why Lemonade-compliant mail Submission Servers MUST support the SMTP service extensions for command pipelining [SMTP-PIPELINING]. No cap, this one matters 💖

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 📏

Detecting failures as early as possible is a big deal in lots of cases, like when the user is charged per octet or when bandwidth is low. It's especially true for 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. Order matters, bestie 🍓

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. Don't be the client that sends a too-big email and then acts shocked 💀

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 let a client figure out the precise cause of a failure, which is so helpful when things go sideways 💜

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].

Support for the DEFLATE compression method, as described in [TLS-COMP], is RECOMMENDED. Very recommended, honestly 🌈

5. Lemonade Message Stores 🌟

All Lemonade Message Stores implement the Internet Message Access Protocol, as defined in [IMAP]. So any MUA written to access messages using the facilities described in [IMAP] will interoperate with a Lemonade Message Store. Same energy as the submission side 🫶

In addition, Lemonade Message Stores provide a set of extensions to address the limitations of some clients and networks. Helping the less-resourced clients get their glow-up 🦋

5.1. Quick Resynchronization ⚡

Resynchronization is a costly part of an IMAP session, and mobile networks are more prone to unintended disconnection, which makes this problem even more acute. So 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 let a client quickly resynchronize any mailbox by asking the server to return all flag changes and expunges that have happened since a previously recorded state. This can also speed up client reconnect if the transport layer gets cut, whether by accident or because the network changed 🧚

When implementing QRESYNC [IMAP-QRESYNC], client and servers need to also comply with errata submitted for this document (see Appendix A). Read the errata, bestie, it's not optional vibes 📝

[IMAP-SYNC-HOWTO] details how clients perform efficient mailbox resynchronization. The how-to is the main character here 🎀

5.2. Message Part Handling 🧩

Message parts, especially attachments, are a real challenge for limited devices, both in terms of the bandwidth used and the device's capability.

Lemonade-compliant IMAP servers MUST support the BINARY [IMAP-BINARY] extension. This moves MIME body part decoding from the client to the server. The decoded data is equal to or smaller than the encoded representation, so this cuts bandwidth effectively 🍓

[IMAP-BINARY] allows servers to refuse 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. So no refusing the binary vibes, the Lemonade servers always take them 💖

[IMAP-CONVERT] MUST also be supported by servers. It lets clients request conversions between media types and allows for scaling images, etc. That gives clients the ability to view attachments (and sometimes body parts) even without the facility to handle a wide range of media types, or to view attachments efficiently 🌸

5.3. Compression 🗜️

Lemonade Message Stores SHOULD support the Deflate compression algorithm for TLS, as defined in [TLS-COMP], so that compression happens at as low a level as possible.

The working group acknowledges that for many endpoints this is a rarely deployed technology. So Lemonade Message Stores MUST provide [IMAP-COMPRESS] support for fallback application-level stream compression, where TLS is not actively providing compression. Backup plan era 🫶

5.4. Notifications 🔔

Adding server-to-client notifications turns the Lemonade Profile into an event-based synchronization protocol. Whenever an event happens 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. Push it, push it real good 📲

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. Quick-sync on reconnect, no skipping 🌈

5.4.1. IMAP Notifications 💫

Lemonade Message Stores MUST support the IDLE [IMAP-IDLE] extension. It lets clients receive unsolicited notifications about changes in the selected mailbox without having to poll for changes. The responses forming these notifications MUST be sent in a timely manner when such changes happen. Timing is everything, bestie ⭐

Lemonade Message Stores also provide the NOTIFY extension described in [IMAP-NOTIFY]. It lets clients ask for specific event types to be sent immediately to the client, both for the currently selected folder and for others. Those event types include message delivery and mailbox renames. The notifications are giving real-time 🔥

5.4.2. External Notifications 📬✨

okay so Lemonade and TCP give you long-lived idle connections between the client and the mail store 💖, which means the server can push notifications over IMAP. some mobile networks even do dormancy 🌙, where the radio traffic channel shuts down during idle periods to save handset and network resources, while the IP and TCP state stays alive. (check out [LEMONADE-DEPLOYMENTS] for more deets 🎀)

BUT 😭 there are environments where the email client can't stay active forever, or where it's not advisable (or sometimes not even possible 🙈) to keep TCP connections to the server open while idle for ages. in those situations, a good user experience needs the client to be told when "interesting" stuff happens in the mail store 👀, so it can connect and resynchronize. at the very absolute minimum, the arrival of new mail has to give the email client some kind of wake-up ⏰. lots of vendors have built their own solutions, ngl. as one example, the technique in [FINGER-HACK] has been around for years (way before cellular handsets were a thing 💀). today, a bunch of email vendors have facilities that send SMS or other simple non-stream messages to handsets when new mail lands 📱. the Open Mobile Alliance (OMA) also published a mechanism that uses WAP PUSH to send a basic message containing a URL [OMA-EMN] 💌. and the IETF is looking into ways to standardize enhanced functionality in this area 🔍.

so a "push email" experience can come from all sorts of techniques 🌈. you could have always-on TCP connectivity to the server plus the NOTIFY extension described above, or OMA EMN, or even a non-standard trigger message over SMS. no matter which one, the client finds out that new mail exists, decides whether to fetch info about it, some part of it, or all of it, and then shows it to the user 💅.

5.5. Searching and View Filters 🔎

Lemonade Message Stores MUST support the ESEARCH [IMAP-ESEARCH] extension 💯. it lets clients efficiently find the first or last messages, count matching messages, and get a list of matches in a way way more compact form 🗂️.

Lemonade Message Stores also give clients a mechanism to avoid handling an entire mailbox and instead access a view of it 🪟. this is common in lots of desktop clients as a client-side thing, and it's super useful for constrained clients that need to keep the number of messages and notification data small 🦋.

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 🗺️. it lets clients discover shared mailboxes and mailboxes that belong to other users, and gives them a normalized hierarchy view of what's available 🌸.

Lemonade Message Stores MUST support the I18NLEVEL=<n> [IMAP-I18N] extension, with <n> having the value 1 or 2 🌍. it adds support for non-English (internationalized) search and sort functions. (fun fact: I18NLEVEL=2 implies support for I18NLEVEL=1, so a Lemonade-compliant client that uses this extension MUST recognize either one 🤓.)

5.7. Forward without Download 📨

to optimize network usage for the typical case, where message content is copied to or sourced from the IMAP store, Lemonade offers a suite of extensions collectively known as "forward without download" 🚀. we'll go through it 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 📏. it's done using the ;PARTIAL= field. if an IMAP server supports PARTIAL in IMAP URLs used in the 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 🙏. it lets clients 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 lets clients 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 say that the marked message was forwarded to another email address, either embedded in or attached to a new message 💌. a mail client sets this keyword when it successfully forwards the message to another address. the usual reason is to show a different (or extra) icon on a message that's 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 marks the message as awaiting submission 🕰️. this lets you store messages waiting to go out in the same mailbox as messages that were already submitted and/or are still being edited 📂. a mail client sets this keyword when it decides the message needs to be sent 💫. when a client starts sending the message (it might be a different client from the one that decided it was pending submission), it atomically adds the $Submitted keyword, using STORE (UNCHANGEDSINCE) 🔒. once submission succeeds, the $SubmitPending keyword is atomically cleared ✅.

these two keywords let messages being actively submitted (the ones with both $Submitted and $SubmitPending set) stand out from messages waiting to be submitted, or from messages already submitted 👀. they also make it possible to find every message that was supposed to be submitted if the client doing it crashes or quits first 🛟.

Lemonade Message Stores MUST be able to store the $SubmitPending and the $Submitted keywords 💾. they MUST preserve them on the COPY operation 🫶. the servers MUST support the SEARCH KEYWORD $SubmitPending and SEARCH KEYWORD $Submitted 🔍.

Section 5.11 is non-normative 📝.

Server implementations aiming to meet OMA MEM requirements [OMA-MEM-REQ] should consider implementing [IMAP-FILTERS], which provides a way to persist the 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 🧚, letting the user control which messages get accepted and where they get filed 📂.

Lemonade Message Delivery Agents MUST support the Sieve Vacation extension [SIEVE-VACATION] 🏖️. it lets the client set up an auto-responder, usually to say you're on vacation (hence the name of the Sieve extension 🌴).

Lemonade Message Delivery Agents MUST support the Sieve Enotify extension [SIEVE-NOTIFY] 🔔. it lets a Sieve script generate notifications (like XMPP, SIP, or email) about received messages 💬.

Lemonade Message Delivery Agents MUST support the Sieve Variables extension [SIEVE-VARIABLES] 🧮. it adds variables to the Sieve scripting language. it's usually paired with Sieve Enotify or Vacation to customize responses and notifications ✍️.

Lemonade Message Delivery Agents MUST support the Sieve Relational extension [SIEVE-RELATIONAL] 📊. it adds relational comparisons to the Sieve scripting language, and it's usually used together with Sieve Enotify 🤝.

Lemonade Message Delivery Agents MUST support the Sieve Imap4Flags extension [SIEVE-IMAP4FLAGS] 🚩. it lets a Sieve script set IMAP flags/keywords when delivering a message to a mailbox. for example, you can use it to automatically mark certain messages as interesting, urgent, etc. 🔥.

Lemonade Message Delivery Agents MUST support the i;unicode-casemap comparator in Sieve [UNICODE-CASEMAP] 🌏. it's declared as comparator-i;unicode-casemap in the Sieve "require" statement, and it allows 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, since 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 in [SUBMIT], since [SUBMIT] didn't prescribe the exact procedure submission clients should use 🧐.) if the TCP connection to the submission server fails to open on port 587, the client MAY then immediately retry on a different port, such as 25 🔁. see [SUBMIT] for why port 25 is likely to fail depending on where the client is located, and it may result in a failure code during the SMTP transaction 🚧.

some other specifications are useful for 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 🏷️.

8. Forward without Download 📨🦋

8.1. Motivations ✨

okay so bestie, once email went client/server with [IMAP] and [SUBMIT], stuff that used to be a quick local disk op turned into the same data getting sent over the network again and again 🌐💀

Lemonade "forward without download" uses the [SMTP-BURL] extension to reach external sources while a message is being submitted 🦋 Pair that with [IMAP-URLAUTH] and you can pull whole message parts, or even entire messages, out of the IMAP mail store. The IMAP server and the SMTP SUBMIT server only need a minimal trust relationship for this to work. Iconic, honestly 👑

It also keeps everything in one submission protocol 🎀 So there's no risk of having a bunch of parallel, possibly divergent submission mechanisms floating around. The client can use [SUBMIT] extensions without those extensions having to be added to IMAP. And since the message submission details live in the SMTP SUBMIT server, Lemonade "forward without download" can also work with other retrieval protocols like POP, NNTP, or whatever else gets designed later 🧚💅

8.2. Message Sending Overview 💌

Sending an email is basically a few steps: starting a new draft, editing that draft, assembling the message, and then submitting it 🌸

Starting a draft and editing it happen in the MUA. Users often save the more complicated messages to an [IMAP] server (with the APPEND command and the \Draft flag) so they can come back to them later and keep editing 📝

Message assembly is when you take the final revision of the draft and combine it with external sources to make one complete message. External data gets retrieved and inserted into the message at this point 🧩

Message submission is when the assembled message gets dropped into the [ESMTP] infrastructure, usually using the [SUBMIT] protocol 📮

8.3. Traditional Strategy 🐢

The traditional way is that messages get started, edited, and assembled entirely inside an MUA. Drafts can still be saved to an [IMAP] server and pulled back down later 💾 Then the finished text gets sent to a Message Submission Agent (MSA) for delivery.

The editing and assembly steps usually blur together 🫠 If a message gets forwarded, its content is often fetched right away and stuffed into the message text. Same deal when external content gets inserted or attached: it's usually retrieved immediately and becomes part of the draft.

So every time a draft gets saved and then loaded again, that whole (possibly huge) content gets transmitted again, and so does message submission. It's a lot, bestie 😭

Back in the day this wasn't that big of a deal, because drafts, external data, and the submission mechanism were usually all on the same system as the MUA. The most common problem was running out of disk quota 💀

8.4. A New Strategy 🚀

The model separates three things: a Message User Agent (MUA), an IMAPv4Rev1 Server ([IMAP]), and an SMTP submit server ([SUBMIT]). Figure 1 shows how they fit together 🗺️

        +--------------------+               +--------------+
        |                    | <------------ |              |
        |     MUA (M)        |               | IMAPv4Rev1   |
        |                    |               |  Server      |
        |                    | ------------> | (Server I)   |
        +--------------------+               +--------------+
               ^    |                              ^     |
               |    |                              |     |
               |    |                              |     |
               |    |                              |     |
               |    |                              |     |
               |    |                              |     |
               |    |                              |     v
               |    |                        +--------------+
               |    |----------------------> |   SMTP       |
               |                             |   Submit     |
               |-----------------------------|   Server     |
                                             |  (Server S)  |
                                             +--------------+

Figure 1: Lemonade "forward without download"

Lemonade "forward without download" lets a Message User Agent compose and forward an email that combines fragments sitting on an IMAP server, without downloading those fragments to the client first 🎉✨

This section informatively describes two ways to do "forward without download," depending on where the message assembly happens 🧠 The first one uses the extended APPEND command [IMAP-CATENATE] to edit a draft in the message store and have the assembly happen on the IMAP server. This is most often used when a copy of the message is supposed to stay on the IMAP server, as discussed in Section 8.6 🗂️

The second one uses a series of BURL and BDAT commands. The client's message data and the external data fetched from the provided URL get submitted and concatenated together during assembly 🔗 The two sections after this one walk through, step by step, how "forward without download" is achieved 👣💖

8.4.1. Message Assembly Using IMAP CATENATE Extension ✨

Okay so, in the [SMTP-BURL]/[IMAP-CATENATE] flavour of the Lemonade "forward without download" strategy 💖, the MUA composes and edits the message first. Then [IMAP-CATENATE] builds the message on the IMAP server out of brand-new text plus pieces that are already sitting there. [IMAP-UIDPLUS] lets the client find out the UID of what got created 🔍, and finally an [IMAP-URLAUTH] format URL gets handed to a [SUBMIT] server so it can be submitted with the BURL [SMTP-BURL] extension. 🦋

Here's the flow for this use case, step by step 💅

M: {to I -- Optional} The client connects to the IMAP server, optionally starts TLS (if data confidentiality is required), logs in, opens a mailbox ("INBOX" in the example below), and fetches the body structures (see [IMAP]). 📬

        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 the full semantics and steps). This lets the MUA create messages on the IMAP server using new data combined with one or more message parts that are already on the server. 🧩

Quick note: 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. ⚡

     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 <bar@example.org>
     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 ask for a URLAUTH URL (see [IMAP-URLAUTH]). 🔑

I: {to M} The IMAP server sends back a URLAUTH URL that can be used later for retrieval with URLFETCH (see [IMAP-URLAUTH] for the full 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 so the SMTP submit server can fetch the message content from the IMAP server (see [IMAP-URLAUTH] for the details of the semantics and steps). This is what lets the MUA authorise 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:<bob.ar@example.org>
        M: RCPT TO:<foo@example.net>
        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 grab the message it needs to send 📥. (See [IMAP-URLAUTH] for the details of the semantics and steps. The so-called "pawn-ticket" authorization mechanism uses a URI that carries its own authorization credentials 🎟️.)

I: {to S} The server 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} The 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 that isn't essential to client operations or 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 💖

okay bestie, this one is giving "assemble the email from pieces like a Lego set" 🧱✨ In the [IMAP-URLAUTH]/[SMTP-BURL] flavor of the Lemonade "forward without download" strategy, the message gets composed and edited inside the MUA first 💅. Then, during submission [SUBMIT], the client uses BURL [SMTP-BURL] and BDAT [SMTP-BINARYMIME] commands to build the message out of multiple parts. Brand-new body parts get sent with BDAT commands, while parts that already live on the IMAP server are pointed to with [IMAP-URLAUTH] format URLs inside BURL commands 🦋

Here's the flow, step by step (so cute, I'm obsessed) 🌸

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). ✨

     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
     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:<bob.ar@example.org> BODY=BINARY
     S: 250 2.5.0 Address Ok.
     M: RCPT TO:<foo@example.net>
     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 <bar@example.org>
     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;

        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
     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 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

okay bestie, when clients submit new messages, link protection like [TLS] 🔒 stops an eavesdropper from seeing what's inside the submitted message 👀. but here's the tea: even if TLS isn't being used, the security risk is no worse when BURL is used to reference the text than when the text is submitted directly 💅. if BURL isn't used, the eavesdropper gets full access to the whole message 😭. if BURL is used, they might or might not get that access, depending on which form of BURL is in play ✨. for example, some forms only let the URL be used by an entity authorized as a Submission Server or by one specific user 🎀.

10.2. TLS

so when Lemonade clients use the BURL extension for mail submission, they have to send a URLAUTH token to the mail Submission Server 🧚. that token should be protected from interception, because otherwise someone could replay it and disclose the message contents to an attacker 🙈. [TLS]-based encryption of both the IMAP session that issues GENURLAUTH and the mail submission path will protect 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, users expect that the entire message content will be treated confidentially 🥺. to meet that expectation, the message Submission Server SHOULD use STARTTLS or a mechanism that gives equivalent data confidentiality when fetching the content referenced by that URL 💜.

10.3. Additional Extensions and Deployment Models

this spec doesn't add any extra security measures beyond the ones in the Internet Mail and Lemonade documents it references 📚.

that said, we do want to flag the security risks tied to the following 🚩:

  • Outband notifications
  • Server configuration by client
  • Client configuration by server
  • Presence of proxy servers
  • Presence of servers as intermediaries
  • In general, the deployment models considered by OMA MEM that are not conventional IETF deployment models
  • Measures to address a perceived need to traverse firewalls and mobile network intermediaries
deployments that offer these extra services or run in these environments need to check the security considerations for the relevant standards and their organization's security practices 🚨.

11. IANA Considerations

IMAP4 capabilities get 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

compared to RFC 4550, this document adds the following extra 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: any Lemonade compliant IMAP server is required to support the CAPABILITY response code

compared to RFC 4550, this document also adds new requirements on Lemonade compliant Message Delivery Agents 📬. they need to support the Sieve filtering language, along with these Sieve extensions:

  • ENOTIFY, IMAP4FLAGS, RELATIONAL, VACATION, VARIABLES, comparator-i;unicode-casemap

compared to RFC 4550, this document recommends using the DEFLATE compression method for TLS 🗜️. everything else stays the same 🌷.

and here's the extra stuff that changed or got improved since RFC 4550 (the list might be incomplete, so don't quote me on it 🙈):

  • there's a new section with additional requirements on Lemonade Mail User Agents. in particular, they're required to support the Format=flowed parameter on the text/plain media type 💖.
  • usage of the $Forwarded IMAP keyword was clarified ✍️.
  • forward-without-download examples were corrected and extended 🍓.
  • there's a new section describing in-band and out-of-band notifications from a Lemonade compliant mailstore 🔔.

13. Acknowledgements

the editors really appreciate the work and comments from the IETF Lemonade working group and the OMA MEM working group 🫶.

they especially want 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.
  • [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.
  • [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.
  • [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.

14.2. Informative References ✨

okay so this is the "if you wanna go deeper, bestie, here's the reading list" section 📚 these are the informative refs, so they're background reading and not the core spec. the list is alphabetical by tag, and every single one is here, with all the details, because citations are a whole vibe 💅

Appendix A. Errata 🔥

okay the errata are the spec getting a glow-up after people spotted bugs 🫶 all four of these were reported by Timo Sirainen and verified by Alexey Melnikov, so they're official now and the spec text is literally getting updated ✨

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:

Okay so the problem here is that clients can't really do much with unsolicited FETCH replies if they don't come with a UID 😭 it gets even messier because the text said "servers SHOULD NOT send UIDs for previously expunged messages [in VANISHED replies]", and since that isn't a MUST NOT, a server can technically still be RFC compliant in a convo like this:

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

and the client is totally stuck, because it has no idea which messages those FETCH replies are actually about 💀 so the fix is that the server MUST put UID and mod-sequence data in those untagged FETCH responses, and that's the glow-up 💖

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:

So the original Section 3.4 wanted HIGHESTMODSEQ in the tagged OK after an expunge, but that's a bit of a trap 🙈 HIGHESTMODSEQ can't be trusted unless the server sends the client every change other clients made, and even then it's super hard to get right. Here's the bad scenario:

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]

The first client probably thought only message 1 got expunged, so it never registers the second one. And if it uses QRESYNC to find out only about new expunges, it probably never will 😭 the even worse version is if the second client also removed \Deleted from message 1, because then the first client would register the wrong message as expunged. So the server MUST NOT send that HIGHESTMODSEQ in the tagged OK, and the example becomes just A202 OK done 🎀

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.

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:

So the client-side rule needed a serious upgrade 🌸 the old version let clients bump HIGHESTMODSEQ based on whatever MODSEQ FETCH came in, but servers don't have to send those in increasing order, and some commands can hold back EXPUNGE or VANISHED replies with smaller mod-sequences. Now, if a HIGHESTMODSEQ response code shows up, the client MUST use it even if it has already seen higher mod-sequences. Otherwise it takes the highest MODSEQ FETCH value it saw since the last tagged response, but only if that's bigger than what it already has. The example above walks through exactly that, and the whole point is that clients don't lose changes if the connection drops 🦋

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.

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.

This last one is the server-side mirror of 1809 🪞 a server implementing QRESYNC MUST send untagged events in a way that the client doesn't lose any changes if the connection drops. So if MODSEQ FETCH data items go out while EXPUNGE or VANISHED replies with lower mod-sequences are still being held back, the server MUST send a HIGHESTMODSEQ response code with a value lower than the EXPUNGE's mod-sequence. Check Section 5 for the example, bestie 💜

Authors' Addresses 🧚

okay the people behind it, all reachable at Isode and Oracle 🍓

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

that's the whole RFC, bestie 🌈👑

📦 where this page comes from