Lemonade
Internet Draft: Lemonade Command Extensions S. H. Maes
Document: draft-maes-lemonade-command-extensions- R. Lima
00 C. Kuang
R. Cromwell
V. Ha
E. Chiu
Oracle Corporation
Expires: January 2005 July 2004
Lemonade Command Extensions
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
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.
Abstract
The Lemonade Command Extensions defines extensions to the IMAPv4 Rev1
protocol [RFC3501] for optimization in a mobile setting, aimed at
delivering extended functionality for mobile devices with limited
resources. It proposes extensions for message delivery, and
maintaining up-to-date personal information. Bindings to specific
transport are explicitly defined.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
Maes [Page 1]
<Lemonade Command Extensions> July 2004
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].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocol(s) it
implements. An implementation that satisfies all the MUST or REQUIRED
level and all the SHOULD level requirements for a protocol is said to
be "unconditionally compliant" to that protocol; one that satisfies all the MUST level requirements but not all the SHOULD level
requirements is said to be "conditionally compliant." When
describing the general syntax, some definitions are omitted as they
are defined in [RFC3501].
Table of Contents
Status of this Memo...............................................1
Abstract..........................................................1
Conventions used in this document.................................1
Table of Contents.................................................2
1. Introduction...................................................2
1.1. Extra Functionality by Lemonade Command Extensions........3
2. Interactions between the Lemonade Client and Lemonade Server...4
2.1. Revisions to IMAPv4 Rev1 Behavior.........................5
2.1.1. UID..................................................5
2.1.2. Mobile Repository....................................6
2.1.3. The CAPABILITY Command...............................6
2.1.4. Lemonade Session/Login...............................7
2.1.5. LEMONADEENCRYPTED....................................8
2.2. Lemonade Command Extensions Responses.....................8
2.2.1. LEMONADEPROVISION....................................8
2.2.2. LEMONADESETPREF & LEMONADEGETPREFS...................9
2.2.3. LEMONADEFILTER......................................11
2.2.4. LEMONADEZIP.........................................11
2.2.5. LEMONADEDELIVER.....................................12
2.2.6. LEMONADECONVERT & UID LEMONADECONVERT...............13
2.2.7. LEMONADEPSEARCH.....................................14
Security Considerations..........................................15
References.......................................................15
Non-Normative Appendices.........................................16
A. Security Issues for Proxy-Based Implementations of Lemonade16
Authors Addresses................................................17
Intellectual Property Statement..................................18
Full Copyright Statement.........................................19
1. Introduction
Maes Expires - January 2005 [Page 2]
<Lemonade Command Extensions> July 2004
Lemonade Command Extensions protocol is based on IMAPv4 Rev1
[RFC3501], but contains additional enhancements for optimization in a
mobile setting. Thus, the client devices in this document are
assumed to be mobile. The Lemonade Command Extensions take into
account the limited resources of mobile devices, as well as extra
functionality desired.
1.1. Extra Functionality by Lemonade Command Extensions
The Lemonade server supports a rich set of extra functionality over
the IMAP server to support extra features for a mobile client, and
these features are presented:
[1] Compression û Lemonade allows for compression of responses to a
command. Preliminary testing results shows significant performance
results when the response to FETCH FLAGS or header information are
compressed.
[2] Sending emails - The Lemonade server can be used to send email,
thus eliminating the need for the Lemonade client to connect to a
separate SMTP server.
[3] Support for unstable mobile connections û After a client drops
a connection, the Lemonade server can temporarily maintain the
session for the mobile client. During this time, the server caches
any events concerning the mobile repository while the client is
disconnected, which it can then send to the client upon
reconnection.
[4] Longer periods of inactivity tolerated - A Lemonade server
should wait at least 24 hours before logging out an inactive mobile
client and ending its session.
[5] Attachments forward/reply behavior - When forwarding/replying
to a message from the Lemonade client, the end user may choose to
reattach the original's message attachments by just specifying the
UID of the original message. The client need not download the
attachments of the original message itself.
[6] Attachments conversion - The Lemonade server can convert
attachments to other formats to be viewed on a mobile device.
[7] PIM - The protocol also provides support for updating personal
information on a client device, even when these changes are
initiated from another client (i.e. a personal assistant connects
to an end userÆs account from a desktop and changes contact
information.) These additional uses are especially useful for
mobile devices, where end users need up-to-date information on the
fly.
Maes Expires - January 2005 [Page 3]
<Lemonade Command Extensions> July 2004
2. Interactions between the Lemonade Client and Lemonade Server
A Lemonade server must support all IMAPv4 Rev1 commands from client
devices following the syntax defined in [RFC3501]. Thus, a Lemonade
client may issue any existing IMAP commands to the Lemonade server,
and both the server and client must behave as specified in RFC3501
except for the changes specified in Section 2.1. In addition, we
define the following extension commands for IMAPv4 Rev1. Lemonade
Command Extension are tagged and asynchronous following the same
rules as in IMAPv4 Rev1.
The format for presenting commands is defined as follows:
<COMMAND NAME>
<Command Description - contains an explanation of the command>
Formal Syntax: <command syntax described in ABNF [RFC2234]>
Valid States: <states of the P-IMAP session in which this command
can be used>
[Extension to: <states what IMAP command this command should be
used in place of>]
Responses: <server responses for this command>
Result: <possible result that comes after the responses. This
usually indicates the status of the execution of a particular
command. Possible values are:
- OK if the execution was successful
- BAD for unknown commands, or when arguments syntax is
incorrect
- NO when argument semantics are incorrect, or when command
processing fails
- BYE when internal system or network error happens and
processing cannot continue>
Example: <Description of what this example is meant to illustrate>
C: <client issued commands>
S: <server returned results>
This section describes commands where the client initiates contact
with the server, like all the commands in the IMAPv4 Rev1 protocol.
These commands include extensions to the IMAP protocol that have been
created in order to better support mobile devices, and these
extensions are all prefixed with LEMONADE. They are used to perform
Maes Expires - January 2005 [Page 4]
<Lemonade Command Extensions> July 2004
actions on messages: retrieve, delete, search, etc., as well as set
up the filters and notification methods of a mobile client. These
commands are sent over a reliable connection as required for IMAP,
see [RFC3501, Sec. 2.1] for more details. Client devices can send
several commands at one time and, thus, these commands must be
tagged. The server can send tagged and untagged responses to the
client. Untagged responses contain information requested by a
command. Tagged responses give the status of the command execution
and its tag identifies the command it corresponds to.
To connect to a Lemonade server, the client must first follow the
procedure for establishing an IMAP session. The client starts out in
NOT AUTHENTICATED state and issues a LOGIN command with a valid
Lemonade device ID appended to the username. Firing this command
enters the client into a Lemonade session, where it can use all the
Lemonade extension commands, as opposed to a regular IMAP session,
which will return errors to all Lemonade defined extensions other
than LEMONADEZIP, LEOMONADEDELIVER, and LEMONADEPROVISION. To
establish a regular IMAP session, the client may also login in the
usual fashion with their username and password.
The server responds to LEMONADEPROVISION commands by returning any
service specific parameters of the server, such as which outband
channels are supported. The LEMONADEZIP command can be used to zip
the response to another command. LEMONADEDELIVER allows the client
to send an email message through this server, instead of having to
connect with an SMTP server.
Once entered into the Lemonade session, the client can issue
LEMONADEFILTER (see [NOTIFICATIONS]), LEOMONADECONVERT,
LEMONADESETPREF, LEMONADEGETPREFS, and LEMONADEPSEARCH as needed.
LEMONADEFILTER is used to set the view filters and notification
filters. LEMONADECONVERT is used for attachments conversion and
LEMONADEPSEARCH is an enhanced version of SEARCH in IMAPv4 Rev1.
2.1. Revisions to IMAPv4 Rev1 Behavior
The section describes all the differences between how an IMAPv4 Rev1
server vs. a Lemonade server responds to all IMAPv4Rev1 commands for
implementing the custom mobile features. A compliant Lemonade server
must implement all the commands in IMAPv4 Rev1, with these revisions.
The IMAPv4Rev1 syntax on commands and responses are found in sections
6 and 7 in [RFC3501]. The rest of this section defines any
additional modifications to the IMAP commands that a Lemonade server
must implement to be compliant.
2.1.1. UID
Maes Expires - January 2005 [Page 5]
<Lemonade Command Extensions> July 2004
The UID of email messages MUST not change across sessions. Changing
the UID of email messages requires a heavy computational burden on
the mobile client, so the server should avoid doing so.
2.1.2. Mobile Repository
In a Lemonade session, the client can only access messages in the
mobile repository. This affects the messages returned by FETCH, UID
FETCH, etc. Message sequence numbers reflect the relative position
of messages within the given folders of the mobile repository, so the
message sequence number of an email while logged in to Lemonade may
also differ from IMAP. When returning information about the email
account, only messages in the mobile repository are taken into
account.
2.1.3. The CAPABILITY Command
The CAPABILITY command is defined in RFC3501, section 6.1.1. The
client sends a CAPABILITY command so it can query the server to find
out what commands it supports. In RFC3501, the IMAP server is
allowed to specify additional capabilities not included in that
specification. A Lemonade server conforms to that requirement, and
must list what Lemonade commands it supports. Minimally, this must
include LEMONADEZIP, LEMONADEDELIVER, and either IDLE or outband
notification. LEMONADEZIP capability is also returned independently
of the binding.
capability_cmd = tag SP "CAPABILITY"
Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT
Responses: REQUIRED untagged response: CAPABILITY
Result: OK - capability completed
BAD - command unknown or arguments invalid
Example: A Lemonade server that implements all Lemonade commands
described in this document and in [NOTIFICATIONS].
C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LEMONADECONVERT
LEMONADEFILTER LEMONADEPSEARCH LEMONADEZIP LEMONADEDELIVER
LEMONADEPROVISION LEMONADEPREF
S: a001 OK CAPABILITY completed
Example: A minimal Lemonade server over TCP binding.
C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LEMONADEZIP
LEMONADEDELIVER
S: a001 OK CAPABILITY completed
Maes Expires - January 2005 [Page 6]
<Lemonade Command Extensions> July 2004
2.1.4. Lemonade Session/Login
An email userÆs LOGIN name for a Lemonade session is its regular
username + "#" + its Lemonade device ID + optionally, the email
domain. Lemonade device IDs might be "P" + the clientÆs 10 digit
telephone number. To enter a Lemonade session, the client uses a
LOGIN command with this new LOGIN name.
The Lemonade server will automatically try to resume a previous
session for this client. If this is the case, the server informs the
client of the state of the server by sending an untagged SESSION
response. If that state is SELECTED, the server also tells the
client what the selected folder is by sending an untagged FOLDER
response. Next, the server sends the client any pending events that
have occurred in this folder while the client has been disconnected.
Thus, the client can just service these pending events and need not
perform a full sync. If these events could not be cached for some
reason or the server senses the client may have not received some
events, the RESYNC Response is returned, and the client should
perform a state-comparison based sync.
untagged SESSION Response = "*" SP "SESSION" SP ("AUTHENTICATED" /
"SELECTED")
untagged FOLDER Response = "*" SP "FOLDER" SP folder
untagged RESYNC Response = "*" SP "RESYNC"
When there is no active Lemonade session û either because this is the
very first time client logins, or because the client explicitly sent
a LOGOUT command to close a previous session - then the server
returns only the tagged response to the LOGIN command, and the client
needs to perform state-comparison-sync to synchronize its contents.
Example: First login, the client needs to perform a state-
comparison-sync to get in sync.
C: A01 LOGIN joe#P6505551234 password
S: A01 OK LOGIN completed
Example: A successful Lemonade login resuming an old session
C: A02 LOGIN joe#P6505551234@foo.com password
S: * SESSION AUTHENTICATED
S: A02 OK LOGIN completed
Example: A successful Lemonade login resuming an old session in
SELECTED state with the INBOX selected.
C: A02 LOGIN joe#P6505551234 password
S: * SESSION SELECTED
S: * FOLDER INBOX
S: * 14 EXISTS
S: * 49 FETCH (....
Maes Expires - January 2005 [Page 7]
<Lemonade Command Extensions> July 2004
S: A02 OK LOGIN completed
Example: A successful Lemonade login resuming an old session in
SELECTED state with the INBOX selected, but where the server could
not cache all the events since the last disconnect.
C: A02 LOGIN joe#P6505551234 password
S: * SESSION SELECTED
S: * FOLDER INBOX
S: * RESYNC
S: A02 OK LOGIN completed
2.1.5. LEMONADEENCRYPTED
For certain proxy-based implementation of Lemonade (see Security
Considerations and Appendix C), it may be necessary to have only
encrypted responses for retrieving email content. In that case in
place of any untagged FETCH response, the Lemonade server will return
an untagged LEMONADEENCRYPTED response with message content. The
server should return LEMONADEENCRYPTED in response to the CAPABILITY
command if it implements this security mechanism and must announce
the encryption methods specified (see the example following).
untagged LEMONADEENCRYPTED Response = "*" SP "LEMONADEENCRYPTED" SP
encrypted_message_data
Server's response to the CAPABILITY command announcing
LEMONADEENCRYPTED methods.
C: A02 CAPABILITY
S: * CAPABILITY IMAP4rev1 LEMONADEENCRYTPED=3DES,RC40,AES
S: A02 CAPABILITY completed
2.2. Lemonade Command Extensions Responses
The following subsections define Lemonade Command Extension.
2.2.1. LEMONADEPROVISION
The LEMONADEPROVISION command is used to allow a device to obtain
service specific parameters of the server. This includes what
LEMONADEFILTERS (see [NOTIFICATIONS]) are supported, since a server
may not actually be able to support all IMAPv4Rev1 Search criteria.
Also, it will supply a list of all Lemonade preferences and the
values they can be set to. A Lemonade server can return other
parameters as long as its syntax is agreed upon with the Lemonade
client.
Maes Expires - January 2005 [Page 8]
<Lemonade Command Extensions> July 2004
lemonadeprovision_cmd = tag SP "LEMONADEPROVISION" SP device-id
[notif-id]
Valid States: AUTHENTICATED or SELECTED
Responses: REQUIRED untagged responses LEMONADEPROVISION
Result: OK - provision completed
NO - can't provision this device
BAD - command unknown, invalid argument
untagged LEMONADEPROVISION LEMONADEFILTER response = "*" SP
"LEMONADEPROVISION" SP "LEMONADEFILTER" SP "("
filter_criteria_list ")"
untagged LEMONADEPROVISION LEMONADEPREF response = "*" SP
"LEMONADEPROVISION" SP "LEMONADEPREF" SP prev-name SP "("
pref_val_list ")"
Example: The client issues an LEMONADEPROVISION command. The
server
responds by returning the encryption key, modes, and channels
supported by Lemonade. Note the syntax for returning parameters.
C: A002 LEMONADEPROVISION
S: * LEMONADEPROVISION LEMONADEFILTER (AND OR DAYSBEFORETODAY
HEADER FROM TO CC)
S: * LEMONADEPROVISION LEMONADEPREF LEMONADE_OUTBAND_CHANNEL
(SMS NONE)
S: * LEMONADEPROVISION LEMONADEPREF LEMONADE_INBAND_NEW_FORMAT
(NONE)
S: * LEMONADEPROVISION LEMONADEPREF LEMONADE_INBAND_PUSH (ON
OFF)
S: A002 OK LEMONADEPROVISION completed
2.2.2. LEMONADESETPREF & LEMONADEGETPREFS
The LEMONADESETPREF command allows a user to define certain
configuration parameters, while the LEMONADEGETPREFS command allows a
user to retrieve the configuration values. Any server that
implements these commands must respond with LEMONADEPREF as one of
the capabilities in response to a CAPABILITY command. It must also
announce the values these parameters can be set to in the
LEMONADEPROVISION command as specified as follows. These parameters
affect how outband notifications (See [NOTIFICATIONS]) are sent to
the client, as well as the format for sending new event notifications
(See [NOTIFICATIONS]). If the server supports LEMONADEPREF they are
required to support all of the following preferences with at least
one value to set each preference to. They are listed following and
their names start with LEMONADE to identify them as LEMONADE
parameters:
Maes Expires - January 2005 [Page 9]
<Lemonade Command Extensions> July 2004
[1] LEMONADE_OUTBAND_ADDRESS - the number or email address to send
SMS/JMS notification messages to the client. This must be a valid
number or email according to the outband channel requirements.
This will not be returned in the LEMONADEPROVISION command.
[2] LEMONADE_OUTBAND_CHANNEL - the channel to send outband
notifications, either SMS, JMS, WAP_PUSH, MMS, or NONE. When NONE,
the LEMONADE server does not send the client any outband
notifications. The list of values may be extended when different
outband channels are available. The valid values for this
preference that the server supports will be given in response to
the LEMONADEPROVISION command.
[3] LEMONADE_INBAND_NEW_FORMAT - the FETCH parameters to
automatically send to the client when there is a new message and
there is a valid Lemonade session, or NONE. If NONE, the server
sends the client a traditional EXISTS message when a new message
arrives in the folder. Otherwise, in place of the EXISTS message,
the server sends an untagged FETCH response with the given
information. The valid values for this preference that the server
supports will be given in response to the LEMONADEPROVISION
command.
[4] LEMONADE_INBAND_PUSH - whether or not the server should
automatically IDLE the server when a folder is selected. The valid
values for this preference that the server supports will be given
in response to the LEMONADEPROVISION command.
lemonadegetpref_cmd =tag SP "LEMONADEGETPREFS" SP "("
lemonade_pref_list ")"
lemonade_pref_list = lemonade_pref [SP lemonade_pref_list]
lemonade_pref = (LEMONADE_OUTBAND_ADDRESS /
LEMONADE_OUTBAND_CHANNEL / LEMONADE_INBAND_NEW_FORMAT /
LEMONADE_INBAND_PUSH)
Valid States: AUTHENTICATED or SELECTED
Responses: REQUIRED untagged LEMONADEGETPREFS response with the
value of the requested parameter.
untagged LEMONADEGETPREFS response - "*" LEMONADEGETPREFS pref-
pair
pref-pair = "(" lemonade-pref SP lemonade-pref-val [pref-pair] ")"
Result: OK - command completed
NO - command failure: can't alter preference
BAD - command unknown or arguments invalid
Example: The client wishes to know the current outband notification
method it has set up. It sends an LEMONADEGETPREFS command.
C: A003 LEMONADEGETPREFS (LEMONADE_OUTBAND_CHANNEL)
S: * LEMONADEGETPREFS (LEMONADE_OUTBAND_CHANNEL SMS)
S: A003 0K LEMONADEGETPREFS completed
Maes Expires - January 2005 [Page 10]
<Lemonade Command Extensions> July 2004
lemonadesetpref_cmd = tag SP "LEMONADESETPREF" SP
(("LEMONADE_OUTBAND_ADDRESS" SP device_address) /
("LEMONADE_OUTBAND_CHANNEL" SP ("SMS"/"JMS"/"WAP_PUSH"/
"MMS"/"NONE")) /
("LEMONADE_INBAND_NEW_FORMAT" SP fetch_criteria) /
("LEMONADE_INBAND_PUSH" SP ("ON" / "OFF"))
Valid States: AUTHENTICATED or SELECTED
Responses: No specific responses.
Result: OK - command completed
NO - command failure: can't get a preference
BAD - command unknown or arguments invalid
Example: The client sets up its SMS device address and then selects
that it wants SMS messages sent to the device.
C: A002 LEMONADESETPREF LEMONADE_OUTBAND_ADDRESS 13335559999
S: A002 OK LEMONADESETPREF completed
C: A003 LEMONADESETPREF LEMONADE_OUTBAND_CHANNEL SMS
S: A003 OK LEMONADESETPREF completed
Example: The client sets the inband NEW format to be ALL, meaning it
wants the server to automatically send it all the headers for any new
message.
C: A002 LEMONADESETPREF LEMONADE_INBAND_NEW_FORMAT ALL
S: A002 OK LEMONADESETPREF LEMONADE_INBAND_NEW_FORMAT completed
From now on, whenever a new message arrives in a folder during a
valid Lemonade session, the server will try to send an untagged FETCH
response of the new message with the specified information to the
client at the earliest opportunity. This untagged FETCH response
replaces the untagged EXISTS response that IMAP sends regarding a new
message.
S: * 60 FETCH ...<headers>
2.2.3. LEMONADEFILTER
See [NOTIFICATIONS].
2.2.4. LEMONADEZIP
The LEMONADEZIP command is used for zipping the response of a command
and can be used while the server is in any state. The LEMONADEZIP
command takes in a complete second command (including a tag for that
command). In an untagged response to LEMONADEZIP, the server gives
the number of bytes in the zipped response to the second command, as
well as the response to that command in g-zip format.
Maes Expires - January 2005 [Page 11]
<Lemonade Command Extensions> July 2004
LEMONADEZIP is optional when HTTP/HTTPS binding is used as specified
in [NOTIFICATIONS], as the Lemonade server may rely on the HTTP/HTTPS
compression mechanism. For the other bindings LEMONADEZIP is
mandatory.
lemonadezip_cmd = tag SP "LEMONADEZIP" SP command
Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT
Responses: "{" num "}" zipped-response-to-command
Result: OK - the command given was g-zipped correctly and sent
BAD - invalid arguments, i.e. command given is in the wrong
format.
Example: Zipping the response to a FETCH command.
C: A001 LEMONADEZIP A002 FETCH 1:* ALL
S: * {10933843723} ...[zipped response to FETCH command]... CRLF
S: A001 OK LEMONADEZIP completed
When the client unzips the body of the response to the FETCH command
it gets:
* 1 FETCH ...
...
A002 OK FETCH completed
2.2.5. LEMONADEDELIVER
The LEMONADEDELIVER command can be used for creating new messages, or
replying to/forwarding an existing message. The first argument after
the command name indicates whether this is a new message "N", a reply
"R" or a forward "F" of an existing message. When replying/forwarding
a message, the client must specify the UID of the message being
replied to or forwarded and whether or not to include the attachments
of the original message in the reply/forward, by indicating either
"Y" or "N" after the UID parameter. The text of the message being
replied to/forwarded is automatically appended to the end of the new
message regardless. If the user wishes to save a copy of this
message to some folder, it can specify that next by using "SAVETO"
followed by the name of the folder. If and only if SAVETO is
specified, the server will return an APPENDUID response code with the
UID validity and then the UID of that saved message in that folder.
If the message cannot be saved to the server, an okay response will
still be returned, but without a UID. The last argument of the
LEMONADEDELIVER command is a number in braces that denotes the number
of bytes in the Internet message (conforming to RFC 2822) that is to
follow. A "+" before the closing braces means the client will send a
CRLF and then the Internet message immediately, without waiting for a
continuance response from the server. The server continues to wait
until it receives the number of bytes specified, and then waits for
an additional CRLF. If more bytes were input before this additional
CRLF than was specified, the server returns an error. Thus, the
client should input exactly the number of bytes specified for the
Maes Expires - January 2005 [Page 12]
<Lemonade Command Extensions> July 2004
Internet Address, and then one final CRLF to terminate the
LEMONADEDELIVER.
lemonadedeliver_cmd =tag SP "LEMONADEDELIVER" SP
("N" / ("R"/"F") SP folder SP uid SP ("Y" / "N"))
[SP "SAVETO=" folder]
SP "{" number ["+"] "}"
internet_msg
Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT
Responses: no specific responses
Result: OK - mail delivered successfully by the SMTP server,
LEMONADEDELIVERUID response code included if the SAVETO is included
in the command.
BAD - invalid arguments, for example missing parameter.
NO - when the envelope information is invalid
Example: new message
C: A001 LEMONADEDELIVER N SAVETO=~/Sent {299}
Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
From: Fred Foobar <foobar@Blurdybloop.COM>
Subject: afternoon meeting
To: mooch@owatagu.siam.edu
Message-Id: <B27397-0100000@Blurdybloop.COM> MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
<a blank line>
Hello Joe, do you think we can meet at 3:30 tomorrow?
<a blank line>
A new message is prepared and sent.
S: A001 OK LEMONADEDELIVER [APPENDUID 1 140] completed
Example: reply message
C: A001 LEMONADEDELIVER R Inbox 203 Y {299}
Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
From: Fred Foobar <foobar@Blurdybloop.COM>
Subject: afternoon meeting
To: mooch@owatagu.siam.edu
Message-Id: <B27397-0100000@Blurdybloop.COM> MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
<a blank line>
Hello Joe, do you think we can meet at 3:30 tomorrow?
<a blank line>
A reply message for message 203 is prepared and includes all
original attachments.
S: A001 OK LEMONADEDELIVER completed
2.2.6. LEMONADECONVERT & UID LEMONADECONVERT
LEMONADECONVERT and LEMONADEUIDCONVERT is used for attachments
conversion. In this case, the client sends one message sequence
Maes Expires - January 2005 [Page 13]
<Lemonade Command Extensions> July 2004
number or UID, a body part number, and gives the mime-type and
subtype to convert the attachment to.
lemonadeconvert_cmd = tag SP "LEMONADECONVERT" message-sequence-
number SP part-id
SP "as" SP mime-type "/" subtype
Valid States: SELECTED
Responses: untagged responses: LEMONADECONVERT
Untagged lemonadeconvert response = "*" SP message-sequence-number SP
"LEMONADECONVERT" SP document_in_converted_format
Result: OK - lemonadeconvert completed
NO - lemonadeconvert error: can't perform the command
BAD - command unknown or arguments invalid
Example: The client fetches an attachment in the message with the
message sequence number of 120 in the Inbox and asks to have that
attachment converted to pdf format.
C: a001 LEMONADECONVERT 120 BODY[3] as application/pdf
S: * 2 LEMONADECONVERT <this part of a document in pdf format.>
S: a001 OK LEMONADECONVERT COMPLETED
lemonadeuidconvert_cmd =tag SP "UID" SP "LEMONADECONVERT" uid SP
part-id SP "as" SP mime-type "/" subtype
Valid States: SELECTED
Responses: untagged responses: LEMONADECONVERT
Result: OK - lemonadeuidconvert completed
NO - lemonadeuidconvert error: can't perform the command
BAD - command unknown or arguments invalid
Example: The client fetches an attachment in the message with UID
120 (and message sequence number 2) in the Inbox and asks to have
that attachment converted to pdf format.
C: a001 UID LEMONADECONVERT 120 BODY[3] as application/pdf
S: * 2 LEMONADECONVERT <this part of a document in pdf format.>
S: a001 OK UID LEMONADECONVERT COMPLETED
2.2.7. LEMONADEPSEARCH
The LEMONADEPSEARCH command and response syntax follows the same
rules as the ones defined for the SEARCH command in RFC3501, Sec.
6.4.4 and 7.2.5 respectively. The LEMONADEPSEARCH command extension
allows the search to be made persistent on the server and to appear
as a virtual folder. Following the successful execution of an
LEMONADEPSEARCH command, a new folder appears when using the LIST
command under the root folder with the specific folder name
requested. This new folder needs to be created on the client device.
Clients operating on this folder see a view of the underlying folder
with only messages matching the search criteria displayed. Operations
on messages in this folder do not affect that message.
Maes Expires - January 2005 [Page 14]
<Lemonade Command Extensions> July 2004
lemonadepsearch_cmd = tag SP "LEMONADEPSEARCH" [SP "CHARSET" SP
astring] 1*(SP
search-key)
Valid States: SELECTED
Extension to: UID SEARCH command [RFC 3501, Sec. 6.4.4]
Responses: no specific responses
Result: OK û lemonadepsearch created
NO - can't create the folder or incorrect query
BAD - invalid arguments
Example: create a persistent search for all messages from "John"
since Jun, 1st 2003. The newly created folder name is called
"from_john"
C: A001 LEMONADEPSEARCH from_john FLAGGED SINCE 1-Jun-2003 FROM
"John"
S: A001 OK LEMONADEPSEARCH completed
Security Considerations
The protocol calls for the same security requirements for an in-
response and inband connectivity mode as IMAP.
For the outband connectivity mode, servers should use encryption
methods for notifications if sensitive information is included in the
payload of that notification.
When an implementation of Lemonade is proxy-based, this may create
new security issues. These issues are discussed in detail in
Appendix A, because the issues are dependent on the implementation of
this protocol rather than inherent to the protocol itself.
References
[OMA-EN] Open Mobile Alliance Email Notification Version 1.0, August
2002. http://www.openmobilealliance.org/tech/docs/EmailNot/OMA-
Push-EMN-V1_0-20020830-C.pdf
[IMAP-DISC] Austein, R. "Synchronization Operations For Disconnected
Imap4 Clients", IMAP-DISC, November 1994.
http://asg.web.cmu.edu/cyrus/rfc/draft-ietf-imap-disc-01.html
[RFC2119] Brader, S. "Keywords for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
http://www.ietf.org/rfc/rfc2119
Maes Expires - January 2005 [Page 15]
<Lemonade Command Extensions> July 2004
[RFC2180] Gahrns, M. "IMAP4 Multi-Accessed Mailbox Practice", RFC
2180, July 1997.
http://www.ietf.org/rfc/rfc2180
[RFC2234] Crocker, D. and Overell, P. "Augmented BNF for Syntax
Specifications", RFC 2234, Nov 1997.
http://www.ietf.org/rfc/rfc2234
[RFC2420] Kummert, H. "The PPP Triple-DES Encryption Protocol
(3DESE)", RFC 2420, September 1998.
http://www.ietf.org/rfc/rfc2420
[RFC2616] Fielding, R. et al. "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
http://www.ietf.org/rfc/rfc2616
[RFC2617] Franks, J. et al. "HTTP Authentication: Basic and Digest
Access Authentication", RFC 2617, June 1999.
http://www.ietf.org/rfc/rfc2617
[RFC2683] Leiba, B. "IMAP4 Implementation Recommendations", RFC 2683
Sep 1999.
http://www.ietf.org/rfc/rfc2683
[RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997.
http://www.ietf.org/rfc/rfc2177
[RFC2818] Rescorla, E. "HTTP over TLS", RFC 2818, May 2000.
http://www.ietf.org/rfc/rfc2818
[RFC2822] Resnick, P. "Internet Message Format", RFC 2822, April
2001. http://www.ietf.org/rfc/rfc2822
[RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
Version 4 rev1", RFC 3501, March 2003.
http://www.ietf.org/rfc/rfc3501
[NOTIFICATIONS] Maes, S.H. and Wilson C., "Lemonade Server to Client
Notifications", draft-ietf-lemonade-server-to-client-
notifications-00.txt, (work in progress), July 2004.
Non-Normative Appendices
A. Security Issues for Proxy-Based Implementations of Lemonade
In some implementations of Lemonade, the client may connect to a
proxy that sits in an operator network, but the backend email storage
Maes Expires - January 2005 [Page 16]
<Lemonade Command Extensions> July 2004
server sits in a separate enterprise network. The enterprise network
is assumed to be secure, but the operator network may not be trusted.
If unencrypted information lies in the operator network, that
information is vulnerable to attacks.
If the Lemonade extensions are all implemented in the enterprise
network, then the proxy on the carrier should be an encrypted SSL
pass-through proxy. The proxy is unaware of the encryption keys and
thus cannot encrypt any data. Without the encryption key, this proxy
cannot see any of the information sent from the client, nor can it
send any bogus commands to the backend enterprise email server to
corrupt the user's mailbox. The additional cost for this design is
that the backend enterprise email server and the client devices must
have additional processing to handle this encryption.
If the Lemonade server is implemented as a backend IMAP server with
additional command processing done on the proxy, there are more
complex security issues. This proxy must be able to send commands to
the backend server to accomplish its tasks, as well as read
information coming from the backend server. An attacker thus can
send commands to the backend to change the state of the mail storage,
possibly corrupting it. In addition, it can read responses from the
mail server that might contain confidential email information. This
proxy may also send bogus responses back to the client. Clearly,
this setup is not an ideal issue and many complications that make
this problem complex to solve. The suggestion recommended is to
remedy the problem of unencrypted, untagged FETCH responses that may
contain confidential information. Untagged LEMONADEENCRYPTED
responses (see Section 2.1.5) should be used in place of any untagged
FETCH responses, which contain encrypted message information to be
passed through the lemonade proxy on the operator network. The key
exchange for encryption should not occur through the proxy. It has
to be done through another channel: manually entered by user (e.g.
password), or via an HTTP SSL request to the enterprise server. Any
other additional server responses containing sensitive information
(passwords, etc.) should be LEMONADEENCRYPTED. The server should
implement 3DES encryption and use the client's password as the key.
Authors Addresses
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
Maes Expires - January 2005 [Page 17]
<Lemonade Command Extensions> July 2004
Rodrigo Lima
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Chang Kuang
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Ray Cromwell
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Vida Ha
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Eugene Chiu
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
Maes Expires - January 2005 [Page 18]
<Lemonade Command Extensions> July 2004
this standard. Please address the information to the IETF Executive
Director.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Full Copyright Statement
Copyright (C) The Internet Society 2003. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Maes Expires - January 2005 [Page 19]