GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4550

Network Working Group S. Maes Request for Comments: 4550 Oracle Category: Standards Track A. Melnikov

                                                            Isode Ltd.
                                                             June 2006
       Internet Email to Support Diverse Service Environments
                         (Lemonade) Profile

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 This document describes a profile (a set of required extensions,
 restrictions, and usage modes) of the IMAP and mail submission
 protocols.  This profile allows clients (especially those that are
 constrained in memory, bandwidth, processing power, or other areas)
 to efficiently use IMAP and Submission to access and submit mail.
 This includes the ability to forward received mail without needing to
 download and upload the mail, to optimize submission, and to
 efficiently resynchronize in case of loss of connectivity with the
 server.
 The Internet Email to Support Diverse Service Environments (Lemonade)
 profile relies upon extensions to IMAP and Mail Submission protocols;
 specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501)
 extensions and the BURL extension to the SUBMIT protocol (RFC 4409).

Maes & Melnikov Standards Track [Page 1] RFC 4550 Lemonade Profile June 2006

Table of Contents

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

Maes & Melnikov Standards Track [Page 2] RFC 4550 Lemonade Profile June 2006

1. Introduction

 Lemonade provides enhancements to Internet email to support diverse
 service environments.
 This document describes the Lemonade profile, which includes:
  1. "forward without download", which describes exchanges between

Lemonade clients and servers to allow new email messages to be

       submitted incorporating content that resides on locations
       external to the client.
  1. Quick mailbox resynchronization using [CONDSTORE].
  1. Several IMAP and SMTP extensions that save bandwidth and/or

number of round-trips required to send/receive data.

 The organization of this document is as follows.  Section 2 describes
 "forward without download".  Section 3 describes additional SMTP
 extensions that must be supported by all Lemonade Submission servers.
 Section 4 describes IMAP quick resynchronization.

1.1. Conventions Used in This Document

 In examples, "M:", "I:", and "S:" indicate lines sent by the client
 messaging user agent, IMAP e-mail server, and SMTP submit server,
 respectively.
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].
 All examples in this document are optimized for Lemonade use and
 might not represent examples of proper protocol usage for a general
 use Submit/IMAP client.  In particular, examples assume that Lemonade
 Submit and IMAP servers support all Lemonade extensions described in
 this document, so they don't show how to deal with absence of an
 extension.

2. Forward without Download

2.1. Motivations

 The advent of client/server email using the [RFC3501], [RFC2821], and
 [SUBMIT] protocols has changed what formerly were local disk
 operations into repetitive network data transmissions.

Maes & Melnikov Standards Track [Page 3] RFC 4550 Lemonade Profile June 2006

 Lemonade "forward without download" makes use of the [BURL] SUBMIT
 extension to enable access to external sources during the submission
 of a message.  In combination with the IMAP [URLAUTH] extension,
 inclusion of message parts or even entire messages from the IMAP mail
 store is possible with a minimal trust relationship between the IMAP
 and SMTP SUBMIT servers.
 Lemonade "forward without download" has the advantage of maintaining
 one submission protocol, and thus avoids the risk of having multiple
 parallel and possibly divergent mechanisms for submission.  The
 client can use Submit/SMTP [SUBMIT] extensions without these being
 added to IMAP.  Furthermore, by keeping the details of message
 submission in the SMTP SUBMIT server, Lemonade "forward without
 download" can work with other message retrieval protocols such as
 Post Office Protocol (POP), Network News Transfer Protocol (NNTP), or
 whatever else may be designed in the future.

2.2. Message Sending Overview

 The act of sending an email message can be thought of as involving
 multiple steps: initiation of a new draft, draft editing, message
 assembly, and message submission.
 Initiation of a new draft and draft editing takes place in the Mail
 User Agent (MUA).  Frequently, users choose to save more complex
 messages on an [RFC3501] server (via the APPEND command with the
 \Draft flag) for later recall by the MUA and resumption of the
 editing process.
 Message assembly is the process of producing a complete message from
 the final revision of the draft and external sources.  At assembly
 time, external data is retrieved and inserted in the message.
 Message submission is the process of inserting the assembled message
 into the [RFC2821] infrastructure, typically using the [SUBMIT]
 protocol.

2.3. Traditional Strategy

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

Maes & Melnikov Standards Track [Page 4] RFC 4550 Lemonade Profile June 2006

 There is often no clear boundary between the editing and assembly
 process.  If a message is forwarded, its content is often retrieved
 immediately and inserted into the message text.  Similarly, when
 external content is inserted or attached, the content is usually
 retrieved immediately and made part of the draft.
 As a consequence, each save of a draft and subsequent retrieve of the
 draft transmits that entire (possibly large) content, as does message
 submission.
 In the past, this was not much of a problem, because drafts, external
 data, and the message submission mechanism were typically located on
 the same system as the MUA.  The most common problem was running out
 of disk quota.

2.4. Step-by-Step Description

 The model distinguishes among a Mail User Agent (MUA), an IMAP4Rev1
 Server ([RFC3501]), and a SMTP submit server ([SUBMIT]), as
 illustrated in Figure 1.
      +--------------------+               +--------------+
      |                    | <------------ |              |
      |     MUA (M)        |               | IMAPv4Rev1   |
      |                    |               |  Server      |
      |                    | ------------> | (Server I)   |
      +--------------------+               +--------------+
             ^    |                              ^     |
             |    |                              |     |
             |    |                              |     |
             |    |                              |     |
             |    |                              |     |
             |    |                              |     |
             |    |                              |     v
             |    |                        +--------------+
             |    |----------------------> |   SMTP       |
             |                             |   Submit     |
             |-----------------------------|   Server     |
                                           |  (Server S)  |
                                           +--------------+
           Figure 1:  Lemonade "forward without download"
 Lemonade "forward without download" allows a Messaging User Agent to
 compose and forward an e-mail combining fragments that are located in
 an IMAP server, without having to download these fragments to the
 client.

Maes & Melnikov Standards Track [Page 5] RFC 4550 Lemonade Profile June 2006

 There are two ways to perform "forward without download", based on
 where the message assembly takes place.  The first uses an extended
 APPEND command [CATENATE] to edit a draft message in the message
 store and cause the message assembly on the IMAP server.  The second
 uses a succession of BURL and BDAT commands to submit and assemble
 (through concatenation) message data from the client and external
 data fetched from the provided URL.  The two subsequent sections
 provide step-by-step instructions on how "forward without download"
 is achieved.

2.4.1. Message Assembly Using IMAP CATENATE Extension

 In the [BURL]/[CATENATE] variant of the Lemonade "forward without
 download" strategy, messages are initially composed and edited within
 an MUA.  The [CATENATE] extension to [RFC3501] is then used to create
 the messages on the IMAP server by transmitting new text and
 assembling them.  The [UIDPLUS] IMAP extension is used by the client
 in order to learn the Unique Identifier (UID) of the created
 messages.  Finally, a [URLAUTH] format URL is given to a [SUBMIT]
 server for submission using the [BURL] extension.
 The flow involved to support such a use case consists of:
    M: {to I -- Optional} The client connects to the IMAP server,
    optionally starts TLS (if data confidentiality is required),
    authenticates, opens a mailbox ("INBOX" in the example below) and
    fetches body structures (See [RFC3501]).
    Example:
          M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
          I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
             ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
             "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
             "trip.txt")
             "<960723163407.20117h@washington.example.com>"
             "Your trip details" "BASE64" 4554 73) "MIXED"))
          I: A0051 OK completed
    M: {to I} The client invokes CATENATE (See [CATENATE] for details
    of the semantics and steps) -- this allows the MUA to create
    messages on the IMAP server using new data combined with one or
    more message parts already present on the IMAP server.
    Note that the example for this step doesn't use the LITERAL+
    [LITERAL+] extension.  Without LITERAL+, the new message is
    constructed using 3 round-trips.  If LITERAL+ is used, the new
    message can be constructed using one round-trip.

Maes & Melnikov Standards Track [Page 6] RFC 4550 Lemonade Profile June 2006

       M: A0052 APPEND Sent FLAGS (\Seen $MDNSent)
          CATENATE (TEXT {475}
       I: + Ready for literal data
       M: Message-ID: <419399E1.6000505@caernarfon.example.org>
       M: Date: Thu, 12 Nov 2004 16:57:05 +0000
       M: From: Bob Ar <bar@example.org>
       M: MIME-Version: 1.0
       M: To: foo@example.net
       M: Subject: About our holiday trip
       M: Content-Type: multipart/mixed;
       M:     boundary="------------030308070208000400050907"
       M:
       M: --------------030308070208000400050907
       M: Content-Type: text/plain; format=flowed
       M:
       M: Our travel agent has sent the updated schedule.
       M:
       M: Cheers,
       M: Bob
       M: --------------030308070208000400050907
       M:  URL "/INBOX;UIDVALIDITY=385759045/;
          UID=25627/;Section=2.MIME" URL "/INBOX;
          UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44}
       I: + Ready for literal data
       M:
       M: --------------030308070208000400050907--
       M: )
       I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed
    M: {to I} The client uses GENURLAUTH command to request a URLAUTH
    URL (see [URLAUTH]).
    I: {to M} The IMAP server returns a URLAUTH URL suitable for later
    retrieval with URLFETCH (see [URLAUTH] for details of the
    semantics and steps).
       M: A0054 GENURLAUTH "imap://bob.ar@example.org/Sent;
          UIDVALIDITY=387899045/;uid=45;expire=2005-10-
          28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
       I: * GENURLAUTH "imap://bob.ar@example.org/Sent;
          UIDVALIDITY=387899045/;uid=45;expire=
          2005-10-28T23:59:59Z;urlauth=submit+bob.ar:
          internal:91354a473744909de610943775f92038"
       I: A0054 OK GENURLAUTH completed
    M: {to S} The client connects to the mail submission server and
    starts a new mail transaction.  It uses BURL to let the SMTP
    submit server fetch the content of the message from the IMAP

Maes & Melnikov Standards Track [Page 7] RFC 4550 Lemonade Profile June 2006

    server.  (See [BURL] for details of the semantics and steps.)
    This allows the 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 2.4.2 demonstrates this.
       S: 220 owlry.example.org ESMTP
       M: EHLO potter.example.org
       S: 250-owlry.example.com
       S: 250-8BITMIME
       S: 250-BINARYMIME
       S: 250-PIPELINING
       S: 250-BURL imap
       S: 250-CHUNKING
       S: 250-AUTH PLAIN
       S: 250-DSN
       S: 250-SIZE 10240000
       S: 250-STARTTLS
       S: 250 ENHANCEDSTATUSCODES
       M: STARTTLS
       S: 220 Ready to start TLS
       ...TLS negotiation, subsequent data is encrypted...
       M: EHLO potter.example.org
       S: 250-owlry.example.com
       S: 250-8BITMIME
       S: 250-BINARYMIME
       S: 250-PIPELINING
       S: 250-BURL imap
       S: 250-CHUNKING
       S: 250-AUTH PLAIN
       S: 250-DSN
       S: 250-SIZE 10240000
       S: 250 ENHANCEDSTATUSCODES
       M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
       S: 235 2.7.0 PLAIN authentication successful.
       M: MAIL FROM:<bob.ar@example.org>
       S: 250 2.5.0 Address Ok.
       M: RCPT TO:<foo@example.net>
       S: 250 2.1.5 foo@example.net OK.
       M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;
          uid=45/;urlauth=submit+bar:internal:
          91354a473744909de610943775f92038 LAST

Maes & Melnikov Standards Track [Page 8] RFC 4550 Lemonade Profile June 2006

    S: {to I} The mail submission server uses URLFETCH to fetch 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} 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 RFC 3501.
    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.

Maes & Melnikov Standards Track [Page 9] RFC 4550 Lemonade Profile June 2006

       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.4.2. Message Assembly Using SMTP CHUNKING and BURL Extensions

 In the [BURL]/[CHUNKING] variant of the Lemonade "forward without
 download" strategy, messages are initially composed and edited within
 an MUA.  During submission [SUBMIT], BURL [BURL] and BDAT [CHUNKING]
 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 [URLAUTH] 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 [URLAUTH]) referencing pieces of the message to be
    assembled.
    I: {to M} The IMAP server returns URLAUTH URLs suitable for later
    retrieval with URLFETCH (see [URLAUTH] for details of the
    semantics and steps).
       M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX;
          UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
          expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar"

Maes & Melnikov Standards Track [Page 10] RFC 4550 Lemonade Profile June 2006

          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 [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

Maes & Melnikov Standards Track [Page 11] RFC 4550 Lemonade Profile June 2006

       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

Maes & Melnikov Standards Track [Page 12] RFC 4550 Lemonade Profile June 2006

       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.

Maes & Melnikov Standards Track [Page 13] RFC 4550 Lemonade Profile June 2006

    Also, if data confidentiality is required, the mail submission
    server should start TLS before issuing the LOGIN command.
    S: {to M} Submission server assembles the complete message, and if
    the assembly succeeds, it acknowledges acceptance of the message
    by sending 250 response to the last BDAT command:
       S: 250 2.5.0 Ok, message accepted.
    M: {to I} The client marks the message containing the forwarded
    attachment on the IMAP server.
       M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
       I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
       I: A0053 OK STORE completed
    Note: the UID STORE command shown above will only work if the
    marked message is in the currently selected mailbox; otherwise, it
    requires a SELECT.  This command can be omitted.  The untagged
    FETCH response is due to [CONDSTORE].  The $Forwarded IMAP keyword
    is described in Section 2.8.

2.5. Normative Statements Related to Forward without Download

 Lemonade-compliant IMAP servers MUST support IMAP4Rev1 [RFC3501],
 CATENATE [CATENATE], UIDPLUS [UIDPLUS], and URLAUTH [URLAUTH].  This
 support MUST be declared via CAPABILITY [RFC3501].
 Lemonade-compliant submit servers MUST support BURL [BURL], 8BITMIME
 [8BITMIME], BINARYMIME [CHUNKING], and CHUNKING [CHUNKING].  This
 support MUST be declared via EHLO [RFC2821].  BURL MUST support
 URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap"
 option following the BURL EHLO keyword (see [BURL] for more details).
 Additional normative statements are provided in other sections.

2.6. Security Considerations for "pawn-tickets"

 The so-called "pawn-ticket" authorization mechanism uses a URI, which
 contains its own authorization credentials using [URLAUTH].  The
 advantage of this mechanism is that the SMTP submit [SUBMIT] server
 cannot access any data on the [RFC3501] server without a "pawn-
 ticket" created by the client.
 The "pawn-ticket" grants access only to the specific data that the
 SMTP submit [SUBMIT] server is authorized to access, can be revoked
 by the client, and can have a time-limited validity.

Maes & Melnikov Standards Track [Page 14] RFC 4550 Lemonade Profile June 2006

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.

Maes & Melnikov Standards Track [Page 15] RFC 4550 Lemonade Profile June 2006

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.

Maes & Melnikov Standards Track [Page 16] RFC 4550 Lemonade Profile June 2006

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

  1. —————————————————-|

| 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].     |
    |-------------------------|--------------------------|

Maes & Melnikov Standards Track [Page 17] RFC 4550 Lemonade Profile June 2006

  1. —————————————————-|

| 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:
  1. Media conversion (static and possibly streamed)
  2. Transport optimization for low or costly bandwidth and less

reliable mobile networks (e.g., quick reconnect)

  1. Server to client notifications, possibly outside of the

traditional IMAP band

  1. Dealing with firewall and intermediaries
  2. Compression and other bandwidth optimization
  3. Filtering
  4. 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].

Maes & Melnikov Standards Track [Page 18] RFC 4550 Lemonade Profile June 2006

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.

Maes & Melnikov Standards Track [Page 19] RFC 4550 Lemonade Profile June 2006

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.

Maes & Melnikov Standards Track [Page 20] RFC 4550 Lemonade Profile June 2006

 [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].

Maes & Melnikov Standards Track [Page 21] RFC 4550 Lemonade Profile June 2006

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

Maes & Melnikov Standards Track [Page 22] RFC 4550 Lemonade Profile June 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Maes & Melnikov Standards Track [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4550.txt · Last modified: 2006/06/14 23:05 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki