LEMONADE Working Group S. Maes, Ed.
Internet-Draft Oracle
Expires: December 31, 2006 A. Melnikov, Ed.
Isode Limited
D. Cridland, Ed.
Inventure Systems Ltd
June 29, 2006
LEMONADE profile bis
draft-ietf-lemonade-profile-bis-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the LEMONADE profile. It contains pointers
to or descriptions of all the features that are normatively part of
this version of the LEMONADE profile.
This document describes a profile (a set of required extensions,
Maes, et al. Expires December 31, 2006 [Page 1]
Internet-Draft LEMONADE profile bis June 2006
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 Lemonade profile relies upon extensions to IMAP and Mail
Submission protocols; specifically URLAUTH and CATENATE IMAP protocol
extensions and BURL extension to the SUBMIT protocol.
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Forward without download . . . . . . . . . . . . . . . . . . . 5
3.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Message Sending Overview . . . . . . . . . . . . . . . . . 5
3.3. Traditional Strategy . . . . . . . . . . . . . . . . . . . 6
3.4. Step by step description . . . . . . . . . . . . . . . . . 7
3.4.1. Message assembly using IMAP CATENATE extension . . . . 7
3.4.2. Message assembly using SMTP CHUNKING and BURL
extensions . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Normative statements related to forward without
download . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Security Considerations for pawn-tickets. . . . . . . . . 16
3.7. Copies of Sent messages: The fcc problem . . . . . . . . . 17
3.8. Registration of $Forwarded IMAP keyword . . . . . . . . . 17
4. Message Submission . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Pipelining . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. DSN Support . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Message size declaration . . . . . . . . . . . . . . . . . 18
4.4. Enhanced status code Support . . . . . . . . . . . . . . . 18
4.5. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Message Store . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Quick resynchronization . . . . . . . . . . . . . . . . . 19
5.2. Message part handling . . . . . . . . . . . . . . . . . . 19
5.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 19
5.4. Out of band notifications . . . . . . . . . . . . . . . . 19
5.5. Virtual Mailboxes . . . . . . . . . . . . . . . . . . . . 20
5.6. Additional IMAP extensions . . . . . . . . . . . . . . . . 20
6. Summary of the required IMAP and SMTP extensions . . . . . . . 21
7. OMA MEM Requirement document . . . . . . . . . . . . . . . . . 21
7.1. OMA MEM Architecture . . . . . . . . . . . . . . . . . . . 22
7.2. OMA MEM Deployment Issues . . . . . . . . . . . . . . . . 22
Maes, et al. Expires December 31, 2006 [Page 2]
Internet-Draft LEMONADE profile bis June 2006
7.3. OMA MEM proxy . . . . . . . . . . . . . . . . . . . . . . 22
7.4. IETF LEMONADE Architecture . . . . . . . . . . . . . . . . 22
7.5. LEMONADE profile logical architecture . . . . . . . . . . 24
7.5.1. Relationship between the OMA MEM and LEMONADE
logical architectures . . . . . . . . . . . . . . . . 24
7.5.2. LEMONADE realization of OMA MEM with non-LEMONADE
compliant servers . . . . . . . . . . . . . . . . . . 26
7.6. Filters and server to client notifications and LEMONADE . 27
7.7. LEMONADE Profile features . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8.1. Confidentiality Protection of Submitted Messages . . . . . 30
8.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.3. Additional extensions and deployment models . . . . . . . 31
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Version history . . . . . . . . . . . . . . . . . . . . . . . 31
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Streaming attachments . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 39
Maes, et al. Expires December 31, 2006 [Page 3]
Internet-Draft LEMONADE profile bis June 2006
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].
Other capitalised words are typically names of extensions or commands
- these are uppercased for clarity only, and are case-insensitive.
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 do not demonstrate fallbacks in the absence of
an extension.
2. Introduction
LEMONADE provides enhancements to Internet email to support diverse
service environments.
This document describes the LEMONADE profile that includes:
o "Forward without download" that describes exchanges between
Lemonade clients and servers to allow to submit new email messages
incorporating content which resides on locations external to the
client.
o Quick mailbox resynchronization using [RFC4551].
o Several IMAP and SMTP extensions that allow saving bandwidth
and/or number of round trips required to send/receive data.
o Extensions to provide support to realizations of OMA mobile email
enabler (MEM) [MEM-req] [MEM-arch] using Internet Mail protocols
defined by the IETF.
<<Editor's note: This document contains the current view of the work.
It refers to stable specifications and work in progress. As the work
progress, it is expected that this document will evolve and be
updated accordingly. As a result some of the statements about some
specification may not yet be supported by the references. When that
is the case, these specifications are expected to be be updated.>>
Also, it is to be noted that this document solely describes
normatively the LEMONADE profile. It discusses LEMONADE
understanding of the work in progress at OMA MEM ([MEM-req] and [MEM-
Maes, et al. Expires December 31, 2006 [Page 4]
Internet-Draft LEMONADE profile bis June 2006
arch] but does not provide a normative reading of these documents.
Readers MUST refer to the Open Mobile Alliance web site for normative
references on the Mobile Email Enabler (OMA MEM). The LEMONADE
working group believes that the LEMONADE profile can be used as basis
for an OMA technical specification of a realization based on LEMONADE
of the OMA MEM enabler.
3. Forward without download
3.1. Motivations
The advent of client/server email using the [RFC3501], [RFC2821] and
[RFC4409] protocols has changed what formerly were local disk
operations to become repetitive network data transmissions.
Lemonade "forward without download" makes use of the [RFC4468] SUBMIT
extension to enable access to external sources during the submission
of a message. In combination with the IMAP [RFC4467] 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 [RFC4409] extensions without these being
added to IMAP. Furthermore, by keeping the details of message
submission in the SMTP SUBMIT server, Lemonade "forward without
download" can work with other message retrieval protocols such as
POP, NNTP, or whatever else may be designed in the future.
3.2. Message Sending Overview
The act of sending an email message can be thought of as involving
multiple steps: initiation of a new draft, draft editing, message
assembly, and message submission.
Initiation of a new draft and draft editing takes place in the MUA.
Frequently, users choose to save more complex messages on an
[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
Maes, et al. Expires December 31, 2006 [Page 5]
Internet-Draft LEMONADE profile bis June 2006
into the [RFC2821] infrastructure, typically using the [RFC4409]
protocol.
3.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 an MSA for delivery.
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.
Maes, et al. Expires December 31, 2006 [Page 6]
Internet-Draft LEMONADE profile bis June 2006
3.4. Step by step description
The model distinguishes between a Messaging User Agent (MUA), an
IMAPv4Rev1 Server ([RFC3501]) and a SMTP submit server ([RFC4409]),
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.
There are two ways to perform "forward without download" based on
where the message assembly takes place. The first uses extended
APPEND command [RFC4469] 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.
3.4.1. Message assembly using IMAP CATENATE extension
In the BURL [RFC4468]/CATENATE [RFC4469] variant of the Lemonade
"forward without download" strategy, messages are initially composed
and edited within an MUA. The [RFC4469] extension to [RFC3501] is
then used to create the messages on the IMAP server by transmitting
Maes, et al. Expires December 31, 2006 [Page 7]
Internet-Draft LEMONADE profile bis June 2006
new text and assembling them. The UIDPLUS [RFC4315] IMAP extension
is used by the client in order to learn the UID of the created
messages. Finally a [RFC4467] format URL is given to a [RFC4409]
server for submission using the BUTL [RFC4468] 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 [RFC4469] 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+
[RFC2088] 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, et al. Expires December 31, 2006 [Page 8]
Internet-Draft LEMONADE profile bis June 2006
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 GENURLAUTH command to request a URLAUTH URL
(See [RFC4467]).
I: {to M} The IMAP server returns a URLAUTH URL suitable for later
retrieval with URLFETCH (See [RFC4467] 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 to let the SMTP submit
server fetch the content of the message from the IMAP server (See
[RFC4468] for details of the semantics and steps -- this allows the
Maes, et al. Expires December 31, 2006 [Page 9]
Internet-Draft LEMONADE profile bis June 2006
MUA to authorize the SMTP submit server to access the message
composed as a result of the CATENATE step). Note that the second
EHLO command is required after a successful STARTTLS command. Also
note that there might be a third required EHLO command if the second
EHLO response doesn't list any BURL options. Section 3.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 fetch the
message to be sent (See [RFC4467] for details of the semantics and
steps. The so-called "pawn-ticket" authorization mechanism uses a
URI which contains its own authorization credentials.).
Maes, et al. Expires December 31, 2006 [Page 10]
Internet-Draft LEMONADE profile bis June 2006
I: {to S} Provides the message composed as a result of the CATENATE
step).
Mail submission server opens 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 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
[RFC3501].
Also, 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 and 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: 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
Maes, et al. Expires December 31, 2006 [Page 11]
Internet-Draft LEMONADE profile bis June 2006
message is in the currently selected mailbox; otherwise, it requires
a SELECT. This command can be omitted, as it simply changes non-
operational metadata not essential to client operations or
interoperability. The untagged FETCH response is due to [RFC4551].
The $Forwarded IMAP keyword is described in Section 3.8.
3.4.2. Message assembly using SMTP CHUNKING and BURL extensions
In the [RFC4468]/[RFC3030] variant of the Lemonade "forward without
download" strategy, messages are initially composed and edited within
an MUA. During submission [RFC4409], BURL [RFC4468] and BDAT
[RFC3030] commands are used to create the messages from multiple
parts. New body parts are supplied using BDAT commands, while
existing body parts are referenced using [RFC4467] format URLs in
BURL commands.
The flow involved to support such a use case consists of:
M: {to I -- Optional} The client connects to the IMAP server,
optionally starts TLS (if data confidentiality is required),
authenticates, opens a mailbox ("INBOX" in the example below) and
fetches body structures (See [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 uses GENURLAUTH command to request URLAUTH URLs
(See [RFC4467]) referencing pieces of the message to be assembled.
I: {to M} The IMAP server returns URLAUTH URLs suitable for later
retrieval with URLFETCH (See [RFC4467] for details of the semantics
and steps).
Maes, et al. Expires December 31, 2006 [Page 12]
Internet-Draft LEMONADE profile bis June 2006
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 instruct the SMTP
submit server to fetch from the IMAP server pieces of the message to
be sent (See [RFC4468] 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 3.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
Maes, et al. Expires December 31, 2006 [Page 13]
Internet-Draft LEMONADE profile bis June 2006
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;
Maes, et al. Expires December 31, 2006 [Page 14]
Internet-Draft LEMONADE profile bis June 2006
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 [RFC4467] 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.
Mail submission server opens 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
Maes, et al. Expires December 31, 2006 [Page 15]
Internet-Draft LEMONADE profile bis June 2006
[RFC3501].
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. As in the previous example, this command is not critical,
and can be omitted. The untagged FETCH response is due to [RFC4551].
The $Forwarded IMAP keyword is described in Section 3.8.
3.5. Normative statements related to forward without download
Lemonade compliant IMAP servers MUST support IMAPv4Rev1 [RFC3501],
CATENATE [RFC4469], UIDPLUS [RFC4315] and URLAUTH [RFC4467]. This
support MUST be declared via CAPABILITY [RFC3501].
Lemonade compliant submit servers MUST support the BURL [RFC4468],
8BITMIME [RFC1652], BINARYMIME [RFC3030] and CHUNKING [RFC3030].
This support MUST be declared via EHLO [RFC2821]. BURL MUST support
URLAUTH type URLs [RFC4467], and thus MUST advertise the "imap"
option following the BURL EHLO keyword (See [RFC4468] for more
details).
Additional normative statements are provided in other sections.
3.6. Security Considerations for pawn-tickets.
The so-called "pawn-ticket" authorization mechanism uses a URI, which
contains its own authorization credentials using [RFC4467]. The
advantage of this mechanism is that the SMTP submit [RFC4409] 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
Maes, et al. Expires December 31, 2006 [Page 16]
Internet-Draft LEMONADE profile bis June 2006
SMTP submit [RFC4409] server is authorized to access, can be revoked
by the client, and can have a time-limited validity.
3.7. 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" which represents the "problem"
aspect of the "fcc problem".
The BURL [RFC4468] 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 [RFC3501]. Note that
APPEND, including when enhanced by [RFC4469], can only create a
single message and this is only of use on the server which stages the
outgoing message for submission. Additional copies of the message
can be created on the same server using one or more COPY commands.
3.8. Registration of $Forwarded IMAP keyword
The $Forwarded IMAP keyword is used by several IMAP clients to
specify that the marked message was forwarded to another email
address, embedded within or attached to a new message. A mail client
sets this keyword when it successfully forwards the message to
another email address. Typical usage of this keyword is to show a
different (or additional) icon for a message that has been forwarded.
Once set the flag SHOULD NOT be cleared.
Lemonade 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.
4. 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, et al. Expires December 31, 2006 [Page 17]
Internet-Draft LEMONADE profile bis June 2006
4.1. Pipelining
Mobile clients regularly use networks with a relatively high latency.
Avoidance of round-trips within a transaction has a great advantage
for the reduction in both bandwidth and total transaction time. For
this reason LEMONADE compliant mail submission servers MUST support
the SMTP Service Extensions for Command Pipelining [RFC2197].
Clients SHOULD pipeline SMTP commands when possible.
4.2. DSN Support
LEMONADE compliant mail submission servers MUST support SMTP service
extensions for delivery status notifications [RFC3461].
4.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 resolve all BURL
parts before enforcing a message size limit.
A LEMONADE compliant client SHOULD use message size declaration. In
particular the client MUST NOT send a message to a mail submission
server, if it knows that the message exceeds the maximal message size
advertised by the submission server. When including a message size
in the MAIL FROM command, the client MUST use a value that is at
least as large as the size of the assembled message data after
resolution of all BURL parts.
4.4. Enhanced status code Support
LEMONADE compliant mail submission servers MUST support SMTP Service
Extension for Returning Enhanced Error Codes [RFC2034].
4.5. TLS
LEMONADE Compliant mail submission servers MUST support SMTP Service
Extension for Secure SMTP over TLS [RFC3207].
5. Message Store
Lemonade compliant message store services provide an IMAP service
with the following set of extensions in order to provide both
efficient access to the message store and support constrained devices
more effectively.
Maes, et al. Expires December 31, 2006 [Page 18]
Internet-Draft LEMONADE profile bis June 2006
5.1. Quick resynchronization
LEMONADE Compliant IMAP servers MUST support the CONDSTORE [RFC4551]
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.
[RFC4549] shows how to perform quick mailbox resynchronization.
In addition, LEMONADE Compliant IMAP servers MUST support the
RECONNECT [I-D.ietf-lemonade-reconnect] extension to provide quick
reconnection facilities in case the transport layer is cut, whether
accidentally or as part of a change in network.
5.2. Message part handling
LEMONADE Compliant IMAP servers MUST support the BINARY [RFC3516]
extension. This moves MIME body part decoding operations from the
client to the server. The decoded data is equal or less than the
encoded representation, so this reduces bandwidth effectively.
[RFC3516] allows for servers to refuse to accept uploaded messages
containing binary data, however LEMONADE Compliant IMAP servers SHALL
always accept binary encoded MIME messages in APPEND commands for any
folder.
[I-D.ietf-lemonade-convert] MUST also be supported by servers, which
allows clients to request conversions between media types, and allows
for scaling images, etc. This provides the ability to view
attachments (and sometimes body parts) without the facility to cope
with a wide range of media types, or to efficiently view attachments.
5.3. Compression
The IETF has for some time generally agreed that compression is best
handled at as low a level as possible, therefore Lemonade compliant
IMAP servers SHOULD support the Deflate compression algorithm for
TLS, as defined in [RFC3749].
However, the working group acknowledges that for many endpoints, this
is a rarely deployed technology, as as such, Lemonade compliant IMAP
servers MUST provide [I-D.gulbrandsen-imap-deflate] support for
fallback application-level stream compression, where TLS is not
actively providing compression.
5.4. Out of band notifications
Server to client notifications as discussed in [I-D.ietf-lemonade-
Maes, et al. Expires December 31, 2006 [Page 19]
Internet-Draft LEMONADE profile bis June 2006
notifications]. Server to server notifications discussed in
[I-D.ietf-lemonade-notifications] describes how NF interacts with the
notifications mechanisms.
<<Editor's Note: This is a placeholder section, awaiting
clarification of notifications.>>
5.5. Virtual Mailboxes
Lemonade compliant IMAP servers provide a mechanism for clients to
avoid handling an entire mailbox, instead accessing a view of the
mailbox defined previously. This technique, common in many desktop
clients as a client-side capability, is useful for constrained
clients to minimize the quantity of messages and notification data.
This virtual folder mechanism is defined in [I-D.ietf-lemonade-
vfolder].
<<Editor's Note: Virtual Mailboxes are currently an open issue.>>
5.6. Additional IMAP extensions
Lemonade compliant IMAP servers MUST support the NAMESPACE [RFC2342]
extension. The extension allows clients to discover shared mailboxes
and mailboxes belonging to other users, and provide a normalized
heirarchy view of the mailboxes available.
Lemonade compliant IMAP servers MUST support the LITERAL+ [RFC2088]
extension. The extension allows clients to save a round trip each
time a non-synchronizing literal is sent.
Lemonade compliant IMAP servers MUST support the ESEARCH
[I-D.melnikov-imap-search-ret] extension. The extension allows
clients to efficiently find the first or last messages, find a count
of matching messages, and obtain a list of matching messages in a
considerably more compact representation.
Lemonade compliant IMAP servers MUST support the METADATA [I-D.daboo-
imap-annotatemore] extension. This allows metadata to be stored
against mailboxes, which is a facility used by other extensions
mandated by this profile.
Lemonade compliant IMAP servers MUST support the IDLE [RFC2177]
extension. The extension allows clients to receive unsolicited
notifications about changes in the selected mailbox, without needing
to poll for changes. The responses forming these notifications MUST
be sent in a timely manner when such changes happen.
Maes, et al. Expires December 31, 2006 [Page 20]
Internet-Draft LEMONADE profile bis June 2006
Lemonade Compliant IMAP servers MUST support IMAP over TLS [RFC3501]
as required by [RFC3501]. As noted above in Section 5.3, servers
SHOULD support the deflate compression algorithm for TLS, as
specified in [RFC3749]
6. Summary of the required IMAP and SMTP extensions
+-------------------------+----------------------------------------+
| Name of SMTP extension | Comment |
+-------------------------+----------------------------------------+
| PIPELINING | Section 4.1 |
| DSN | Section 4.2 |
| SIZE | Section 4.3 |
| ENHANCEDSTATUSCODES | Section 4.4 |
| STARTTLS | Section 4.5 |
| BURL | Section 3 |
| URLAUTH support in BURL | Section 3 |
| CHUNKING, BINARYMIME | Section 3.5 |
| 8BITMIME | Required by BURL |
| AUTH | Required by Submission. See [RFC2554] |
+-------------------------+----------------------------------------+
+-----------------------------------+----------------------------+
| Name of IMAP extension or feature | Comment |
+-----------------------------------+----------------------------+
| NAMESPACE | Section 5.6 |
| CONDSTORE | Section 5.1 |
| STARTTLS | Required by IMAP [RFC3501] |
| URLAUTH, CATENATE, UIDPLUS | Section 3 |
| LITERAL+ | Section 5.6 |
| IDLE | Section 5.6 |
| $Forwarded IMAP keyword | Section 3.8 |
| BINARY | Section 5.2 |
| RECONNECT | Section 5.1 |
| ESEARCH | Section 5.6 |
| VFOLDER | Section 5.5 |
| CONVERT | Section 5.2 |
| COMPRESS=DEFLATE | Section 5.3 |
| METADATA | Section 5.6 |
+-----------------------------------+----------------------------+
7. OMA MEM Requirement document
The OMA MEM activity has collected a set of use cases and derived
requirements for a mobile email enabler (MEM). the resulting work is
summarized in OMA MEM Requirement document [MEM-req]. Some
Maes, et al. Expires December 31, 2006 [Page 21]
Internet-Draft LEMONADE profile bis June 2006
requirements relates to email protocols, some involve other OMA
technologies outside the scope of IETF and some relate to
implementations and normative interoperability statements for clients
and servers.
7.1. OMA MEM Architecture
The OMA MEM activity has derived a logical architecture from the
requirements and use cases described in [MEM-req]. The logical
architecture, its elements and interfaces and the notations that it
uses can be found in [MEM-arch].
7.2. OMA MEM Deployment Issues
The OMA MEM Architecture document [MEM-arch] further identifies
deployment models.
Certain of these deployment models are not what IETF has
conventionally modeled. They require special attention to end-to-end
security aspects and may warrant introduction of additional security
measures (e.g. object level encryption).
7.3. OMA MEM proxy
The OMA MEM Architecture document [MEM-arch] identifies OMA MEM
server proxies as server components that may be deployed ahead of
firewalls to facilitate traversal of firewalls.
Both IMAP and SMTP generally are compatible with proxies between the
client and the server. Such proxies may disrupt end-to-end
encryption, with the transport-level encryption ending at the proxy
and re-generating from the proxy to the server. Again this may
require additional security measures like object level encryption.
7.4. IETF LEMONADE Architecture
This section gives a brief introduction to the LEMONADE Architecture.
The IETF LEMONADE activity has derived a profile with the logical
architecture represented in Figure 15, where arrows indicate content
flows.
Maes, et al. Expires December 31, 2006 [Page 22]
Internet-Draft LEMONADE profile bis June 2006
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______
| | | _____
__v__ IMAP | LEMONADE | ESMTP | |
| |<----------->| IMAP |<---------------| MTA |
| MUA |- | Store | |_____|
|_____| \ |__________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____
\ | | _____
\ | LEMONADE | ESMTP | |
---->| Submit |--------------->| MTA |
| Server | |_____|
|__________|
Figure 15: LEMONADE logical architecture
The LEMONADE profile assumes: <<Editor's note: remove redundant
information from the list below.>>
o IMAP protocol [RFC3501] including LEMONADE profile extensions
o Submit protocol ([RFC4409], profile of [RFC2821]) including
LEMONADE profile extensions
o LEMONADE profile compliant IMAP store connected to MTA (Mail
Transfer Agent) via ESMTP [RFC2821].
o LEMONADE profile compliant Submit server connected to MTA via
ESMTP
o Lemonade profile message store / Submit server protocols (URLAUTH)
(see [RFC4467]).
o Outband server to client notifications relying on external
notification mechanisms (and notification protocols) that may be
out of scope of the LEMONADE profile.
o A LEMONADE aware MUA (Mail User Agent). While use of outband
notification is described in the LEMONADE profile, support for the
underlying notifications mechanisms/protocols is out of scope of
the LEMONADE specifications.
Further details on the IETF email protocol stack and architecture can
be found in [I-D.crocker-email-arch]
Note that in Figure 15 the IMAP server and Submit server are
Maes, et al. Expires December 31, 2006 [Page 23]
Internet-Draft LEMONADE profile bis June 2006
represented connected to MTAs (Mail Transfer Agents) via ESMTP
[RFC1861]. This is not really essential. It could as well be X.400
so long as the message in the store is in the internet form.
OMA MEM identifies other functionalities. These are considered as
out of scope of the LEMONADE work and will need to be specified by
OMA MEM.
7.5. LEMONADE profile logical architecture
This section details the LEMONADE profile logical architecture. This
architecture is also expected to support the OMA MEM logical
Architecture.
7.5.1. Relationship between the OMA MEM and LEMONADE logical
architectures
Figure 16 illustrates the mapping of the IETF LEMONADE logical
architecture on the OMA MEM logical architecture.
Maes, et al. Expires December 31, 2006 [Page 24]
Internet-Draft LEMONADE profile bis June 2006
_____________________
| Other_Mob. Enablers |
| |--------------| |
_________| Notification | |
| | | Mechanism | |
| | |______________| |
|Notif. |____________^________|
|Protocol ______|__________
ME-4 | | ___|_ME-3_ |
___|____ | | | | _____
| __v__ | IMAP | | LEMONADE | | ESMTP | |
|| |<----------->| IMAP |<-----------| MTA |
|| MUA || ME-2a | | Store | | |_____|
||_____||\ME-1 | |__________| |
| MEM | \ | | |
| Client| \ | |URLAUTH |
|_______| \SUBMIT | |
\ | ____v_____ |
\ | | | | _____
\ | | LEMONADE | | ESMTP | |
---->| Submit |----------->| MTA |
ME-2b | | Server | | |_____|
| |__________| |
|MEM Email |
|Server Server|
|_________________|
^
|ME-5
|
Figure 16: Mapping of LEMONADE profile logical architecture onto the
OMA MEM logical architecture.
As described in Section 7.4, the LEMONADE profile assumes LEMONADE
profile compliant IMAP stores and Submit servers. Because the
LEMONADE profile extends the IMAP store and the submit server, the
mobile enablement of email provided by the LEMONADE profile is
directly provided in these server. Mapped to OMA MEM logical
architecture, for the case considered and specified by the LEMONADE
profile, the MEM server and email server logically combined. They
are however split into distinct LEMONADE message store and LEMONADE
submit server. The OMA MEM interfaces ME-2 ([MEM-arch]) consists of
two interfaces ME-2a and ME-2b associated respectively to IMAP
extended according to the LEMONADE profile and SUBMIT extended
according to the LEMONADE profile.
The MUA is part of the MEM client.
Maes, et al. Expires December 31, 2006 [Page 25]
Internet-Draft LEMONADE profile bis June 2006
External notifications mechanism can be part of the other OMA enabler
specified by OMA (or other activities).
7.5.2. LEMONADE realization of OMA MEM with non-LEMONADE compliant
servers
The OMA MEM activity is not limited to enabling Lemonade compliant
servers. It explicitly identifies the need to support other
backends.
7.5.2.1. LEMONADE realization of OMA MEM with non-LEMONADE enhanced
IMAP servers
Figure 17 illustrates the case of IMAP servers that are not (yet)
LEMONADE compliant / enhanced with LEMONADE. In such case, the I2
interface between the MEM server components and the IMAP store and
submit server are IMAP and SUBMIT.
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______ _____________
| | LEMONADE | | | _____
__v__ IMAP | MEM | IMAP |NON-LEMONADE | ESMTP | |
| |<--------->|Enabler |<------>|IMAP |<----->| MTA |
| MUA |\ ME-2a | Server | |Store | |_____|
|_____| \ |__________| |_____________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____ _____________
\ | | | | _____
\ | LEMONADE | SUBMIT |NON-LEMONADE | ESMTP | |
-->| MEM | |Submit | | |
| Enabler |------->|Server |------>| MTA |
ME-2b | Server | | | |_____|
|__________| |_____________|
Figure 17: Architecture to support non-LEMONADE enhanced IMAP
servers with a LEMONADE realization of OMA MEM enabler.
In Figure 17, the server may be a separate proxy.
Maes, et al. Expires December 31, 2006 [Page 26]
Internet-Draft LEMONADE profile bis June 2006
7.5.2.2. LEMONADE realization of OMA MEM with non-IMAP servers
<<Editor's note: This section and the previous section and figures
may be combined in a future release of this draft.>
Figure 18 illustrates the cases where the message store and submit
servers are not IMAP store or submit servers. They may be POP3
servers or other proprietary message stores.
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______ _____________
| | LEMONADE | | | _____
__v__ IMAP | MEM | I2 |Proprietary | ESMTP | |
| |<--------->|Enabler |<------>|Message |<----->| MTA |
| MUA |\ ME-2a | Server | |Store | |_____|
|_____| \ |__________| |_____________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____ _____________
\ | | | | _____
\ | LEMONADE | I2 |Proprietary | ESMTP | |
-->| MEM | |Submit | | |
| Enabler |------->|Server |------>| MTA |
ME-2b | Server | | | |_____|
|__________| |_____________|
Figure 18: Architecture to support non-IMAP servers with a LEMONADE
realization of OMA MEM enabler.
I2 designates proprietary adapters to the backends. They may
involved functions performed in the message stores or submit server
as well as in the MEM enabler server.
In Figure 18, the server may be a separate proxy.
7.6. Filters and server to client notifications and LEMONADE
OMA MEM RD [MEM-req] and AD [MEM-arch] emphasize the need to provide
mechanisms for server to client notifications of email events and
filtering. Figure 19 illustrates how notification and filterings are
Maes, et al. Expires December 31, 2006 [Page 27]
Internet-Draft LEMONADE profile bis June 2006
introduced in LEMONADE profile.
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol -------\ _|_
| ______| ___\>|NF|____
| | | ---- | _____
__v__| IMAP |__ LEMONADE |___ ESMTP __| |
| |<-------->|VF| IMAP |DF |<--------|AF| MTA |
| MUA |\ ME-2a |-- Store |--- --|_____|
|_____| \ |_____________| ^
\_\_______________|_______|
\ |URLAUTH
\SUBMIT |
\ ____v_____
\ | | _____
\ | LEMONADE | ESMTP | |
---->| Submit |--------------->| MTA |
ME-2b | Server | |_____|
|__________|
Figure 19: Filtering mechanism defined in LEMONADE architecture
In Figure 19, four categories of filters are defined:
o AF: Administrative Filters - Set up by email service provider. AF
are typically not configured by the user and set to apply policies
content filtering, virus protection, spam filtering etc...
o DF: Deposit Filters - Filters that are executed on deposit of new
email messages. They can be defined as SIEVE filters [SIEVE].
They can include vacation notices.
o VF: View Filters - Filters that define which emails are visible to
the MUA. View filters can be defined as virtual folders
[I-D.ietf-lemonade-vfolder] as described in [I-D.ietf-lemonade-
vfolder] and [I-D.ietf-lemonade-notifications].
o NF: Notification Filters - Filters that define for what email
server event an outband notification is sent to the client.
The filters are manageable from the MUA:
o NF and DF: via SIEVE Management protocol [I-D.martin-managesieve]
Maes, et al. Expires December 31, 2006 [Page 28]
Internet-Draft LEMONADE profile bis June 2006
o VF: via virtual folder mechanisms as discussed in [I-D.ietf-
lemonade-vfolder] and [I-D.ietf-lemonade-notifications]
7.7. LEMONADE Profile features
<<Editor's note: This section will be empty before publication, other
sections would contain detailed description of features listed in
this section.>>
The LEMONADE Profile provides normative support for the technical
features identified within scope of IETF LEMONADE work in the OMA MEM
realization internet draft.
The following is a list of features that will be normatively
described: <<Editor's note: The features are currently introduced by
reference to documents that are work in progress and may still be
individual drafts. They are expected to become WG drafts and RFCs.
References will be updated and text provided to explain the normative
usage in LEMONADE profile.>>
o LEMONADE profile features, evolved to include capabilities to edit
on MUA and send differences to server even for address fields.
o Server to client notifications as discussed in [I-D.ietf-lemonade-
notifications]. Server to server notifications discussed in
[I-D.ietf-lemonade-notifications] describes how NF interacts with
the notifications mechanisms.
o Filters as discussed in [I-D.ietf-lemonade-notifications],
[I-D.ietf-lemonade-vfolder], [I-D.ietf-lemonade-search-within],
[SIEVE] and [I-D.ietf-lemonade-imap-sieve]. Events that can be
bound to notifications are described in [I-D.ietf-lemonade-
msgevent]. Filter remote management are discussed in [I-D.ietf-
lemonade-notifications] and [I-D.ietf-lemonade-vfolder]. For NF,
it MAY rely on [I-D.martin-managesieve]
o Virtual folders as discussed in [I-D.ietf-lemonade-vfolder]
o Media conversion as discussed in [I-D.ietf-lemonade-convert].
Streamed media conversion is still under consideration.
o Quick reconnect as discussed in [I-D.ietf-lemonade-reconnect]
o Compression as discussed in [I-D.gulbrandsen-imap-deflate].
o Intermediaries as discussed in [I-D.smaes-lemonade-intermediary-
challenges]. Best practices are discussed in [I-D.ietf-lemonade-
deployments]. Lemonade protocols MAY also follow [I-D.maes-
lemonade-tcp-challenged-environments]
o Proxies and other intermediaries that provide protocol support
disrupt conventional IETF security models and require object level
encryption as discussed in [I-D.ietf-lemonade-convert].
[I-D.ietf-lemonade-notifications] further discusses the use for
notification encryption.
Maes, et al. Expires December 31, 2006 [Page 29]
Internet-Draft LEMONADE profile bis June 2006
o Message recall within SUBMIT domain based on [RFC3888].
8. Security Considerations
Security considerations on Lemonade "forward without download" are
discussed throughout Section 3. Additional security considerations
can be found in [RFC3501] and other documents describing other SMTP
and IMAP extensions comprising the Lemonade Profile.
Note that the mandatory-to-implement authentication mechanism for
SMTP submission is described in [RFC4409]. 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 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, an
extension that requires sending a URLAUTH token to the mail
submission server, such a token should be protected from interception
to avoid a replay attack that may disclose the contents of the
message to an attacker. TLS based encryption of 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 which
references non-public information, there is a user expectation that
the entire message content will be treated confidentially. To meet
Maes, et al. Expires December 31, 2006 [Page 30]
Internet-Draft LEMONADE profile bis June 2006
this expectation, the message submission server should use STARTTLS
or a mechanism providing equivalent data confidentiality when
fetching the content referenced by that URL.
8.3. Additional extensions and deployment models
This specification provides no additional security measures beyond
those in the referenced Internet Mail and LEMONADE documents.
We note however the security risks associated to:
o Outband notifications
o Server configuration by client
o Client configuration by server
o Presence of proxy servers
o Presence of servers as intermediaries
o In general the deployment models considered by OMA MEM that are
not conventional IETF deployment models.
o Measures to address the need to traverse firewalls and mobile
network intermediaries.
9. IANA considerations
This document doesn't require any IANA registration or action that
are not covered by the different drafts and RFCs included in the
realization described in this document.
We note the reserved mailbox / folder names in [I-D.ietf-lemonade-
vfolder].
10. Future work
o The different drafts and RFCs referenced in this document must be
completed and separated into normative and informative references.
o Text will be updated as described in editor's notes
11. Version history
o Version 02:
* Update of references and how they are displayed in the text
(Comments from Randy Gellens)
* Update of list of extensions to support as MUST by the Lemonade
Profile Bis
* Update of options for compression via placeholder imap-
compression section describing compression requirements
Maes, et al. Expires December 31, 2006 [Page 31]
Internet-Draft LEMONADE profile bis June 2006
* Update of support of TCP chalenged environments
* Update of support of object level encryption
* Clarified the use of $Forwarded in the examples, and
demonstrated how to remove the \Draft flag from the sent
message
* Clarified $Forwarded
* Added RECONNECT to imap-condstore section
* Add new section imap-bodypart, "Message part handling",
describing BINARY and CONVERT requirements
* Added placeholder section for notifications
* Added various extensions to imap-other section, and added
clarifying comments to IDLE, NAMESPACE, and a further
references to TLS DEFLATE compression
* Added extension names to IMAP table
* Fixed all issues found with original Lemonade profile so far.
o Version 01:
* LEMONADE profile has been introduced in-line, with some updates
/ corrections.
* Subsequent re-organization of the text
* Details of extensions proper to Lemonade Profile-bis have been
updated to refer to the drafts newly accepted as WG IETF
drafts.
* Addition of appendix on attachements streaming.
o Version 00:
* It evolved from a combination of the content of LEMONADE
profile and the OMA MEM realization internet draft.
12. Acknowledgements
The editors acknowledge and appreciate the work and comments of the
IETF LEMONADE working group and the OMA MEM working group.
In particular, the editors would like to thank Eric Burger, Randall
Gellens, Zoltan Ordogh, Greg Vaudreuil, and Fan Xiaohui for their
comments and reviews.
Appendix A. Streaming attachments
<<Editor's note: This section is introduced as a reminder that a
draft is due on this topic. It is expected to be moved to that
draft. Otherwise, it may be expanded and remain in this document
(possibly as a main section) when well enough documented.>>
<<Editor's note: Support for this capability is expected to remain
optional.>>
Maes, et al. Expires December 31, 2006 [Page 32]
Internet-Draft LEMONADE profile bis June 2006
+----------+ +--------+ +---------+
| LEMONADE | (2) | Media | (3) | Media |
| IMAP |<-------->| Server |<----->|Converter|
| Store | | | | |
+----------+ +--------+ +---------+
^ ^
| |
|(1) |
| |(4)
| |
+----V---+ |
| | |
| Client <-----------------|
| |
+--------+
Figure 20: LEMONADE architecture to support streaming and conversion
of attachments
In Figure 20:
o (1) Designates:
* (a) The request (to be defined by Lemonade) for content
streaming (possibly with conversion) sent by the client to the
IMAP store.
* (b) The response from the IMAP store (if any).
o (2) Designates:
* A yet to be defined rest to initiate streaming of converted
content to the client.
* The response
o (3) Designates :
* (a) A yet to be defined request by the media server to convert
content as requested by the client. This could be based on OMA
STI. <<Editor's note: Reference will be added later.>>
* (b) The response
o (4) Designates:
* (a) The signaling between the Media Server and the client to
initiate and control streaming of the media
* (b) The actual media streaming
o This could involve SIP, RTP, RTSP, ... <<Editor's note: References
will be added later after details are agreed upon.>>
o <<Editor's note: Open issue: Could IMAP store issue the signalling
(e.g. SIP third party call control) or does it have to be solely
between client and media server>>
13. References
Maes, et al. Expires December 31, 2006 [Page 33]
Internet-Draft LEMONADE profile bis June 2006
13.1. Normative References
[I-D.crocker-email-arch]
Crocker, D., "Internet Mail Architecture",
draft-crocker-email-arch-04 (work in progress),
March 2005.
[I-D.daboo-imap-annotatemore]
Daboo, C., "IMAP METADATA Extension",
draft-daboo-imap-annotatemore-09 (work in progress),
March 2006.
[I-D.gulbrandsen-imap-deflate]
Gulbrandsen, A., "The IMAP COMPRESS=DEFLATE extension",
draft-gulbrandsen-imap-deflate-02 (work in progress),
March 2006.
[I-D.ietf-lemonade-convert]
Maes, S. and R. Cromwell, "CONVERT",
draft-ietf-lemonade-convert-04 (work in progress),
June 2006.
[I-D.ietf-lemonade-imap-sieve]
Leiba, B., "Support for Sieve in Internet Message Access
Protocol (IMAP4)", draft-ietf-lemonade-imap-sieve-01 (work
in progress), March 2006.
[I-D.ietf-lemonade-msgevent]
Newman, C., "Internet Message Store Events",
draft-ietf-lemonade-msgevent-00 (work in progress),
June 2006.
[I-D.ietf-lemonade-notifications]
Cromwell, R. and S. Maes, "Lemonade notifications and
filters", draft-ietf-lemonade-notifications-03 (work in
progress), June 2006.
[I-D.ietf-lemonade-reconnect]
Wilson, C. and A. Melnikov, "IMAP4 Extensions for Quick
Reconnect", draft-ietf-lemonade-reconnect-07 (work in
progress), June 2006.
[I-D.ietf-lemonade-search-within]
Maes, S. and R. Cromwell, "WITHIN Search extension to the
IMAP Protocol", draft-ietf-lemonade-search-within-02 (work
in progress), June 2006.
[I-D.ietf-lemonade-vfolder]
Maes, et al. Expires December 31, 2006 [Page 34]
Internet-Draft LEMONADE profile bis June 2006
Maes, S., "Persistent Virtual Folder extension to the IMAP
Protocol", draft-ietf-lemonade-vfolder-01 (work in
progress), May 2006.
[I-D.martin-managesieve]
Martin, T. and A. Melnikov, "A Protocol for Remotely
Managing Sieve Scripts", draft-martin-managesieve-06 (work
in progress), February 2006.
[I-D.melnikov-imap-search-ret]
Melnikov, A. and D. Cridland, "IMAP4 extension to SEARCH
command for controlling what kind of information is
returned", draft-melnikov-imap-search-ret-03 (work in
progress), June 2006.
[MEM-arch]
Open Mobile Alliance, "Mobile Email Architecture
Document", OMA (Work in Progress),
http://www.openmobilealliance.org/, October 2005.
[MEM-req] Open Mobile Alliance, "Mobile Email Requirements
Document", OMA http://www.openmobilealliance.org/
release_program/docs/RD/
OMA-RD-MobileEmail-V1_0_20051018-C.pdf, Oct 2005.
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994.
[RFC1861] Gwinn, R., "Simple Network Paging Protocol - Version 3
-Two-Way Enhanced", RFC 1861, October 1995.
[RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10, RFC 1870,
November 1995.
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
Error Codes", RFC 2034, October 1996.
[RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[RFC2197] Freed, N., "SMTP Service Extension for Command
Maes, et al. Expires December 31, 2006 [Page 35]
Internet-Draft LEMONADE profile bis June 2006
Pipelining", RFC 2197, September 1997.
[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
May 1998.
[RFC2554] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission
of Large and Binary MIME Messages", RFC 3030,
December 2000.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)",
RFC 3461, January 2003.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
April 2003.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
Compression Methods", RFC 3749, May 2004.
[RFC3888] Hansen, T., "Message Tracking Model and Requirements",
RFC 3888, September 2004.
[RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, December 2005.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006.
[RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) -
URLAUTH Extension", RFC 4467, May 2006.
[RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468,
May 2006.
[RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP)
CATENATE Extension", RFC 4469, April 2006.
Maes, et al. Expires December 31, 2006 [Page 36]
Internet-Draft LEMONADE profile bis June 2006
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE Operation or Quick Flag Changes Resynchronization",
RFC 4551, June 2006.
[SIEVE] IETF, "SIEVE WG",
http://www.ietf.org/html.charters/sieve-charter.html.
13.2. Informative References
[I-D.ietf-lemonade-deployments]
Gellens, R., "Deployment Considerations for lemonade-
compliant Mobile Email",
draft-ietf-lemonade-deployments-03 (work in progress),
June 2006.
[I-D.maes-lemonade-tcp-challenged-environments]
Maes, S. and R. Cromwell, "Lemonade in TCP Challenged
Environments",
draft-maes-lemonade-tcp-challenged-environments-01 (work
in progress), June 2006.
[I-D.smaes-lemonade-intermediary-challenges]
Maes, S., "Lemonade and the challenges of Intermediaries",
draft-smaes-lemonade-intermediary-challenges-02 (work in
progress), November 2005.
[RFC4549] Melnikov, A., "Synchronization Operations for Disconnected
IMAP4 Clients", RFC 4549, June 2006.
Maes, et al. Expires December 31, 2006 [Page 37]
Internet-Draft LEMONADE profile bis June 2006
Authors' Addresses
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
Alexey Melnikov (editor)
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
Email: Alexey.Melnikov@isode.com
Dave Cridland (editor)
Inventure Systems Ltd
21, Heol Bronwydd
Caerfyrddin, Cymru SA31 2AJ
GB
Email: dave.cridland@invsys.co.uk
Maes, et al. Expires December 31, 2006 [Page 38]
Internet-Draft LEMONADE profile bis June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Maes, et al. Expires December 31, 2006 [Page 39]
