to be sent (see [BURL] for details of the semantics and steps).
Note that the second EHLO command is required after a successful
STARTTLS command. The third EHLO command is required if and only
if the second EHLO response doesn’t list any BURL options. See
Section 2.4.1 for an example of submission where the third EHLO
command/response is not present.
S: 220 owlry.example.org ESMTP
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5
S: 250-DSN
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES
M: STARTTLS
S: 220 Ready to start TLS
...TLS negotiation, subsequent data is encrypted...
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
S: 235 2.7.0 PLAIN authentication successful.
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap imap://imap.example.org
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: MAIL FROM:<bob.ar@example.org> BODY=BINARY
S: 250 2.5.0 Address Ok.
M: RCPT TO:<foo@example.net>
S: 250 2.1.5 foo@example.net OK.
M: BDAT 475
M: Message-ID: <419399E1.6000505@caernarfon.example.org>
M: Date: Thu, 12 Nov 2004 16:57:05 +0000
M: From: Bob Ar <bar@example.org>
M: MIME-Version: 1.0
M: To: foo@example.net
M: Subject: About our holiday trip
M: Content-Type: multipart/mixed;
M: boundary="------------030308070208000400050907"
M:
M: --------------030308070208000400050907
M: Content-Type: text/plain; format=flowed
M:
M: Our travel agent has sent the updated schedule.
M:
M: Cheers,
M: Bob
M: --------------030308070208000400050907
S: 250 2.5.0 OK
M: BURL imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF
S: 250 2.5.0 OK
M: BURL imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9
S: 250 2.5.0 OK
M: BDAT 44 LAST
M:
M: --------------030308070208000400050907--
S: {to I} The mail submission server uses URLFETCH to fetch the
pieces of the message to be sent (see [URLAUTH] for details of the
semantics and steps). The so-called "pawn-ticket" authorization
mechanism uses a URI that 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 RFC 3501.
Also, if data confidentiality is required, the mail submission
server should start TLS before issuing the LOGIN command.
S: {to M} Submission server assembles the complete message, and if
the assembly succeeds, it acknowledges acceptance of the message
by sending 250 response to the last BDAT command:
S: 250 2.5.0 Ok, message accepted.
M: {to I} The client marks the message containing the forwarded
attachment on the IMAP server.
M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 OK STORE completed
Note: the UID STORE command shown above will only work if the
marked message is in the currently selected mailbox; otherwise, it
requires a SELECT. This command can be omitted. The untagged
FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword
is described in Section 2.8.
2.5. Normative Statements Related to Forward without Download
Lemonade-compliant IMAP servers MUST support IMAP4Rev1 [RFC3501],
CATENATE [CATENATE], UIDPLUS [UIDPLUS], and URLAUTH [URLAUTH]. This
support MUST be declared via CAPABILITY [RFC3501].
Lemonade-compliant submit servers MUST support BURL [BURL], 8BITMIME
[8BITMIME], BINARYMIME [CHUNKING], and CHUNKING [CHUNKING]. This
support MUST be declared via EHLO [RFC2821]. BURL MUST support
URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap"
option following the BURL EHLO keyword (see [BURL] for more details).
Additional normative statements are provided in other sections.
2.6. Security Considerations for "pawn-tickets"
The so-called "pawn-ticket" authorization mechanism uses a URI, which
contains its own authorization credentials using [URLAUTH]. The
advantage of this mechanism is that the SMTP submit [SUBMIT] server
cannot access any data on the [RFC3501] server without a "pawn-
ticket" created by the client.
The "pawn-ticket" grants access only to the specific data that the
SMTP submit [SUBMIT] server is authorized to access, can be revoked
by the client, and can have a time-limited validity.
2.7. The fcc Problem
The "fcc problem" refers to delivering a copy of a message to a "file
carbon copy" recipient. By far, the most common case of fcc is a
client leaving a copy of outgoing mail in a "Sent Mail" or "Outbox"
mailbox.
In the traditional strategy, the MUA duplicates the effort spent in
transmitting to the MSA by writing the message to the fcc destination
in a separate step. This may be a write to a local disk file or an
APPEND to a mailbox on an IMAP server. The latter is one of the
"repetitive network data transmissions" that represents the "problem"
aspect of the "fcc problem".
The [CATENATE] extension to [RFC3501] can be used to address the fcc
problem. The final message is constructed in the mailbox designed
for outgoing mail. Note that the [CATENATE] extension can only
create a single message and only on the server that stages the
outgoing message for submission. Additional copies of the message
can be created on the same server using one or more COPY commands.
2.8. Registration of $Forwarded IMAP Keyword
The $Forwarded IMAP keyword is used by several IMAP clients to
specify that the message was resent to another email address,
embedded within or attached to a new message. A mail client sets
this keyword when it successfully forwards the message to another
email address. Typical usage of this keyword is to show a different
(or additional) icon for a message that has been forwarded. Once
set, the flag SHOULD NOT be cleared.
Lemonade-compliant servers MUST be able to store the $Forwarded
keyword. They MUST preserve it on the COPY operation. The servers
MUST support the SEARCH KEYWORD $Forwarded.
3. Message Submission
Lemonade-compliant mail submission servers are expected to implement
the following set of SMTP extensions to make message submission
efficient.
Lemonade clients should take advantage of these features.
3.1. Pipelining
Mobile clients regularly use networks with a relatively high latency.
Avoidance of round-trips within a transaction has a great advantage
for reduction in both bandwidth and total transaction time. For this
reason, Lemonade-compliant mail submission servers MUST support the
SMTP Service Extensions for Command Pipelining [RFC2920].
Clients SHOULD pipeline SMTP commands when possible.
3.2. DSN Support
Lemonade-compliant mail submission servers MUST support SMTP service
extensions for delivery status notifications [RFC3461].
3.3. Message Size Declaration
Lemonade-compliant mail submission servers MUST support the SMTP
Service Extension for Message Size Declaration [RFC1870].
Lemonade-compliant mail submission servers MUST "expand" all BURL
parts before enforcing a message size limit.
A Lemonade-compliant client SHOULD use message size declaration. In
particular, it MUST NOT send a message to a mail submission server,
if the client knows that the message exceeds the maximal message size
advertised by the submission server.
3.4. Enhanced Status Code Support
Lemonade-compliant mail submission servers MUST support SMTP Service
Extension for Returning Enhanced Error Codes [RFC2034].
3.5. TLS
Lemonade-compliant mail submission servers MUST support SMTP Service
Extension for Secure SMTP over TLS [SMTP-TLS].
4. Quick Resynchronization
Lemonade-compliant IMAP servers MUST support the CONDSTORE
[CONDSTORE] extension. It allows a client to quickly resynchronize
any mailbox by asking the server to return all flag changes that have
occurred since the last known mailbox synchronization mark.
[IMAP-DISC] shows how to perform quick mailbox resynchronization.
5. Additional IMAP Extensions
Lemonade-compliant IMAP servers MUST support the NAMESPACE
[NAMESPACE] extension. The extension allows clients to discover
shared mailboxes and mailboxes belonging to other users.
Lemonade-compliant IMAP servers MUST support the LITERAL+ [LITERAL+]
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 IDLE [IDLE]
extension. The extension allows clients to receive instant
notifications about changes in the selected mailbox, without needing
to poll for changes.
Lemonade-compliant IMAP servers MUST support IMAP over TLS [RFC3501]
as required by RFC 3501.
6. Summary of the Required IMAP and SMTP Extensions
-----------------------------------------------------|
| Name of SMTP extension | Comment |
|-------------------------|--------------------------|
| PIPELINING | Section 3.1 |
|-------------------------|--------------------------|
| DSN | Section 3.2 |
|-------------------------|--------------------------|
| SIZE | Section 3.3 |
|-------------------------|--------------------------|
| ENHANCEDSTATUSCODES | Section 3.4 |
|-------------------------|--------------------------|
| STARTTLS | Section 3.5 |
|-------------------------|--------------------------|
| BURL | Forward without download,|
| | Section 2 |
|-------------------------|--------------------------|
| URLAUTH support in BURL | Section 2.5 |
|-------------------------|--------------------------|
| CHUNKING, | Section 2.5 |
| BINARYMIME | Section 2.5 |
|-------------------------|--------------------------|
| 8BITMIME, | Required by BURL |
|-------------------------|--------------------------|
| AUTH | Required by Submission, |
| | See [SMTPAUTH]. |
|-------------------------|--------------------------|
-----------------------------------------------------|
| Name of IMAP extension | Comment |
| or feature | |
|-------------------------|--------------------------|
| NAMESPACE | Section 5 |
|-------------------------|--------------------------|
| CONDSTORE | Section 4 |
|-------------------------|--------------------------|
| STARTTLS |Required by IMAP (RFC3501)|
|-------------------------|--------------------------|
| URLAUTH, | Forward without download,|
| CATENATE, | Section 2 |
| UIDPLUS | |
|-------------------------|--------------------------|
| LITERAL+ | Section 5 |
|-------------------------|--------------------------|
| IDLE | Section 5 |
|-------------------------|--------------------------|
| $Forwarded IMAP keyword | Section 2.8 |
|-------------------------|--------------------------|
7. Future work
The Lemonade Working Group is looking into additional issues related
to usage of email by mobile devices, possibly including:
- Media conversion (static and possibly streamed)
- Transport optimization for low or costly bandwidth and less
reliable mobile networks (e.g., quick reconnect)
- Server to client notifications, possibly outside of the
traditional IMAP band
- Dealing with firewall and intermediaries
- Compression and other bandwidth optimization
- Filtering
- Other considerations for mobile clients
8. Security Considerations
Security considerations on Lemonade "forward without download" are
discussed throughout Section 2. 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 [SUBMIT]. The mandatory-to-implement
authentication mechanism for IMAP is described in [RFC3501].
8.1. Confidentiality Protection of Submitted Messages
When clients submit new messages, link protection such as TLS guards
against an eavesdropper seeing the contents of the submitted message.
It’s worth noting, however, that even if TLS is not used, the
security risks are no worse if BURL is used to reference the text
than if the text is submitted directly. If BURL is not used, an
eavesdropper gains access to the full text of the message. If BURL
is used, the eavesdropper may or may not be able to gain such access,
depending on the form of BURL used. For example, some forms restrict
use of the URL to an entity authorized as a submission server or a
specific user.
8.2. TLS
When Lemonade clients use the BURL extension to mail submission,
which requires sending a URLAUTH token to the mail submission server,
such a token should be protected from interception to avoid a replay
attack that may disclose the contents of the message to an attacker.
TLS-based encryption of the mail submission path will provide
protection against this attack.
Lemonade clients SHOULD use TLS-protected IMAP and mail submission
channels when using BURL-based message submission to protect the
URLAUTH token from interception.
Lemonade-compliant mail submission servers SHOULD use TLS-protected
IMAP connections when fetching message content using the URLAUTH
token provided by the Lemonade client.
When a client uses SMTP STARTTLS to send a BURL command that
references non-public information, there is a user expectation that
the entire message content will be treated confidentially. To meet
this expectation, the message submission server should use STARTTLS
or a mechanism providing equivalent data confidentiality when
fetching the content referenced by that URL.
9. References
9.1. Normative References
[BURL] Newman, C. "Message Submission BURL Extension", RFC 4468,
May 2006.
[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994.
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission
of Large and Binary MIME Messages", RFC 3030, December
2000.
[CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP)
CATENATE Extension", RFC 4469, April 2006.
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2920] Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, RFC 2920, September 2000.
[RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10, RFC
1870, November 1995.
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for
Mail", RFC 4409, April 2006.
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC
3461, January 2003.
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) -
URLAUTH Extension", RFC 4467, May 2006.
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
Error Codes", RFC 2034, October 1996.
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
May 1998.
[SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999.
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
January 1997.
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE Operation or Quick Flag Changes Resynchronization",
RFC 4551, June 2006.
[IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
9.2. Informative References
[IMAP-DISC] Melnikov, A., "Synchronization operations for
disconnected IMAP4 clients", Work in Progress, October
2004.
10. Acknowledgements
This document is a product of Lemonade WG. The editors thank the
Lemonade WG members that contributed comments and corrections; in
particular: Randy Gellens, Dave Cridland, and Greg Vaudreuil.
This document borrows some text from "Message Submission" (February
2004) by Mark Crispin, as well as from the trio [BURL], [CATENATE],
and [URLAUTH].
Authors’ Addresses
Stephane H. Maes
Oracle Corporation
500 Oracle Parkway
M/S 4op634
Redwood Shores, CA 94065
USA
Phone: +1-650-607-6296
EMail: stephane.maes@oracle.com
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex
TW12 2BX
UK
EMail: Alexey.melnikov@isode.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has