Network Working Group S. Maes
Request for Comments: 4550 Oracle
Category: Standards Track A. Melnikov
Isode Ltd.
June 2006
Internet Email to Support Diverse Service Environments(Lemonade) Profile
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) 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 allows clients (especially those that are
constrained in memory, bandwidth, processing power, or other areas)
to efficiently use IMAP and Submission to access and submit mail.
This includes the ability to forward received mail without needing to
download and upload the mail, to optimize submission, and to
efficiently resynchronize in case of loss of connectivity with the
server.
The Internet Email to Support Diverse Service Environments (Lemonade)
profile relies upon extensions to IMAP and Mail Submission protocols;
specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501)
extensions and the BURL extension to the SUBMIT protocol (RFC 4409).
Maes & Melnikov Standards Track [Page 1]

RFC 4550 Lemonade Profile June 20061. Introduction
Lemonade provides enhancements to Internet email to support diverse
service environments.
This document describes the Lemonade profile, which includes:
- "forward without download", which describes exchanges between
Lemonade clients and servers to allow new email messages to be
submitted incorporating content that resides on locations
external to the client.
- Quick mailbox resynchronization using [CONDSTORE].
- Several IMAP and SMTP extensions that save bandwidth and/or
number of round-trips required to send/receive data.
The organization of this document is as follows. Section 2 describes
"forward without download". Section 3 describes additional SMTP
extensions that must be supported by all Lemonade Submission servers.
Section 4 describes IMAP quick resynchronization.
1.1. Conventions Used in This Document
In examples, "M:", "I:", and "S:" indicate lines sent by the client
messaging user agent, IMAP e-mail server, and SMTP submit server,
respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
All examples in this document are optimized for Lemonade use and
might not represent examples of proper protocol usage for a general
use Submit/IMAP client. In particular, examples assume that Lemonade
Submit and IMAP servers support all Lemonade extensions described in
this document, so they don't show how to deal with absence of an
extension.
2. Forward without Download2.1. Motivations
The advent of client/server email using the [RFC3501], [RFC2821], and
[SUBMIT] protocols has changed what formerly were local disk
operations into repetitive network data transmissions.
Maes & Melnikov Standards Track [Page 3]

RFC 4550 Lemonade Profile June 2006
Lemonade "forward without download" makes use of the [BURL] SUBMIT
extension to enable access to external sources during the submission
of a message. In combination with the IMAP [URLAUTH] extension,
inclusion of message parts or even entire messages from the IMAP mail
store is possible with a minimal trust relationship between the IMAP
and SMTP SUBMIT servers.
Lemonade "forward without download" has the advantage of maintaining
one submission protocol, and thus avoids the risk of having multiple
parallel and possibly divergent mechanisms for submission. The
client can use Submit/SMTP [SUBMIT] extensions without these being
added to IMAP. Furthermore, by keeping the details of message
submission in the SMTP SUBMIT server, Lemonade "forward without
download" can work with other message retrieval protocols such as
Post Office Protocol (POP), Network News Transfer Protocol (NNTP), or
whatever else may be designed in the future.
2.2. Message Sending Overview
The act of sending an email message can be thought of as involving
multiple steps: initiation of a new draft, draft editing, message
assembly, and message submission.
Initiation of a new draft and draft editing takes place in the Mail
User Agent (MUA). Frequently, users choose to save more complex
messages on an [RFC3501] server (via the APPEND command with the
\Draft flag) for later recall by the MUA and resumption of the
editing process.
Message assembly is the process of producing a complete message from
the final revision of the draft and external sources. At assembly
time, external data is retrieved and inserted in the message.
Message submission is the process of inserting the assembled message
into the [RFC2821] infrastructure, typically using the [SUBMIT]
protocol.
2.3. Traditional Strategy
Traditionally, messages are initiated, edited, and assembled entirely
within an MUA, although drafts may be saved to an [RFC3501] server
and later retrieved from the server. The completed text is then
transmitted to a Message Submission Agent (MSA) for delivery.
Maes & Melnikov Standards Track [Page 4]

RFC 4550 Lemonade Profile June 2006
There is often no clear boundary between the editing and assembly
process. If a message is forwarded, its content is often retrieved
immediately and inserted into the message text. Similarly, when
external content is inserted or attached, the content is usually
retrieved immediately and made part of the draft.
As a consequence, each save of a draft and subsequent retrieve of the
draft transmits that entire (possibly large) content, as does message
submission.
In the past, this was not much of a problem, because drafts, external
data, and the message submission mechanism were typically located on
the same system as the MUA. The most common problem was running out
of disk quota.
2.4. Step-by-Step Description
The model distinguishes among a Mail User Agent (MUA), an IMAP4Rev1
Server ([RFC3501]), and a SMTP submit server ([SUBMIT]), as
illustrated in Figure 1.
+--------------------+ +--------------+
| | <------------ | |
| MUA (M) | | IMAPv4Rev1 |
| | | Server |
| | ------------> | (Server I) |
+--------------------+ +--------------+
^ | ^ |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | v
| | +--------------+
| |----------------------> | SMTP |
| | Submit |
|-----------------------------| Server |
| (Server S) |
+--------------+
Figure 1: Lemonade "forward without download"
Lemonade "forward without download" allows a Messaging User Agent to
compose and forward an e-mail combining fragments that are located in
an IMAP server, without having to download these fragments to the
client.
Maes & Melnikov Standards Track [Page 5]

RFC 4550 Lemonade Profile June 2006
There are two ways to perform "forward without download", based on
where the message assembly takes place. The first uses an extended
APPEND command [CATENATE] to edit a draft message in the message
store and cause the message assembly 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
provide step-by-step instructions on how "forward without download"
is achieved.
2.4.1. Message Assembly Using IMAP CATENATE Extension
In the [BURL]/[CATENATE] variant of the Lemonade "forward without
download" strategy, messages are initially composed and edited within
an MUA. The [CATENATE] extension to [RFC3501] is then used to create
the messages on the IMAP server by transmitting new text and
assembling them. The [UIDPLUS] IMAP extension is used by the client
in order to learn the Unique Identifier (UID) of the created
messages. Finally, a [URLAUTH] format URL is given to a [SUBMIT]
server for submission using the [BURL] extension.
The flow involved to support such a use case consists of:
M: {to I -- Optional} The client connects to the IMAP server,
optionally starts TLS (if data confidentiality is required),
authenticates, opens a mailbox ("INBOX" in the example below) and
fetches body structures (See [RFC3501]).
Example:
M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
"TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
"trip.txt")
"<960723163407.20117h@washington.example.com>"
"Your trip details" "BASE64" 4554 73) "MIXED"))
I: A0051 OK completed
M: {to I} The client invokes CATENATE (See [CATENATE] for details
of the semantics and steps) -- this allows the MUA to create
messages on the IMAP server using new data combined with one or
more message parts already present on the IMAP server.
Note that the example for this step doesn't use the LITERAL+
[LITERAL+] extension. Without LITERAL+, the new message is
constructed using 3 round-trips. If LITERAL+ is used, the new
message can be constructed using one round-trip.
Maes & Melnikov Standards Track [Page 6]

RFC 4550 Lemonade Profile June 2006
Also, if data confidentiality is required, the mail submission
server should start TLS before issuing the LOGIN command.
S: {to M} Submission server assembles the complete message, and 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: 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.
2.5. Normative Statements Related to Forward without Download
Lemonade-compliant IMAP servers MUST support IMAP4Rev1 [RFC3501],
CATENATE [CATENATE], UIDPLUS [UIDPLUS], and URLAUTH [URLAUTH]. This
support MUST be declared via CAPABILITY [RFC3501].
Lemonade-compliant submit servers MUST support BURL [BURL], 8BITMIME
[8BITMIME], BINARYMIME [CHUNKING], and CHUNKING [CHUNKING]. This
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.
Maes & Melnikov Standards Track [Page 14]

RFC 4550 Lemonade Profile June 20062.7. The fcc Problem
The "fcc problem" refers to 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 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 [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
Lemonade-compliant mail submission servers are expected to implement
the following set of SMTP extensions to make message submission
efficient.
Lemonade clients should take advantage of these features.
Maes & Melnikov Standards Track [Page 15]

RFC 4550 Lemonade Profile June 20063.1. Pipelining
Mobile clients regularly use networks with a relatively high latency.
Avoidance of round-trips within a transaction has a great advantage
for reduction in both bandwidth and total transaction time. For this
reason, Lemonade-compliant mail submission servers MUST support the
SMTP Service Extensions for Command Pipelining [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.
A Lemonade-compliant client SHOULD use message size declaration. In
particular, it MUST NOT send a message to a mail submission server,
if the client knows that the message exceeds the maximal message size
advertised by the submission server.
3.4. Enhanced Status Code Support
Lemonade-compliant mail submission servers MUST support SMTP Service
Extension for Returning Enhanced Error Codes [RFC2034].
3.5. TLS
Lemonade-compliant mail submission servers MUST support SMTP Service
Extension for Secure SMTP over TLS [SMTP-TLS].
4. Quick Resynchronization
Lemonade-compliant IMAP servers MUST support the CONDSTORE
[CONDSTORE] extension. It allows a client to quickly resynchronize
any mailbox by asking the server to return all flag changes that have
occurred since the last known mailbox synchronization mark.
[IMAP-DISC] shows how to perform quick mailbox resynchronization.
Maes & Melnikov Standards Track [Page 16]

RFC 4550 Lemonade Profile June 20068.1. Confidentiality Protection of Submitted Messages
When clients submit new messages, link protection such as TLS guards
against an eavesdropper seeing the contents of the submitted message.
It's worth noting, however, that even if TLS is not used, the
security risks are no worse if BURL is used to reference the text
than if the text is submitted directly. If BURL is not used, an
eavesdropper gains access to the full text of the message. If BURL
is used, the eavesdropper may or may not be able to gain such access,
depending on the form of BURL used. For example, some forms restrict
use of the URL to an entity authorized as a submission server or a
specific user.
8.2. TLS
When Lemonade clients use the BURL extension to mail submission,
which requires sending a URLAUTH token to the mail submission server,
such a token should be protected from interception to avoid a replay
attack that may disclose the contents of the message to an attacker.
TLS-based encryption of the mail submission path will provide
protection against this attack.
Lemonade clients SHOULD use TLS-protected IMAP and mail submission
channels when using BURL-based message submission to protect the
URLAUTH token from interception.
Lemonade-compliant mail submission servers SHOULD use TLS-protected
IMAP connections when fetching message content using the URLAUTH
token provided by the Lemonade client.
When a client uses SMTP STARTTLS to send a BURL command that
references non-public information, there is a user expectation that
the entire message content will be treated confidentially. To meet
this expectation, the message submission server should use STARTTLS
or a mechanism providing equivalent data confidentiality when
fetching the content referenced by that URL.
Maes & Melnikov Standards Track [Page 19]

RFC 4550 Lemonade Profile June 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and 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 takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Maes & Melnikov Standards Track [Page 23]