RFC 4550

Internet Email to Support Diverse Service Environments (Lemonade) Profile

📅 published June 2006, from ietf

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

Okay bestie, let's talk about RFC 4550 🦋 It's a Standards Track document from June 2006, written by S. Maes (Oracle) and A. Melnikov (Isode Ltd.) 💖 The Lemonade profile is a whole set of required extensions, restrictions, and usage modes for IMAP and mail submission. It's giving "make email work well for devices that are low on memory, bandwidth, or processing power" 🌸 Its status is Standards Track, it's a Network Working Group document, and it's the work of the Internet Society (2006). The title block doesn't say anything about obsoleting or updating other RFCs, so there's nothing to report there 🧚

This is part 1 of 5, so more is coming, no sign-off yet 💅

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 (C) The Internet Society (2006).

Abstract ✨

This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile lets clients that are constrained in memory, bandwidth, processing power, or other areas use IMAP and Submission to access and submit mail efficiently 🫶 That includes forwarding received mail without downloading and re-uploading it, optimizing submission, and efficiently resynchronizing after a loss of connectivity with the server 🔥

The Internet Email to Support Diverse Service Environments (Lemonade) profile relies on extensions to IMAP and Mail Submission protocols. Specifically, it uses the URLAUTH and CATENATE IMAP protocol extensions (RFC 3501) and the BURL extension to the SUBMIT protocol (RFC 4409) 🎀

Table of Contents 🍓

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. Forward without Download ........................................3
      2.1. Motivations ................................................3
      2.2. Message Sending Overview ...................................4
      2.3. Traditional Strategy .......................................4
      2.4. Step-by-Step Description ...................................5
           2.4.1. Message Assembly Using IMAP CATENATE Extension ......6
           2.4.2. Message Assembly Using SMTP CHUNKING and
                  BURL Extensions ....................................10
      2.5. Normative Statements Related to Forward without Download ..14
      2.6. Security Considerations for "pawn-tickets" ................14
      2.7. The fcc Problem ...........................................15
      2.8. Registration of $Forwarded IMAP Keyword ...................15
   3. Message Submission .............................................15
      3.1. Pipelining ................................................16
      3.2. DSN Support ...............................................16
      3.3. Message Size Declaration ..................................16
      3.4. Enhanced Status Code Support ..............................16
      3.5. TLS .......................................................16
   4. Quick Resynchronization ........................................16
   5. Additional IMAP Extensions .....................................17
   6. Summary of the Required IMAP and SMTP Extensions ...............17
   7. Future work ....................................................18
   8. Security Considerations ........................................18
      8.1. Confidentiality Protection of Submitted Messages ..........19
      8.2. TLS .......................................................19
   9. References .....................................................20
      9.1. Normative References ......................................20
      9.2. Informative References ....................................21
   10. Acknowledgements ..............................................21

1. Introduction 🌸

Lemonade is all about making Internet email better for diverse service environments 💅

This document describes the Lemonade profile, which includes:

  • "Forward without download", which covers exchanges between Lemonade clients and servers so new email messages can be submitted with content that lives somewhere outside the client 🦋
  • Quick mailbox resynchronization using [CONDSTORE] ✨
  • Several IMAP and SMTP extensions that save bandwidth and/or the number of round-trips needed to send and receive data 🌈

Here's the roadmap: Section 2 covers "forward without download". Section 3 covers additional SMTP extensions that must be supported by all Lemonade Submission servers. Section 4 covers IMAP quick resynchronization 🧚

1.1. Conventions Used in This Document 💖

In examples, "M:", "I:", and "S:" mean lines sent by the client messaging user agent, the IMAP e-mail 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 [RFC2119] 👑

All examples in this document are optimized for Lemonade use and might not show proper protocol usage for a general-use Submit/IMAP client 🙈 In particular, the examples assume that Lemonade Submit and IMAP servers support all Lemonade extensions described in this document, so they don't show how to handle the absence of an extension 💀

2. Forward without Download 🦋

2.1. Motivations 💜

The arrival of client/server email using the [RFC3501], [RFC2821], and [SUBMIT] protocols turned what used to be local disk operations into repetitive network data transmissions 😭

Lemonade "forward without download" uses the [BURL] SUBMIT extension to enable access to external sources while a message is being submitted ✨ Combined with the IMAP [URLAUTH] extension, including message parts or even whole messages from the IMAP mail store is possible with a minimal trust relationship between the IMAP and SMTP SUBMIT servers 🔥

Lemonade "forward without download" keeps one submission protocol, so it avoids the risk of having multiple parallel and possibly divergent submission mechanisms 👑 The client can use Submit/SMTP [SUBMIT] extensions without those being added to IMAP. Also, 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 Post Office Protocol (POP), Network News Transfer Protocol (NNTP), or whatever else may be designed in the future 🌈

2.2. Message Sending Overview 🎀

Sending an email message can be thought of as several steps: starting a new draft, editing the draft, assembling the message, and submitting the message 🌸

Starting a new draft and editing it happen in the Mail User Agent (MUA). Often, users save more complex messages on an [RFC3501] server (via the APPEND command with the \Draft flag) so the MUA can recall them later and resume editing 🧚

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 into the message 💅

Message submission is the process of inserting the assembled message into the [RFC2821] infrastructure, typically using the [SUBMIT] protocol 🦋

2.3. Traditional Strategy 💖

Traditionally, messages are started, edited, and assembled entirely within an MUA, although drafts may be saved to an [RFC3501] server and retrieved from it later. The completed text is then sent to a Message Submission Agent (MSA) for delivery 🫶

There's often no clear boundary between the editing and assembly process. If a message is forwarded, its content is often retrieved right away and inserted into the message text. Similarly, when external content is inserted or attached, it's usually retrieved immediately and made part of the draft 😭

As a result, every save of a draft and every later retrieval of that draft transmits the entire (possibly large) content, and so does message submission 💀

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

2.4. Step-by-Step Description ✨

The model distinguishes between a Mail User Agent (MUA), an IMAP4Rev1 Server ([RFC3501]), and an SMTP submit server ([SUBMIT]), as shown 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" lets a Messaging User Agent compose and forward an e-mail that combines fragments located on an IMAP server, without downloading those fragments to the client 🧚💜

There are two ways to perform "forward without download", depending on where message assembly happens. The first uses an extended APPEND command [CATENATE] to edit a draft message in the message store and have the message assembled on the IMAP server 🦋 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 give step-by-step instructions on how "forward without download" is achieved 👑

Part 1 of 5 done! 🌈 Say "next" and I'll keep going with Section 2.4.1 🫶

2.4.1. Message Assembly Using IMAP CATENATE Extension ✨

okay so this is the [BURL]/[CATENATE] version of Lemonade's "forward without download" strategy 💖 The MUA composes and edits the message locally first. Then the [CATENATE] extension to [RFC3501] builds the message on the IMAP server by sending new text and stitching it together with existing parts 🧩 The [UIDPLUS] IMAP extension lets the client learn the Unique Identifier (UID) of the new message. Last step: a [URLAUTH] format URL gets handed to a [SUBMIT] server, which submits it using the [BURL] extension. literally so clean 🦋

Here's the flow for this use case:

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 [RFC3501]). 🔐

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 [CATENATE] for details of the semantics and steps). This is the part where the MUA gets to build messages on the IMAP server out of new data plus one or more message parts that are already sitting there 🪄

Quick note: this example doesn't use the LITERAL+ [LITERAL+] extension. Without LITERAL+, the new message takes 3 round-trips to build. With LITERAL+, it only takes one round-trip. so efficient, bestie 🏃‍♀️💨

M: A0052 APPEND Sent FLAGS (\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 [URLAUTH]). 🙏

I: {to M} The IMAP server hands back a URLAUTH URL that can be used later with URLFETCH (see [URLAUTH] for details of the semantics and steps). ✨

M: A0054 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: A0054 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 [BURL] for details of the semantics and steps). This is how the MUA authorizes the SMTP submit server to access the message that got composed in the CATENATE step 🫶 Heads up: the second EHLO command is required after a successful STARTTLS command. There's also a possible third EHLO command that's required if the second EHLO response doesn't list any BURL options. Section 2.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=
S: 235 2.7.0 PLAIN authentication successful.
M: MAIL FROM:<bob.ar@example.org>
S: 250 2.5.0 Address Ok.
M: RCPT TO:<foo@example.net>
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's going to send. (See [URLAUTH] for 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} Gives over the message that was composed in 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...
S: a002 OK URLFETCH completed
I: a003 LOGOUT
S: * BYE See you later
S: a003 OK Logout successful

Note: if the IMAP server doesn't send the CAPABILITY response code in its greeting, the mail submission server must issue the CAPABILITY command to find out which IMAP extensions are supported, as described in RFC 3501. 🕵️‍♀️

Also, if data confidentiality isn't required, the mail submission server may skip the STARTTLS command before it issues the LOGIN command. 🙃

S: {to M} The submission server puts the complete message together, and if the assembly works, it sends OK back to the MUA 🎉

S: 250 2.5.0 Ok.

M: {to I} The client marks the message that holds the forwarded attachment on the IMAP server 🏷️

M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 OK STORE completed
Note: the UID STORE command shown above only works if the marked message is in the currently selected mailbox. Otherwise, it needs a SELECT first. This command can be omitted. The untagged FETCH response comes from [CONDSTORE]. The $Forwarded IMAP keyword is described in Section 2.8. 💅

2.4.2. Message Assembly Using SMTP CHUNKING and BURL Extensions ✨

okay so in the [BURL]/[CHUNKING] version of the Lemonade "forward without download" strategy, messages get composed and edited in an MUA first 💅 then, during submission [SUBMIT], BURL [BURL] and BDAT [CHUNKING] commands stitch the message together from multiple parts. 🧩 New body parts come in through BDAT commands, while existing body parts get referenced with [URLAUTH] format URLs in BURL commands. it's giving teamwork 🫶

here's the flow for this use case:

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 [RFC3501]) 📬

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 uses the GENURLAUTH command to request URLAUTH URLs (see [URLAUTH]) that point at pieces of the message to be assembled 🧁

I: {to M} the IMAP server hands back URLAUTH URLs that can be used later with URLFETCH (see [URLAUTH] for details of the semantics and steps) 🌸

M: A0054 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: A0054 OK GENURLAUTH completed

M: {to S} the client connects to the mail submission server and starts a new mail transaction 💌 It uses BURL to tell the SMTP submit server to fetch pieces of the message to be sent from the IMAP server (see [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 2.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 grab the pieces of the message to be sent (see [URLAUTH] for 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 IMAP server 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: a001 LOGIN submitserver secret
I: a001 OK submitserver logged in
S: a002 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...
S: a002 OK URLFETCH completed
I: a003 LOGOUT
S: * BYE See you later
S: a003 OK Logout successful

Note that if the IMAP server doesn't send CAPABILITY response code in the greeting, the mail submission server must issue the CAPABILITY command to learn about supported IMAP extensions as described in RFC 3501. 🔍

Also, if data confidentiality is required, the mail submission server should start TLS before issuing the LOGIN command. 🔐

S: {to M} the submission server assembles the complete message, and if the assembly succeeds, it acknowledges acceptance by sending a 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: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 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. The untagged FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword is described in Section 2.8.

okay the rules, bestie 🙈 if you're a Lemonade-compliant IMAP server, you MUST support IMAP4Rev1 [RFC3501], CATENATE [CATENATE], UIDPLUS [UIDPLUS], and URLAUTH [URLAUTH]. And that support MUST be declared via CAPABILITY [RFC3501]. 💜

if you're a Lemonade-compliant submit server, you MUST support BURL [BURL], 8BITMIME [8BITMIME], BINARYMIME [CHUNKING], and CHUNKING [CHUNKING]. That support MUST be declared via EHLO [RFC2821]. BURL MUST support URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap" option following the BURL EHLO keyword (see [BURL] for more details). 🌈

Additional normative statements are provided in other sections. ✨

2.6. Security Considerations for "pawn-tickets" 🔒

The so-called "pawn-ticket" authorization mechanism uses a URI, which contains its own authorization credentials using [URLAUTH]. The advantage of this mechanism is that the SMTP submit [SUBMIT] server cannot access any data on the [RFC3501] 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. 🎀

2.7. The fcc Problem 📨

the "fcc problem" is about delivering a copy of a message to a "file carbon copy" recipient. 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 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 [CATENATE] extension to [RFC3501] can be used to address the fcc problem. The final message is constructed in the mailbox designed for outgoing mail. Note that the [CATENATE] extension can only create a single message and only on the server that stages the outgoing message for submission. Additional copies of the message can be created on the same server using one or more COPY commands. 🧚

2.8. Registration of $Forwarded IMAP Keyword 🏷️

the $Forwarded IMAP keyword is used by several IMAP clients to specify that the message was resent 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-compliant servers MUST be able to store the $Forwarded keyword. They MUST preserve it on the COPY operation. The servers MUST support the SEARCH KEYWORD $Forwarded. 💅

3. Message Submission ✨

okay so bestie, Lemonade-compliant mail submission servers are expected to implement this set of SMTP extensions so that message submission is efficient 💅 and Lemonade clients should totally take advantage of these features 🫶

3.1. Pipelining 🚀

mobile clients are always on networks with kinda high latency 😭 so avoiding round-trips inside a transaction is a huge win for bandwidth AND total transaction time. that's why Lemonade-compliant mail submission servers MUST support the SMTP Service Extensions for Command Pipelining [RFC2920] ✨

clients SHOULD pipeline SMTP commands when possible 💖

3.2. DSN Support 📬

Lemonade-compliant mail submission servers MUST support SMTP service extensions for delivery status notifications [RFC3461] 🌸

3.3. Message Size Declaration 📏

Lemonade-compliant mail submission servers MUST support the SMTP Service Extension for Message Size Declaration [RFC1870] 🎀

Lemonade-compliant mail submission servers MUST "expand" all BURL parts before enforcing a message size limit. the vibe here is "expand first, THEN check the size" 🙈

a Lemonade-compliant client SHOULD use message size declaration. and honestly? it MUST NOT send a message to a mail submission server if the client already knows the message is bigger than the maximal message size the submission server advertised 💀

3.4. Enhanced Status Code Support 🔥

Lemonade-compliant mail submission servers MUST support the SMTP Service Extension for Returning Enhanced Error Codes [RFC2034] 💜

3.5. TLS 🔒

Lemonade-compliant mail submission servers MUST support the SMTP Service Extension for Secure SMTP over TLS [SMTP-TLS] 👑

4. Quick Resynchronization ⚡

Lemonade-compliant IMAP servers MUST support the CONDSTORE [CONDSTORE] extension. it lets a client quickly resync ANY mailbox by asking the server to send back all the flag changes that happened since the last known mailbox synchronization mark. so iconic 🦋

[IMAP-DISC] shows how to do quick mailbox resynchronization 🧚

5. Additional IMAP Extensions 🎀

Lemonade-compliant IMAP servers MUST support the NAMESPACE [NAMESPACE] extension. it lets clients discover shared mailboxes and mailboxes that belong to other users 🍓

Lemonade-compliant IMAP servers MUST support the LITERAL+ [LITERAL+] extension. it saves clients a round-trip every time a non-synchronizing literal gets sent ✨

Lemonade-compliant IMAP servers MUST support the IDLE [IDLE] extension. this one is giving instant notifications about changes in the selected mailbox WITHOUT the client needing to poll 🔔

Lemonade-compliant IMAP servers MUST support IMAP over TLS [RFC3501] as required by RFC 3501 🔐

6. Summary of the Required IMAP and SMTP Extensions 📋

okay here's the cheat sheet, bestie 💅 the tables are copied exactly as they are in the spec:

  -----------------------------------------------------|
  |  Name of SMTP extension |            Comment       |
  |-------------------------|--------------------------|
  |        PIPELINING       |       Section 3.1        |
  |-------------------------|--------------------------|
  |           DSN           |       Section 3.2        |
  |-------------------------|--------------------------|
  |           SIZE          |       Section 3.3        |
  |-------------------------|--------------------------|
  |  ENHANCEDSTATUSCODES    |       Section 3.4        |
  |-------------------------|--------------------------|
  |        STARTTLS         |       Section 3.5        |
  |-------------------------|--------------------------|
  |           BURL          | Forward without download,|
  |                         |         Section 2        |
  |-------------------------|--------------------------|
  | URLAUTH support in BURL |       Section 2.5        |
  |-------------------------|--------------------------|
  |        CHUNKING,        |       Section 2.5        |
  |       BINARYMIME        |       Section 2.5        |
  |-------------------------|--------------------------|
  |        8BITMIME,        |    Required by BURL      |
  |-------------------------|--------------------------|
  |          AUTH           |  Required by Submission, |
  |                         |      See [SMTPAUTH].     |
  |-------------------------|--------------------------|
  -----------------------------------------------------|
  |  Name of IMAP extension |            Comment       |
  |        or feature       |                          |
  |-------------------------|--------------------------|
  |        NAMESPACE        |       Section 5          |
  |-------------------------|--------------------------|
  |        CONDSTORE        |       Section 4          |
  |-------------------------|--------------------------|
  |        STARTTLS         |Required by IMAP (RFC3501)|
  |-------------------------|--------------------------|
  |        URLAUTH,         | Forward without download,|
  |        CATENATE,        |        Section 2         |
  |        UIDPLUS          |                          |
  |-------------------------|--------------------------|
  |        LITERAL+         |       Section 5          |
  |-------------------------|--------------------------|
  |          IDLE           |       Section 5          |
  |-------------------------|--------------------------|
  | $Forwarded IMAP keyword |       Section 2.8        |
  |-------------------------|--------------------------|

7. Future work 🔭

the Lemonade Working Group is looking into more issues around email on mobile devices, possibly including:

  • Media conversion (static and possibly streamed)
  • Transport optimization for low or costly bandwidth and less reliable mobile networks (e.g., quick reconnect)
  • Server to client notifications, possibly outside of the traditional IMAP band
  • Dealing with firewall and intermediaries
  • Compression and other bandwidth optimization
  • Filtering
  • Other considerations for mobile clients

the future is bright, bestie ✨

8. Security Considerations 🛡️

this section is SERIOUS, bestie. read it carefully 🚨

security considerations on Lemonade "forward without download" are discussed throughout Section 2. more security considerations can be found in [RFC3501] and in the other documents that describe the SMTP and IMAP extensions making up the Lemonade profile 🔍

note that the mandatory-to-implement authentication mechanism for SMTP submission is described in [SUBMIT]. the mandatory-to-implement authentication mechanism for IMAP is described in [RFC3501] 🔑

8.1. Confidentiality Protection of Submitted Messages 🤫

when clients submit new messages, link protection like TLS guards against an eavesdropper seeing the contents of the submitted message. BUT here's the tea: 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 gets the full text of the message. if BURL IS used, the eavesdropper may or may not be able to get that access, depending on which form of BURL is used. for example, some forms restrict use of the URL to an entity authorized as a submission server or a specific user 🙅‍♀️

8.2. TLS 🔐

when Lemonade clients use the BURL extension for mail submission, which requires sending a URLAUTH token to the mail submission server, that token should be protected from interception. otherwise a replay attack could disclose the message contents to an attacker 😱 TLS-based encryption of the mail submission path protects against this attack 💖

Lemonade clients SHOULD use TLS-protected IMAP and mail submission channels when using BURL-based message submission, so the URLAUTH token doesn't get intercepted 🫶

Lemonade-compliant mail submission servers SHOULD use TLS-protected IMAP connections when fetching message content using the URLAUTH token the client provided 🔒

when a client uses SMTP STARTTLS to send a BURL command that references non-public information, there's a user expectation that the entire message content gets treated confidentially. to meet that expectation, the message submission server should use STARTTLS or a mechanism that provides equivalent data confidentiality when fetching the content referenced by that URL 🌈

9. References 📚

9.1. Normative References

  • [BURL] Newman, C. "Message Submission BURL Extension", RFC 4468, May 2006.
  • [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
  • [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
  • [CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006.
  • [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2920] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
  • [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
  • [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
  • [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
  • [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
  • [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
  • [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
  • [URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
  • [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
  • [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
  • [SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
  • [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
  • [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
  • [IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.

9.2. Informative References

  • [IMAP-DISC] Melnikov, A., "Synchronization operations for disconnected IMAP4 clients", Work in Progress, October 2004.

10. Acknowledgements 💌

this document is a product of the Lemonade WG 🍋 the editors thank the Lemonade WG members who contributed comments and corrections, in particular: Randy Gellens, Dave Cridland, and Greg Vaudreuil 🫶

this document borrows some text from "Message Submission" (February 2004) by Mark Crispin, as well as from the trio [BURL], [CATENATE], and [URLAUTH] ✨

Authors' Addresses 💌

Here's where to find our two authors, so you can slide into their inboxes 🦋

Stephane H. Maes
Oracle Corporation
500 Oracle Parkway
M/S 4op634
Redwood Shores, CA 94065
USA

Phone: +1-650-607-6296
EMail: stephane.maes@oracle.com
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex
TW12 2BX
UK

EMail: Alexey.melnikov@isode.com

Copyright (C) The Internet Society (2006). 🌸

This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth there, the authors keep all their rights. 💜

This document and the information in it are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭

Intellectual Property 🔥

The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or how far they reach. It also doesn't say whether any license under those rights might or might not be available, and it hasn't independently tried to find any such rights. More info on how rights work for RFC documents is in BCP 78 and BCP 79. 📚

Copies of IPR disclosures sent to the IETF Secretariat, along with any assurances of licenses that might be offered, and the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr. 🔍

The IETF invites anyone interested to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 🫶

Acknowledgement 🌈

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). That's the crew keeping all these RFCs organized, and we love them for it 👑✨

📦 where this page comes from