idnits 2.17.1 draft-ietf-lemonade-profile-bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1693. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 3, 2007) is 6225 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) == Outdated reference: A later version (-08) exists of draft-ietf-lemonade-compress-07 ** Obsolete normative reference: RFC 4551 (ref. 'IMAP-CONDSTORE') (Obsoleted by RFC 7162) == Outdated reference: A later version (-05) exists of draft-cridland-imap-context-00 == Outdated reference: A later version (-20) exists of draft-ietf-lemonade-convert-05 == Outdated reference: A later version (-17) exists of draft-daboo-imap-annotatemore-11 == Outdated reference: A later version (-07) exists of draft-gulbrandsen-imap-notify-03 == Outdated reference: A later version (-06) exists of draft-ietf-lemonade-reconnect-client-03 == Outdated reference: A later version (-05) exists of draft-ietf-lemonade-search-within-04 ** Obsolete normative reference: RFC 1652 (ref. 'SMTP-8BITMIME') (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 2554 (ref. 'SMTP-AUTH') (Obsoleted by RFC 4954) ** Obsolete normative reference: RFC 2197 (ref. 'SMTP-PIPELINING') (Obsoleted by RFC 2920) ** Obsolete normative reference: RFC 4409 (ref. 'SUBMIT') (Obsoleted by RFC 6409) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'ESMTP') (Obsoleted by RFC 5321) == Outdated reference: A later version (-09) exists of draft-ietf-lemonade-deployments-06 == Outdated reference: A later version (-12) exists of draft-martin-managesieve-07 == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-12 Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LEMONADE D. Cridland, Ed. 3 Internet-Draft A. Melnikov, Ed. 4 Intended status: Standards Track Isode Limited 5 Expires: October 5, 2007 S. Maes, Ed. 6 Oracle 7 April 3, 2007 9 The Lemonade Profile 10 draft-ietf-lemonade-profile-bis-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 5, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes a profile (a set of required extensions, 44 restrictions and usage modes) of the IMAP and mail submission 45 protocols. This profile allows clients (especially those that are 46 constrained in memory, bandwidth, processing power, or other areas) 47 to efficiently use IMAP and Submission to access and submit mail. 48 This includes the ability to forward received mail without needing to 49 download and upload the mail, to optimize submission and to 50 efficiently resynchronize in case of loss of connectivity with the 51 server. 53 The Lemonade profile relies upon several extensions to IMAP and Mail 54 Submission protocols. 56 Table of Contents 58 1. Conventions used in this document . . . . . . . . . . . . . . 4 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Summary of the required support . . . . . . . . . . . . . . . 5 61 3.1. Lemonade Submission Servers . . . . . . . . . . . . . . . 5 62 3.2. Lemonade Message Stores . . . . . . . . . . . . . . . . . 6 63 4. Lemonade Submission Servers . . . . . . . . . . . . . . . . . 7 64 4.1. Forward Without Download . . . . . . . . . . . . . . . . . 7 65 4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.3. DSN Support . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.4. Message size declaration . . . . . . . . . . . . . . . . . 7 68 4.5. Enhanced status code Support . . . . . . . . . . . . . . . 8 69 4.6. Encryption and Compression . . . . . . . . . . . . . . . . 8 70 5. Lemonade Message Stores . . . . . . . . . . . . . . . . . . . 9 71 5.1. Quick resynchronization . . . . . . . . . . . . . . . . . 9 72 5.2. Message part handling . . . . . . . . . . . . . . . . . . 9 73 5.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.4. In band notifications . . . . . . . . . . . . . . . . . . 10 75 5.5. Searching and View Filters . . . . . . . . . . . . . . . . 10 76 5.6. Mailbox Handling . . . . . . . . . . . . . . . . . . . . . 11 77 5.7. Forward Without Download . . . . . . . . . . . . . . . . . 11 78 5.8. Additional IMAP extensions . . . . . . . . . . . . . . . . 11 79 5.9. Registration of $Forwarded IMAP keyword . . . . . . . . . 11 80 6. Lemonade Mail User Agents . . . . . . . . . . . . . . . . . . 12 81 7. Forward without download . . . . . . . . . . . . . . . . . . . 12 82 7.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.2. Message Sending Overview . . . . . . . . . . . . . . . . . 13 84 7.3. Traditional Strategy . . . . . . . . . . . . . . . . . . . 13 85 7.4. Step by step description . . . . . . . . . . . . . . . . . 14 86 7.4.1. Message assembly using IMAP CATENATE extension . . . . 15 87 7.4.2. Message assembly using SMTP CHUNKING and BURL 88 extensions . . . . . . . . . . . . . . . . . . . . . . 19 89 7.5. Security Considerations for pawn-tickets. . . . . . . . . 23 90 7.6. Copies of Sent messages: The fcc problem . . . . . . . . . 23 91 8. OMA MEM Requirement document . . . . . . . . . . . . . . . . . 24 92 8.1. OMA MEM Architecture . . . . . . . . . . . . . . . . . . . 24 93 8.2. OMA MEM Deployment Issues . . . . . . . . . . . . . . . . 24 94 8.3. OMA MEM proxy . . . . . . . . . . . . . . . . . . . . . . 24 95 8.4. IETF Lemonade Architecture . . . . . . . . . . . . . . . . 25 96 8.5. Lemonade profile logical architecture . . . . . . . . . . 26 97 8.5.1. Relationship between the OMA MEM and Lemonade 98 logical architectures . . . . . . . . . . . . . . . . 26 99 8.5.2. Lemonade realization of OMA MEM with non-Lemonade 100 compliant servers . . . . . . . . . . . . . . . . . . 28 101 8.6. Filters and server to client notifications and Lemonade . 29 102 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 31 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 104 10.1. Confidentiality Protection of Submitted Messages . . . . . 31 105 10.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 106 10.3. Additional extensions and deployment models . . . . . . . 32 107 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 108 12. Version history . . . . . . . . . . . . . . . . . . . . . . . 32 109 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 110 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 111 14.1. Normative References . . . . . . . . . . . . . . . . . . . 34 112 14.2. Informative References . . . . . . . . . . . . . . . . . . 36 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 114 Intellectual Property and Copyright Statements . . . . . . . . . . 39 116 1. Conventions used in this document 118 In examples, "M:", "I:" and "S:" indicate lines sent by the client 119 messaging user agent, IMAP e-mail server and SMTP submit server 120 respectively. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [KEYWORDS]. 126 Other capitalised words are typically names of extensions or commands 127 - these are uppercased for clarity only, and are case-insensitive. 129 All examples in this document are optimized for Lemonade use and 130 might not represent examples of proper protocol usage for a general 131 use Submit/IMAP client. In particular examples assume that Submit 132 and IMAP servers support all Lemonade extensions described in this 133 document, so they do not demonstrate fallbacks in the absence of an 134 extension. 136 2. Introduction 138 The Lemonade Profile, or simply Lemonade, provides enhancements to 139 Internet email to support diverse service environments. Lemonade 140 Mail Servers provide both a Lemonade Submission Server and a Lemonade 141 Message Store, which are based on the existing [SUBMIT] and [IMAP] 142 protocols respectively. 144 This document describes the Lemonade profile that includes: 145 o General common enhancements to Internet Mail, described in 146 Section 5 and Section 4. 147 o "Forward without download" that describes exchanges between 148 Lemonade clients and servers to allow to submit new email messages 149 incorporating content which resides on locations external to the 150 client, described in Section 7. 151 o Quick mailbox resynchronization, described in Section 5.1. 152 o Extensions to support more precise, and broader, notifications 153 from the store in support of notifications and view filters, 154 described in Section 5.4 and Section 5.5. 156 It is intended that the Lemonade profile support realizations of the 157 OMA's mobile email enabler (MEM) (see [MEM-req] and [MEM-arch]) using 158 Internet Mail protocols defined by the IETF. 160 3. Summary of the required support 162 3.1. Lemonade Submission Servers 164 Lemonade Submission Servers MUST provide a service as described in 165 [SUBMIT], and MUST support the following. Note that the Lemonade 166 Profile imposes further requirements for some cases, detailed in the 167 sections cited. 169 +---------------------+--------------------+--------------+ 170 | SMTP extension | Reference | Requirements | 171 +---------------------+--------------------+--------------+ 172 | PIPELINING | [SMTP-PIPELINING] | Section 4.2 | 173 | DSN | [SMTP-DSN] | Section 4.3 | 174 | SIZE | [SMTP-SIZE] | Section 4.4 | 175 | ENHANCEDSTATUSCODES | [SMTP-STATUSCODES] | Section 4.5 | 176 | STARTTLS | [SMTP-TLS] | Section 4.6 | 177 | BURL imap | [SMTP-BURL] | Section 7 | 178 | BINARYMIME | [SMTP-BINARYMIME] | Section 4.1 | 179 | CHUNKING | [SMTP-BINARYMIME] | Section 4.1 | 180 | 8BITMIME | [SMTP-8BITMIME] | [SMTP-BURL] | 181 | AUTH | [SMTP-AUTH] | [SUBMIT] | 182 | QUICKSTART | | Section 4.6 | 183 +---------------------+--------------------+--------------+ 185 3.2. Lemonade Message Stores 187 Lemonade Message Stores MUST provide a service as described in 188 [IMAP], and MUST support the following. Note that the Lemonade 189 Profile imposes further requirements for some cases, detailed in the 190 sections cited. 192 +------------------+------------------+--------------+ 193 | IMAP extension | Reference | Requirements | 194 +------------------+------------------+--------------+ 195 | NAMESPACE | [IMAP-NAMESPACE] | Section 5.6 | 196 | CONDSTORE | [IMAP-CONDSTORE] | Section 5.1 | 197 | STARTTLS | [IMAP] | - | 198 | URLAUTH | [IMAP-URLAUTH] | Section 5.7 | 199 | CATENATE | [IMAP-CATENATE] | Section 5.7 | 200 | UIDPLUS | [IMAP-UIDPLUS] | Section 5.7 | 201 | LITERAL+ | [IMAP-LITERAL+] | Section 5.8 | 202 | IDLE | [IMAP-IDLE] | Section 5.4 | 203 | NOTIFY | [IMAP-NOTIFY] | Section 5.4 | 204 | $Forwarded | - | Section 5.9 | 205 | BINARY | [IMAP-BINARY] | Section 5.2 | 206 | QRESYNC | [IMAP-QRESYNC] | Section 5.1 | 207 | ESEARCH | [IMAP-ESEARCH] | Section 5.5 | 208 | WITHIN | [IMAP-WITHIN] | Section 5.5 | 209 | CONTEXT | [IMAP-CONTEXT] | Section 5.5 | 210 | CONVERT | [IMAP-CONVERT] | Section 5.2 | 211 | COMPRESS=DEFLATE | [IMAP-COMPRESS] | Section 5.3 | 212 | METADATA | [IMAP-METADATA] | Section 5.8 | 213 | LIST-EXTENDED | [IMAP-LISTEXT] | Section 5.8 | 214 +------------------+------------------+--------------+ 216 4. Lemonade Submission Servers 218 All Lemonade Submission Servers implement the Mail Submission 219 protocol described in [SUBMIT], which is in turn a specific profile 220 of [ESMTP]. Therefore any MUA designed to submit email via [SUBMIT] 221 or [ESMTP] will interoperate with Lemonade Submission Servers. 223 In addition, Lemonade Submission Servers implement the following set 224 of SMTP and Submission extensions to increase message submission 225 efficiency. 227 4.1. Forward Without Download 229 In order to optimize network usage for the typical case where message 230 content is copied to, or sourced from, the IMAP store, Lemonade 231 provides support for a suite of extensions collectively known as 232 Forward Without Download, discussed in detail in Section 7. 234 Lemonade Submission Servers MUST support the BURL [SMTP-BURL], 235 8BITMIME [SMTP-8BITMIME], BINARYMIME [SMTP-BINARYMIME] and CHUNKING 236 [SMTP-BINARYMIME]. 238 BURL MUST support URLAUTH type URLs [IMAP-URLAUTH], and thus MUST 239 advertise the "imap" option following the BURL EHLO keyword (See 240 [SMTP-BURL] for more details). 242 4.2. Pipelining 244 Some clients regularly use networks with a relatively high latency, 245 such as Mobile or Satellite based networks. Avoidance of round-trips 246 within a transaction has a great advantage for the reduction in both 247 bandwidth and total transaction time. For this reason Lemonade 248 compliant mail submission servers MUST support the SMTP Service 249 Extensions for Command Pipelining [SMTP-PIPELINING]. 251 In addition, Lemonade Submission Servers provide full support for the 252 QUICKSTART framework described in . 254 4.3. DSN Support 256 Lemonade compliant mail submission servers MUST support SMTP service 257 extensions for delivery status notifications [SMTP-DSN]. 259 4.4. Message size declaration 261 There is a distinct advantage in detecting failure cases as early as 262 possible in many cases, such as where the user is charged per-octet, 263 or where bandwidth is low. This is especially true of large message 264 sizes. 266 Lemonade Submission Servers MUST support the SMTP Service Extension 267 for Message Size Declaration [SMTP-SIZE]. 269 Lemonade Submission Servers MUST NOT consider a supplied message size 270 to be acceptable without expanding all BURL parts. 272 A Lemonade capable client SHOULD use message size declaration. In 273 particular the client MUST NOT send a message to a mail submission 274 server, if it knows that the message exceeds the maximal message size 275 advertised by the submission server. When including a message size 276 in the MAIL FROM command, the client MUST use a value that is at 277 least as large as the size of the assembled message data after 278 resolution of all BURL parts. 280 4.5. Enhanced status code Support 282 Lemonade compliant mail submission servers MUST support SMTP Service 283 Extension for Returning Enhanced Error Codes [SMTP-STATUSCODES]. 284 These allow a client to determine the precise cause of failure. 286 4.6. Encryption and Compression 288 Lemonade Compliant mail submission servers MUST support SMTP Service 289 Extension for Secure SMTP over TLS [SMTP-TLS]. 291 Support for the DEFLATE compression method, as described in 292 [TLS-COMP], is RECOMMENDED. 294 Lemonade Submission Servers MUST support the QUICKSTART extension 295 defined in $lt;No Draft>, which provides for considerably fewer 296 round-trips at the commencement of a submission. 298 5. Lemonade Message Stores 300 All Lemonade Message Stores implement Internet Message Access 301 Protocol, as defined in [IMAP]. Therefore any MUA written to access 302 messages using the facilities described in [IMAP] will interoperate 303 with a Lemonade Message Store. 305 In addition, Lemonade Message Stores provide a set of extensions to 306 address the limitations of some clients and networks. 308 5.1. Quick resynchronization 310 Resynchronization is a costly part of an IMAP session, and mobile 311 networks are generally more prone to unintended disconnection, which 312 in turns makes this problem more acute. Therefore Lemonade Message 313 Stores provide a suite of extensions to reduce the synchronization 314 cost. 316 Lemonade Compliant IMAP servers MUST support the CONDSTORE 317 [IMAP-CONDSTORE] and the QRESYNC [IMAP-QRESYNC] extensions. These 318 allow a client to quickly resynchronize any mailbox by asking the 319 server to return all flag changes and expunges that have occurred 320 since a previously recorded state. This can also speed up client 321 reconnect in case the transport layer is cut, whether accidentally or 322 as part of a change in network. 324 [IMAP-SYNC-HOWTO] details how clients perform efficient mailbox 325 resynchronization. 327 5.2. Message part handling 329 The handling of message parts, especially attachments, represents a 330 set of challenges to limited devices, both in terms of the bandwidth 331 used, and the capability of the device. 333 Lemonade Compliant IMAP servers MUST support the BINARY [IMAP-BINARY] 334 extension. This moves MIME body part decoding operations from the 335 client to the server. The decoded data is always equal or less than 336 the encoded representation, so this reduces bandwidth effectively. 338 [IMAP-BINARY] allows for servers to refuse to accept uploaded 339 messages containing binary data, by not accepting the Binary content- 340 transfer-encoding; however Lemonade Compliant IMAP servers SHALL 341 always accept binary encoded MIME messages in APPEND commands for any 342 folder. 344 [IMAP-CONVERT] MUST also be supported by servers, which allows 345 clients to request conversions between media types, and allows for 346 scaling images, etc. This provides the ability to view attachments 347 (and sometimes body parts) without the facility to cope with a wide 348 range of media types, or to efficiently view attachments. 350 5.3. Compression 352 The IETF has for some time generally agreed that compression is best 353 handled at as low a level as possible, therefore Lemonade Message 354 Stores SHOULD support the Deflate compression algorithm for TLS, as 355 defined in [TLS-COMP]. 357 However, the working group acknowledges that for many endpoints, this 358 is a rarely deployed technology, and as such, Lemonade Message Stores 359 MUST provide [IMAP-COMPRESS] support for fallback application-level 360 stream compression, where TLS is not actively providing compression. 362 5.4. In band notifications 364 Lemonade Message Stores MUST support the IDLE [IMAP-IDLE] extension. 365 The extension allows clients to receive unsolicited notifications 366 about changes in the selected mailbox, without needing to poll for 367 changes. The responses forming these notifications MUST be sent in a 368 timely manner when such changes happen. 370 Lemonade Message Stores also provide the NOTIFY extension described 371 in [IMAP-NOTIFY], which allows clients to request specific event 372 types to be sent immediately to the client, both for the currently 373 selected folder and others. Such event types include message 374 delivery, and mailbox renames. 376 5.5. Searching and View Filters 378 Lemonade Message Stores MUST support the ESEARCH [IMAP-ESEARCH] 379 extension. The extension allows clients to efficiently find the 380 first or last messages, find a count of matching messages, and obtain 381 a list of matching messages in a considerably more compact 382 representation. 384 Lemonade Message Stores MUST support the WITHIN [IMAP-WITHIN] 385 extension. The extension allows clients to easily find all messages 386 that were delivered within a specific time period. 388 Lemonade Message Stores also provide a mechanism for clients to avoid 389 handling an entire mailbox, instead accessing a view of the mailbox. 390 This technique, common in many desktop clients as a client-side 391 capability, is useful for constrained clients to minimize the 392 quantity of messages and notification data. 394 Lemonade Message Stores therefore MUST implement the CONTEXT 395 extension defined in [IMAP-CONTEXT]. 397 5.6. Mailbox Handling 399 Lemonade Message Stores MUST support the NAMESPACE [IMAP-NAMESPACE] 400 extension. The extension allows clients to discover shared mailboxes 401 and mailboxes belonging to other users, and provide a normalized 402 heirarchy view of the mailboxes available. 404 Lemonade Message Stores MUST support the METADATA [IMAP-METADATA] 405 extension. This allows metadata to be stored against mailboxes, 406 which is a facility used by other extensions mandated by this 407 profile. 409 Lemonade Message Stores MUST support the LIST-EXTENDED [IMAP-LISTEXT] 410 extension. This is required for the METADATA [IMAP-METADATA] 411 extension. It defines an extensible LIST command. 413 5.7. Forward Without Download 415 In order to optimize network usage for the typical case where message 416 content is copied to, or sourced from, the IMAP store, Lemonade 417 provides support for a suite of extensions collectively known as 418 Forward Without Download, discussed in detail in Section 7. 420 Lemonade Message Stores MUST support CATENATE [IMAP-CATENATE], 421 UIDPLUS [IMAP-UIDPLUS] and URLAUTH [IMAP-URLAUTH]. 423 5.8. Additional IMAP extensions 425 Lemonade Message Stores MUST support the LITERAL+ [IMAP-LITERAL+] 426 extension. The extension allows clients to save a round trip each 427 time a non-synchronizing literal is sent. 429 Lemonade Compliant IMAP servers MUST support IMAP over TLS [IMAP] as 430 required by [IMAP]. As noted above in Section 5.3, servers SHOULD 431 support the deflate compression algorithm for TLS, as specified in 432 [TLS-COMP] 434 5.9. Registration of $Forwarded IMAP keyword 436 The $Forwarded IMAP keyword is used by several IMAP clients to 437 specify that the marked message was forwarded to another email 438 address, embedded within or attached to a new message. A mail client 439 sets this keyword when it successfully forwards the message to 440 another email address. Typical usage of this keyword is to show a 441 different (or additional) icon for a message that has been forwarded. 443 Once set the flag SHOULD NOT be cleared. 445 Lemonade Message Stores MUST be able to store the $Forwarded keyword. 446 They MUST preserve it on the COPY operation. The servers MUST 447 support the SEARCH KEYWORD $Forwarded. 449 6. Lemonade Mail User Agents 451 Although all existing IMAP MUAs are Lemonade compliant in as much as 452 all Lemonade services are based on the existing [IMAP] and [SUBMIT] 453 protocols, client implementors are encouraged to take full advantage 454 of the facilities provided by Lemonade Submission Servers and 455 Lemonade Message Stores, as described in Section 4 and Section 5 456 respectively. 458 Note that the explicit usage of [SUBMIT] means that when opening a 459 connection to the submission server, clients MUST do so using port 460 587 unless explicitly configured to use an alternate port. If the 461 TCP connection to the submission server fails to open using port 587, 462 the client MAY then immediately retry using a different port, such as 463 25. See [SUBMIT] information on why using port 25 is likely to fail 464 depending on the current location of the client, and may result in a 465 failure code during the SMTP transaction. 467 In addition, some specifications are useful to support interoperable 468 messaging with an enhanced user experience. 470 Lemonade capable clients SHOULD support the Format and DelSp 471 parameters to the text/plain media type described in [FLOWED], and 472 generate this format for messages. 474 Lemonade capable clients SHOULD support, and use, the $Forwarded 475 keyword described in Section 5.9. 477 7. Forward without download 479 7.1. Motivations 481 The advent of client/server email using the [IMAP] and [SUBMIT] 482 protocols changed what formerly were local disk operations to become 483 repetitive network data transmissions. 485 Lemonade "forward without download" makes use of the [SMTP-BURL] 486 extension to enable access to external sources during the submission 487 of a message. In combination with the [IMAP-URLAUTH] extension, 488 inclusion of message parts or even entire messages from the IMAP mail 489 store is possible with a minimal trust relationship between the IMAP 490 and SMTP SUBMIT servers. 492 Lemonade "forward without download" has the advantage of maintaining 493 one submission protocol, and thus avoids the risk of having multiple 494 parallel and possibly divergent mechanisms for submission. The 495 client can use [SUBMIT] extensions without these being added to IMAP. 496 Furthermore, by keeping the details of message submission in the SMTP 497 SUBMIT server, Lemonade "forward without download" can work with 498 other message retrieval protocols such as POP, NNTP, or whatever else 499 may be designed in the future. 501 7.2. Message Sending Overview 503 The act of sending an email message can be thought of as involving 504 multiple steps: initiation of a new draft, draft editing, message 505 assembly, and message submission. 507 Initiation of a new draft and draft editing takes place in the MUA. 508 Frequently, users choose to save more complex messages on an [IMAP] 509 server (via the APPEND command with the \Draft flag) for later recall 510 by the MUA and resumption of the editing process. 512 Message assembly is the process of producing a complete message from 513 the final revision of the draft and external sources. At assembly 514 time, external data is retrieved and inserted in the message. 516 Message submission is the process of inserting the assembled message 517 into the [ESMTP] infrastructure, typically using the [SUBMIT] 518 protocol. 520 7.3. Traditional Strategy 522 Traditionally, messages are initiated, edited, and assembled entirely 523 within an MUA, although drafts may be saved to an [IMAP] server and 524 later retrieved from the server. The completed text is then 525 transmitted to an MSA for delivery. 527 There is often no clear boundary between the editing and assembly 528 process. If a message is forwarded, its content is often retrieved 529 immediately and inserted into the message text. Similarly, when 530 external content is inserted or attached, the content is usually 531 retrieved immediately and made part of the draft. 533 As a consequence, each save of a draft and subsequent retrieve of the 534 draft transmits that entire (possibly large) content, as does message 535 submission. 537 In the past, this was not much of a problem, because drafts, external 538 data, and the message submission mechanism were typically located on 539 the same system as the MUA. The most common problem was running out 540 of disk quota. 542 7.4. Step by step description 544 The model distinguishes between a Messaging User Agent (MUA), an 545 IMAPv4Rev1 Server ([IMAP]) and a SMTP submit server ([SUBMIT]), as 546 illustrated in Figure 1. 548 +--------------------+ +--------------+ 549 | | <------------ | | 550 | MUA (M) | | IMAPv4Rev1 | 551 | | | Server | 552 | | ------------> | (Server I) | 553 +--------------------+ +--------------+ 554 ^ | ^ | 555 | | | | 556 | | | | 557 | | | | 558 | | | | 559 | | | | 560 | | | v 561 | | +--------------+ 562 | |----------------------> | SMTP | 563 | | Submit | 564 |-----------------------------| Server | 565 | (Server S) | 566 +--------------+ 568 Figure 1: Lemonade "forward without download" 570 Lemonade "forward without download" allows a Messaging User Agent to 571 compose and forward an e-mail combining fragments that are located in 572 an IMAP server, without having to download these fragments to the 573 client. 575 There are two ways to perform "forward without download" based on 576 where the message assembly takes place. The first uses extended 577 APPEND command [IMAP-CATENATE] to edit a draft message in the message 578 store and cause the message assembly on the IMAP server. This is 579 most often used when a copy of the message is to be retained on the 580 IMAP server, as discussed in Section 7.6. 582 The second uses a succession of BURL and BDAT commands to submit and 583 assemble through concatenation, message data from the client and 584 external data fetched from the provided URL. The two subsequent 585 sections provide step-by-step instructions on how "forward without 586 download" is achieved. 588 7.4.1. Message assembly using IMAP CATENATE extension 590 In the [SMTP-BURL]/[IMAP-CATENATE] variant of the Lemonade "forward 591 without download" strategy, messages are initially composed and 592 edited within an MUA. The [IMAP-CATENATE] extension to [IMAP] is 593 then used to create the messages on the IMAP server by transmitting 594 new text and assembling them. The UIDPLUS [IMAP-UIDPLUS] IMAP 595 extension is used by the client in order to learn the UID of the 596 created messages. Finally a [IMAP-URLAUTH] format URL is given to a 597 [SUBMIT] server for submission using the BURL [SMTP-BURL] extension. 599 The flow involved to support such a use case consists of: 601 M: {to I -- Optional} The client connects to the IMAP server, 602 optionally starts TLS (if data confidentiality is required), 603 authenticates, opens a mailbox ("INBOX" in the example below) and 604 fetches body structures (See [IMAP]). 606 Example: 608 M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) 609 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 610 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( 611 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 612 "trip.txt") 613 "<960723163407.20117h@washington.example.com>" 614 "Your trip details" "BASE64" 4554 73) "MIXED")) 615 I: A0051 OK completed 617 M: {to I} The client invokes CATENATE (See [IMAP-CATENATE] for 618 details of the semantics and steps) -- this allows the MUA to create 619 messages on the IMAP server using new data combined with one or more 620 message parts already present on the IMAP server. 622 Note that the example for this step doesn't use the LITERAL+ 623 [IMAP-LITERAL+] extension. Without LITERAL+ the new message is 624 constructed using 3 round-trips. If LITERAL+ is used, the new 625 message can be constructed using one round-trip. 627 M: A0052 APPEND Sent FLAGS (\Draft \Seen $MDNSent) 628 CATENATE (TEXT {475} 629 I: + Ready for literal data 630 M: Message-ID: <419399E1.6000505@caernarfon.example.org> 631 M: Date: Thu, 12 Nov 2004 16:57:05 +0000 632 M: From: Bob Ar 633 M: MIME-Version: 1.0 634 M: To: foo@example.net 635 M: Subject: About our holiday trip 636 M: Content-Type: multipart/mixed; 637 M: boundary="------------030308070208000400050907" 638 M: 639 M: --------------030308070208000400050907 640 M: Content-Type: text/plain; format=flowed 641 M: 642 M: Our travel agent has sent the updated schedule. 643 M: 644 M: Cheers, 645 M: Bob 646 M: --------------030308070208000400050907 647 M: URL "/INBOX;UIDVALIDITY=385759045/; 648 UID=25627/;Section=2.MIME" URL "/INBOX; 649 UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44} 650 I: + Ready for literal data 651 M: 652 M: --------------030308070208000400050907-- 653 M: ) 654 I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed 656 M: {to I} The client uses GENURLAUTH command to request a URLAUTH URL 657 (See [IMAP-URLAUTH]). 658 I: {to M} The IMAP server returns a URLAUTH URL suitable for later 659 retrieval with URLFETCH (See [IMAP-URLAUTH] for details of the 660 semantics and steps). 662 M: A0054 GENURLAUTH "imap://bob.ar@example.org/Sent; 663 UIDVALIDITY=387899045/;uid=45;expire=2005-10- 664 28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL 665 I: * GENURLAUTH "imap://bob.ar@example.org/Sent; 666 UIDVALIDITY=387899045/;uid=45;expire= 667 2005-10-28T23:59:59Z;urlauth=submit+bob.ar: 668 internal:91354a473744909de610943775f92038" 669 I: A0054 OK GENURLAUTH completed 671 M: {to S} The client connects to the mail submission server and 672 starts a new mail transaction. It uses BURL to let the SMTP submit 673 server fetch the content of the message from the IMAP server (See 674 [IMAP-URLAUTH] for details of the semantics and steps -- this allows 675 the MUA to authorize the SMTP submit server to access the message 676 composed as a result of the CATENATE step). Note that the second 677 EHLO command is required after a successful STARTTLS command. Also 678 note that there might be a third required EHLO command if the second 679 EHLO response doesn't list any BURL options. Section 7.4.2 680 demonstrates this. 682 S: 220 owlry.example.org ESMTP 683 M: EHLO potter.example.org 684 S: 250-owlry.example.com 685 S: 250-8BITMIME 686 S: 250-BINARYMIME 687 S: 250-PIPELINING 688 S: 250-BURL imap 689 S: 250-CHUNKING 690 S: 250-AUTH PLAIN 691 S: 250-DSN 692 S: 250-SIZE 10240000 693 S: 250-STARTTLS 694 S: 250 ENHANCEDSTATUSCODES 695 M: STARTTLS 696 S: 220 Ready to start TLS 697 ...TLS negotiation, subsequent data is encrypted... 698 M: EHLO potter.example.org 699 S: 250-owlry.example.com 700 S: 250-8BITMIME 701 S: 250-BINARYMIME 702 S: 250-PIPELINING 703 S: 250-BURL imap 704 S: 250-CHUNKING 705 S: 250-AUTH PLAIN 706 S: 250-DSN 707 S: 250-SIZE 10240000 708 S: 250 ENHANCEDSTATUSCODES 709 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 710 S: 235 2.7.0 PLAIN authentication successful. 711 M: MAIL FROM: 712 S: 250 2.5.0 Address Ok. 713 M: RCPT TO: 714 S: 250 2.1.5 foo@example.net OK. 715 M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/; 716 uid=45/;urlauth=submit+bar:internal: 717 91354a473744909de610943775f92038 LAST 719 S: {to I} The mail submission server uses URLFETCH to fetch the 720 message to be sent (See [IMAP-URLAUTH] for details of the semantics 721 and steps. The so-called "pawn-ticket" authorization mechanism uses 722 a URI which contains its own authorization credentials.). 724 I: {to S} Provides the message composed as a result of the CATENATE 725 step). 727 Mail submission server opens IMAP connection to the IMAP server: 729 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ 730 CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com 731 IMAP server ready 732 S: a000 STARTTLS 733 I: a000 Start TLS negotiation now 734 ...TLS negotiation, if successful - subsequent data 735 is encrypted... 736 S: a001 LOGIN submitserver secret 737 I: a001 OK submitserver logged in 738 S: a002 URLFETCH "imap://bob.ar@example.org/Sent; 739 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: 740 internal:91354a473744909de610943775f92038" 741 I: * URLFETCH "imap://bob.ar@example.org/Sent; 742 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: 743 internal:91354a473744909de610943775f92038" {15065} 744 ...message body follows... 745 S: a002 OK URLFETCH completed 746 I: a003 LOGOUT 747 S: * BYE See you later 748 S: a003 OK Logout successful 750 Note that if the IMAP server doesn't send CAPABILITY response code in 751 the greeting, the mail submission server must issue the CAPABILITY 752 command to learn about supported IMAP extensions as described in 753 [IMAP]. 755 Also, if data confidentiality is not required the mail submission 756 server may omit the STARTTLS command before issuing the LOGIN 757 command. 759 S: {to M} Submission server assembles the complete message and if the 760 assembly succeeds it returns OK to the MUA: 762 S: 250 2.5.0 Ok. 764 M: {to I} The client marks the message containing the forwarded 765 attachment on the IMAP server. 767 M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) 768 I: * 215 FETCH (UID 25627 MODSEQ (12121231000)) 769 I: A0053 OK STORE completed 771 Note: the UID STORE command shown above will only work if the marked 772 message is in the currently selected mailbox; otherwise, it requires 773 a SELECT. This command can be omitted, as it simply changes non- 774 operational metadata not essential to client operations or 775 interoperability. The untagged FETCH response is due to 776 [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in 777 Section 5.9. 779 7.4.2. Message assembly using SMTP CHUNKING and BURL extensions 781 In the [IMAP-URLAUTH]/[SMTP-BURL] variant of the Lemonade "forward 782 without download" strategy, messages are initially composed and 783 edited within an MUA. During submission [SUBMIT], BURL [SMTP-BURL] 784 and BDAT [SMTP-BINARYMIME] commands are used to create the messages 785 from multiple parts. New body parts are supplied using BDAT 786 commands, while existing body parts are referenced using 787 [IMAP-URLAUTH] format URLs in BURL commands. 789 The flow involved to support such a use case consists of: 790 M: {to I -- Optional} The client connects to the IMAP server, 791 optionally starts TLS (if data confidentiality is required), 792 authenticates, opens a mailbox ("INBOX" in the example below) and 793 fetches body structures (See [IMAP]). 795 Example: 797 M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) 798 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 799 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( 800 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 801 "trip.txt") 802 "<960723163407.20117h@washington.example.com>" 803 "Your trip details" "BASE64" 4554 73) "MIXED")) 804 I: A0051 OK completed 806 M: {to I} The client uses GENURLAUTH command to request URLAUTH URLs 807 (See [IMAP-URLAUTH]) referencing pieces of the message to be 808 assembled. 809 I: {to M} The IMAP server returns URLAUTH URLs suitable for later 810 retrieval with URLFETCH (See [IMAP-URLAUTH] for details of the 811 semantics and steps). 813 M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX; 814 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 815 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" 816 INTERNAL "imap://bob.ar@example.org/INBOX; 817 UIDVALIDITY=385759045/;UID=25627/;Section=2; 818 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL 819 I: * GENURLAUTH "imap://bob.ar@example.org/INBOX; 820 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 821 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 822 internal:A0DEAD473744909de610943775f9BEEF" 823 "imap://bob.ar@example.org/INBOX; 824 UIDVALIDITY=385759045/;UID=25627/;Section=2; 825 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 826 internal:BEEFA0DEAD473744909de610943775f9" 827 I: A0054 OK GENURLAUTH completed 829 M: {to S} The client connects to the mail submission server and 830 starts a new mail transaction. It uses BURL to instruct the SMTP 831 submit server to fetch from the IMAP server pieces of the message to 832 be sent (See [SMTP-BURL] for details of the semantics and steps). 834 Note that the second EHLO command is required after a successful 835 STARTTLS command. The third EHLO command is required if and only if 836 the second EHLO response doesn't list any BURL options. See 837 Section 7.4.1 for an example of submission where the third EHLO 838 command/response is not present. 840 S: 220 owlry.example.org ESMTP 841 M: EHLO potter.example.org 842 S: 250-owlry.example.com 843 S: 250-8BITMIME 844 S: 250-BINARYMIME 845 S: 250-PIPELINING 846 S: 250-BURL 847 S: 250-CHUNKING 848 S: 250-AUTH DIGEST-MD5 849 S: 250-DSN 850 S: 250-SIZE 10240000 851 S: 250-STARTTLS 852 S: 250 ENHANCEDSTATUSCODES 853 M: STARTTLS 854 S: 220 Ready to start TLS 855 ...TLS negotiation, subsequent data is encrypted... 856 M: EHLO potter.example.org 857 S: 250-owlry.example.com 858 S: 250-8BITMIME 859 S: 250-BINARYMIME 860 S: 250-PIPELINING 861 S: 250-BURL 862 S: 250-CHUNKING 863 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL 864 S: 250-DSN 865 S: 250-SIZE 10240000 866 S: 250 ENHANCEDSTATUSCODES 867 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 868 S: 235 2.7.0 PLAIN authentication successful. 869 M: EHLO potter.example.org 870 S: 250-owlry.example.com 871 S: 250-8BITMIME 872 S: 250-BINARYMIME 873 S: 250-PIPELINING 874 S: 250-BURL imap imap://imap.example.org 875 S: 250-CHUNKING 876 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL 877 S: 250-DSN 878 S: 250-SIZE 10240000 879 S: 250 ENHANCEDSTATUSCODES 880 M: MAIL FROM: BODY=BINARY 881 S: 250 2.5.0 Address Ok. 882 M: RCPT TO: 883 S: 250 2.1.5 foo@example.net OK. 884 M: BDAT 475 885 M: Message-ID: <419399E1.6000505@caernarfon.example.org> 886 M: Date: Thu, 12 Nov 2004 16:57:05 +0000 887 M: From: Bob Ar 888 M: MIME-Version: 1.0 889 M: To: foo@example.net 890 M: Subject: About our holiday trip 891 M: Content-Type: multipart/mixed; 892 M: boundary="------------030308070208000400050907" 893 M: 894 M: --------------030308070208000400050907 895 M: Content-Type: text/plain; format=flowed 896 M: 897 M: Our travel agent has sent the updated schedule. 898 M: 899 M: Cheers, 900 M: Bob 901 M: --------------030308070208000400050907 902 S: 250 2.5.0 OK 903 M: BURL imap://bob.ar@example.org/INBOX; 904 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 905 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 906 internal:A0DEAD473744909de610943775f9BEEF 907 S: 250 2.5.0 OK 908 M: BURL imap://bob.ar@example.org/INBOX; 909 UIDVALIDITY=385759045/;UID=25627/;Section=2; 910 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 911 internal:BEEFA0DEAD473744909de610943775f9 912 S: 250 2.5.0 OK 913 M: BDAT 44 LAST 914 M: 915 M: --------------030308070208000400050907-- 917 S: {to I} The mail submission server uses URLFETCH to fetch the 918 pieces of the message to be sent (See [SMTP-BURL] for details of the 919 semantics and steps. The so-called "pawn-ticket" authorization 920 mechanism uses a URI which contains its own authorization 921 credentials.). 922 I: {to S} Returns the requested body parts. 924 Mail submission server opens IMAP connection to the IMAP server: 926 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ 927 CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com 928 IMAP server ready 929 S: a001 LOGIN submitserver secret 930 I: a001 OK submitserver logged in 931 S: a002 URLFETCH "imap://bob.ar@example.org/INBOX; 932 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 933 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 934 internal:A0DEAD473744909de610943775f9BEEF" "imap:// 935 bob.ar@example.org/INBOX; 936 UIDVALIDITY=385759045/;UID=25627/;Section=2; 937 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 938 internal:BEEFA0DEAD473744909de610943775f9" 939 I: * URLFETCH "imap://bob.ar@example.org/INBOX; 940 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 941 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 942 internal:A0DEAD473744909de610943775f9BEEF" {84} 943 ...message section follows... 944 "imap://bob.ar@example.org/INBOX; 945 UIDVALIDITY=385759045/;UID=25627/;Section=2; 946 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 947 internal:BEEFA0DEAD473744909de610943775f9" {15065} 948 ...message section follows... 949 S: a002 OK URLFETCH completed 950 I: a003 LOGOUT 951 S: * BYE See you later 952 S: a003 OK Logout successful 954 Note that if the IMAP server doesn't send CAPABILITY response code in 955 the greeting, the mail submission server must issue the CAPABILITY 956 command to learn about supported IMAP extensions as described in 958 [IMAP]. 960 Also, if data confidentiality is required the mail submission server 961 should start TLS before issuing the LOGIN command. 963 S: {to M} Submission server assembles the complete message and if the 964 assembly succeeds it acknowledges acceptance of the message by 965 sending 250 response to the last BDAT command: 967 S: 250 2.5.0 Ok, message accepted. 969 M: {to I} The client marks the message containing the forwarded 970 attachment on the IMAP server. 972 M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) 973 I: * 215 FETCH (UID 25627 MODSEQ (12121231000)) 974 I: A0053 OK STORE completed 976 Note: the UID STORE command shown above will only work if the marked 977 message is in the currently selected mailbox; otherwise, it requires 978 a SELECT. As in the previous example, this command is not critical, 979 and can be omitted. The untagged FETCH response is due to 980 [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in 981 Section 5.9. 983 7.5. Security Considerations for pawn-tickets. 985 The so-called "pawn-ticket" authorization mechanism uses a URI, which 986 contains its own authorization credentials using [IMAP-URLAUTH]. The 987 advantage of this mechanism is that the SMTP submit [SUBMIT] server 988 cannot access any data on the [IMAP-URLAUTH] server without a "pawn- 989 ticket" created by the client. 991 The "pawn-ticket" grants access only to the specific data that the 992 SMTP submit [SUBMIT] server is authorized to access, can be revoked 993 by the client, and can have a time-limited validity. 995 7.6. Copies of Sent messages: The fcc problem 997 The "fcc problem" refers to delivering a copy of a message to a 998 mailbox, or "file carbon copy". By far, the most common case of fcc 999 is a client leaving a copy of outgoing mail in a "Sent Mail" or 1000 "Outbox" mailbox. 1002 In the traditional strategy, the MUA duplicates the effort spent in 1003 transmitting to the MSA by writing the message to the fcc destination 1004 in a separate step. This may be a write to a local disk file or an 1005 APPEND to a mailbox on an IMAP server. The latter is one of the 1006 "repetitive network data transmissions" which represents the 1007 "problem" aspect of the "fcc problem". 1009 The BURL [SMTP-BURL] extension can be used to eliminate the 1010 additional transmission. The final message is uploaded to the 1011 mailbox designed for outgoing mail, by the APPEND command of [IMAP]. 1012 Note that APPEND, including when enhanced by [IMAP-CATENATE], can 1013 only create a single copy of the message and this is only of use on 1014 the server which stages the outgoing message for submission. 1015 Additional copies of the message on the same server can be created by 1016 using one or more COPY commands. 1018 8. OMA MEM Requirement document 1020 The OMA MEM activity has collected a set of use cases and derived 1021 requirements for a mobile email enabler (MEM). The resulting work is 1022 summarized in OMA MEM Requirement document [MEM-req]. Some 1023 requirements relate to email protocols, some involve other OMA 1024 technologies outside the scope of IETF and some relate to 1025 implementations and normative interoperability statements for clients 1026 and servers. 1028 8.1. OMA MEM Architecture 1030 The OMA MEM activity has derived a logical architecture from the 1031 requirements and use cases described in [MEM-req]. The logical 1032 architecture, its elements and interfaces and the notations that it 1033 uses can be found in [MEM-arch]. 1035 8.2. OMA MEM Deployment Issues 1037 The OMA MEM Architecture document [MEM-arch] further identifies 1038 deployment models. 1040 Certain of these deployment models are not what IETF has 1041 conventionally modeled. They require special attention to end-to-end 1042 security aspects and may warrant introduction of additional security 1043 measures (e.g. object level encryption). 1045 8.3. OMA MEM proxy 1047 The OMA MEM Architecture document [MEM-arch] identifies OMA MEM 1048 server proxies as server components that may be deployed. 1050 Both IMAP and SMTP generally are compatible with proxies between the 1051 client and the server. Such proxies may disrupt end-to-end 1052 encryption, with the transport-level encryption ending at the proxy 1053 and re-generating from the proxy to the server. Again this may 1054 require additional security measures like object level encryption, 1055 and this mode of operation is not recommended. 1057 8.4. IETF Lemonade Architecture 1059 This section gives a brief introduction to the Lemonade Architecture. 1061 The IETF Lemonade activity has derived a profile with the logical 1062 architecture represented in Figure 15, where arrows indicate content 1063 flows. 1065 ______________ 1066 | | 1067 _________| Notification | 1068 | | Mechanism | 1069 | |______________| 1070 |Notif. ^ 1071 |Protocol | 1072 | ___|______ 1073 | | | _____ 1074 __v__ IMAP | Lemonade | ESMTP | | 1075 | |<----------->| IMAP |<---------------| MTA | 1076 | MUA |- | Store | |_____| 1077 |_____| \ |__________| 1078 \ | 1079 \ |URLAUTH 1080 \SUBMIT | 1081 \ ____v_____ 1082 \ | | _____ 1083 \ | Lemonade | ESMTP | | 1084 ---->| Submit |--------------->| MTA | 1085 | Server | |_____| 1086 |__________| 1088 Figure 15: Lemonade logical architecture 1090 The Lemonade profile assumes: <> 1092 o IMAP protocol [IMAP] including Lemonade profile extensions 1093 o Submit protocol ([SUBMIT], profile of [ESMTP]) including Lemonade 1094 profile extensions 1095 o Lemonade profile compliant IMAP store connected to MTA (Mail 1096 Transfer Agent) via ESMTP [ESMTP]. 1097 o Lemonade profile compliant Submit server connected to MTA via 1098 ESMTP 1100 o Lemonade profile message store / Submit server protocols (URLAUTH) 1101 (see [IMAP-URLAUTH]). 1102 o Outband server to client notifications relying on external 1103 notification mechanisms (and notification protocols) that may be 1104 out of scope of the Lemonade profile. 1105 o A Lemonade aware MUA (Mail User Agent). While use of outband 1106 notification is described in the Lemonade profile, support for the 1107 underlying notifications mechanisms/protocols is out of scope of 1108 the Lemonade specifications. 1110 Note that in Figure 15 the IMAP server and Submit server are 1111 represented connected to MTAs (Mail Transfer Agents) via [ESMTP]. 1112 This is not really essential. It could as well be X.400 so long as 1113 the message in the store is in the internet form. 1115 OMA MEM identifies other functionalities. These are considered as 1116 out of scope of the Lemonade work and will need to be specified by 1117 OMA MEM. 1119 8.5. Lemonade profile logical architecture 1121 This section details the Lemonade profile logical architecture. This 1122 architecture is also expected to support the OMA MEM logical 1123 Architecture. 1125 8.5.1. Relationship between the OMA MEM and Lemonade logical 1126 architectures 1128 Figure 16 illustrates the mapping of the IETF Lemonade logical 1129 architecture on the OMA MEM logical architecture. 1131 _____________________ 1132 | Other_Mob. Enablers | 1133 | |--------------| | 1134 _________| Notification | | 1135 | | | Mechanism | | 1136 | | |______________| | 1137 |Notif. |____________^________| 1138 |Protocol ______|__________ 1139 ME-4 | | ___|_ME-3_ | 1140 ___|____ | | | | _____ 1141 | __v__ | IMAP | | Lemonade | | ESMTP | | 1142 || |<----------->| IMAP |<-----------| MTA | 1143 || MUA || ME-2a | | Store | | |_____| 1144 ||_____||\ME-1 | |__________| | 1145 | MEM | \ | | | 1146 | Client| \ | |URLAUTH | 1147 |_______| \SUBMIT | | 1148 \ | ____v_____ | 1149 \ | | | | _____ 1150 \ | | Lemonade | | ESMTP | | 1151 ---->| Submit |----------->| MTA | 1152 ME-2b | | Server | | |_____| 1153 | |__________| | 1154 |MEM Email | 1155 |Server Server| 1156 |_________________| 1157 ^ 1158 |ME-5 1159 | 1161 Figure 16: Mapping of Lemonade profile logical architecture onto 1162 the OMA MEM logical architecture. 1164 As described in Section 8.4, the Lemonade profile assumes Lemonade 1165 profile compliant IMAP stores and Submit servers. Because the 1166 Lemonade profile extends the IMAP store and the submit server, the 1167 mobile enablement of email provided by the Lemonade profile is 1168 directly provided in these server. Mapped to OMA MEM logical 1169 architecture, for the case considered and specified by the Lemonade 1170 profile, the MEM server and email server logically combined. They 1171 are however split into distinct Lemonade message store and Lemonade 1172 submit server. The OMA MEM interfaces ME-2 ([MEM-arch]) consists of 1173 two interfaces ME-2a and ME-2b associated respectively to IMAP 1174 extended according to the Lemonade profile and SUBMIT extended 1175 according to the Lemonade profile. 1177 The MUA is part of the MEM client. 1179 External notifications mechanism can be part of the other OMA enabler 1180 specified by OMA (or other activities). 1182 8.5.2. Lemonade realization of OMA MEM with non-Lemonade compliant 1183 servers 1185 The OMA MEM activity is not limited to enabling Lemonade compliant 1186 servers. It explicitly identifies the need to support other 1187 backends. 1189 8.5.2.1. Lemonade realization of OMA MEM with non-Lemonade enhanced 1190 IMAP servers 1192 Figure 17 illustrates the case of IMAP servers that are not (yet) 1193 Lemonade compliant / enhanced with Lemonade. In such case, the I2 1194 interface between the MEM server components and the IMAP store and 1195 submit server are IMAP and SUBMIT. 1197 ______________ 1198 | | 1199 _________| Notification | 1200 | | Mechanism | 1201 | |______________| 1202 |Notif. ^ 1203 |Protocol | 1204 | ___|______ _____________ 1205 | | Lemonade | | | _____ 1206 __v__ IMAP | MEM | IMAP |NON-Lemonade | ESMTP | | 1207 | |<--------->|Enabler |<------>|IMAP |<----->| MTA | 1208 | MUA |\ ME-2a | Server | |Store | |_____| 1209 |_____| \ |__________| |_____________| 1210 \ | 1211 \ |URLAUTH 1212 \SUBMIT | 1213 \ ____v_____ _____________ 1214 \ | | | | _____ 1215 \ | Lemonade | SUBMIT |NON-Lemonade | ESMTP | | 1216 -->| MEM | |Submit | | | 1217 | Enabler |------->|Server |------>| MTA | 1218 ME-2b | Server | | | |_____| 1219 |__________| |_____________| 1221 Figure 17: Architecture to support non-Lemonade enhanced IMAP 1222 servers with a Lemonade realization of OMA MEM enabler. 1224 In Figure 17, the server may be a separate proxy. 1226 8.5.2.2. Lemonade realization of OMA MEM with non-IMAP servers 1228 < 1231 Figure 18 illustrates the cases where the message store and submit 1232 servers are not IMAP store or submit servers. They may be POP3 1233 servers or other proprietary message stores. 1235 ______________ 1236 | | 1237 _________| Notification | 1238 | | Mechanism | 1239 | |______________| 1240 |Notif. ^ 1241 |Protocol | 1242 | ___|______ _____________ 1243 | | Lemonade | | | _____ 1244 __v__ IMAP | MEM | I2 |Proprietary | ESMTP | | 1245 | |<--------->|Enabler |<------>|Message |<----->| MTA | 1246 | MUA |\ ME-2a | Server | |Store | |_____| 1247 |_____| \ |__________| |_____________| 1248 \ | 1249 \ |URLAUTH 1250 \SUBMIT | 1251 \ ____v_____ _____________ 1252 \ | | | | _____ 1253 \ | Lemonade | I2 |Proprietary | ESMTP | | 1254 -->| MEM | |Submit | | | 1255 | Enabler |------->|Server |------>| MTA | 1256 ME-2b | Server | | | |_____| 1257 |__________| |_____________| 1259 Figure 18: Architecture to support non-IMAP servers with a Lemonade 1260 realization of OMA MEM enabler. 1262 I2 designates proprietary adapters to the backends. They may 1263 involved functions performed in the message stores or submit server 1264 as well as in the MEM enabler server. 1266 In Figure 18, the server may be a separate proxy. 1268 8.6. Filters and server to client notifications and Lemonade 1270 OMA MEM RD [MEM-req] and AD [MEM-arch] emphasize the need to provide 1271 mechanisms for server to client notifications of email events and 1272 filtering. Figure 19 illustrates how notification and filterings are 1273 introduced in Lemonade profile. 1275 ______________ 1276 | | 1277 _________| Notification | 1278 | | Mechanism | 1279 | |______________| 1280 |Notif. ^ 1281 |Protocol -------\ _|_ 1282 | ______| ___\>|NF|____ 1283 | | | ---- | _____ 1284 __v__| IMAP |__ Lemonade |___ ESMTP __| | 1285 | |<-------->|VF| IMAP |DF |<--------|AF| MTA | 1286 | MUA |\ ME-2a |-- Store |--- --|_____| 1287 |_____| \ |_____________| ^ 1288 \_\_______________|_______| 1289 \ |URLAUTH 1290 \SUBMIT | 1291 \ ____v_____ 1292 \ | | _____ 1293 \ | Lemonade | ESMTP | | 1294 ---->| Submit |--------------->| MTA | 1295 ME-2b | Server | |_____| 1296 |__________| 1298 Figure 19: Filtering mechanism defined in Lemonade architecture 1300 In Figure 19, four categories of filters are defined: 1301 o AF: Administrative Filters - Set up by email service provider. AF 1302 are typically not configured by the user and set to apply policies 1303 content filtering, virus protection, spam filtering etc... 1304 o DF: Deposit Filters - Filters that are executed on deposit of new 1305 email messages. They can be defined as [SIEVE]. They can include 1306 vacation notices. 1307 o VF: View Filters - Filters that define which emails are visible to 1308 the MUA. View filters can be performed via IMAP using the 1309 facilities described in Section 5.5. 1310 o NF: Notification Filters - Filters that define for what email 1311 server events a notification is sent to the client, as described 1312 in Section 5.4. 1314 The filters are manageable from the MUA: 1315 o NF and DF: via SIEVE Management protocol [MANAGESIEVE] 1316 o VF: via extended IMAP SEARCH commands discussed in Section 5.5. 1318 9. Deployment Considerations 1320 Deployment considerations are discussed extensively in 1321 [LEMONADE-DEPLOYMENTS]. 1323 10. Security Considerations 1325 Implementors are advised to examine the Security Considerations of 1326 all the referenced documents. This section merely highlights these, 1327 and advises implementors on specific issues relating to the 1328 combination of extensions. 1330 Security considerations on Lemonade "forward without download" are 1331 discussed throughout Section 7. Additional security considerations 1332 can be found in [IMAP] and other documents describing other SMTP and 1333 IMAP extensions comprising the Lemonade Profile. 1335 Note that the mandatory-to-implement authentication mechanism for 1336 SMTP submission is described in [SMTP-AUTH]. The mandatory-to- 1337 implement authentication mechanism for IMAP is described in [IMAP]. 1339 10.1. Confidentiality Protection of Submitted Messages 1341 When clients submit new messages, link protection such as TLS guards 1342 against an eavesdropper seeing the contents of the submitted message. 1343 It is worth noting, however, that even if TLS is not used, the 1344 security risks are no worse if BURL is used to reference the text 1345 than if the text is submitted directly. If BURL is not used, an 1346 eavesdropper gains access to the full text of the message. If BURL 1347 is used, the eavesdropper may or may not be able to gain such access, 1348 depending on the form of BURL used. For example, some forms restrict 1349 use of the URL to an entity authorized as a submission server or a 1350 specific user. 1352 10.2. TLS 1354 When Lemonade clients use the BURL extension to mail submission, an 1355 extension that requires sending a URLAUTH token to the mail 1356 submission server, such a token should be protected from interception 1357 to avoid a replay attack that may disclose the contents of the 1358 message to an attacker. TLS based encryption of the mail submission 1359 path will provide protection against this attack. 1361 Lemonade clients SHOULD use TLS-protected IMAP and mail submission 1362 channels when using BURL-based message submission to protect the 1363 URLAUTH token from interception. 1365 Lemonade compliant mail submission servers SHOULD use TLS-protected 1366 IMAP connections when fetching message content using the URLAUTH 1367 token provided by the Lemonade client. 1369 When a client uses SMTP STARTTLS to send a BURL command which 1370 references non-public information, there is a user expectation that 1371 the entire message content will be treated confidentially. To meet 1372 this expectation, the message submission server should use STARTTLS 1373 or a mechanism providing equivalent data confidentiality when 1374 fetching the content referenced by that URL. 1376 10.3. Additional extensions and deployment models 1378 This specification provides no additional security measures beyond 1379 those in the referenced Internet Mail and Lemonade documents. 1381 We note however the security risks associated to: 1382 o Outband notifications 1383 o Server configuration by client 1384 o Client configuration by server 1385 o Presence of proxy servers 1386 o Presence of servers as intermediaries 1387 o In general the deployment models considered by OMA MEM that are 1388 not conventional IETF deployment models. 1389 o Measures to address a perceived need to traverse firewalls and 1390 mobile network intermediaries. 1392 11. IANA considerations 1394 This document does not require any IANA registration or action that 1395 are not covered by the different drafts and RFCs included in the 1396 realization described in this document. 1398 12. Version history 1400 o Version 04: 1401 * Major reorganization of text. 1402 * Move checklist summary to beginning of document, collate 1403 Submission and Store server requirements. 1404 o Version 03: 1405 * Replaced RECONNECT (server side quick reconned) with QRESYNC 1406 (client side quick reconnect) 1408 * Added WITHIN and LIST-EXTENDED. 1409 * Moved IDLE extension to a separate section. 1410 * Added requirement for clients to use Format=flowed. 1411 o Version 02: 1412 * Update of references and how they are displayed in the text 1413 (Comments from Randy Gellens) 1414 * Update of list of extensions to support as MUST by the Lemonade 1415 Profile Bis 1416 * Update of options for compression via placeholder imap- 1417 compression section describing compression requirements 1418 * Update of support of TCP chalenged environments 1419 * Update of support of object level encryption 1420 * Clarified the use of $Forwarded in the examples, and 1421 demonstrated how to remove the \Draft flag from the sent 1422 message 1423 * Clarified $Forwarded 1424 * Added RECONNECT to imap-condstore section 1425 * Add new section imap-bodypart, "Message part handling", 1426 describing BINARY and CONVERT requirements 1427 * Added placeholder section for notifications 1428 * Added various extensions to imap-other section, and added 1429 clarifying comments to IDLE, NAMESPACE, and a further 1430 references to TLS DEFLATE compression 1431 * Added extension names to IMAP table 1432 * Fixed all issues found with original Lemonade profile so far. 1433 o Version 01: 1434 * Lemonade profile has been introduced in-line, with some updates 1435 / corrections. 1436 * Subsequent re-organization of the text 1437 * Details of extensions proper to Lemonade Profile-bis have been 1438 updated to refer to the drafts newly accepted as WG IETF 1439 drafts. 1440 * Addition of appendix on attachements streaming. 1441 o Version 00: 1442 * It evolved from a combination of the content of Lemonade 1443 profile and the OMA MEM realization internet draft. 1445 13. Acknowledgements 1447 The editors acknowledge and appreciate the work and comments of the 1448 IETF Lemonade working group and the OMA MEM working group. 1450 In particular, the editors would like to thank Eric Burger, Randall 1451 Gellens, Zoltan Ordogh, Greg Vaudreuil, and Fan Xiaohui for their 1452 comments and reviews. 1454 14. References 1456 14.1. Normative References 1458 [FLOWED] Gellens, R., "The Text/Plain Format and DelSp Parameters", 1459 RFC 3676, February 2004. 1461 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1462 4rev1", RFC 3501, March 2003. 1464 [IMAP-BINARY] 1465 Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, 1466 April 2003. 1468 [IMAP-CATENATE] 1469 Resnick, P., "Internet Message Access Protocol (IMAP) 1470 CATENATE Extension", RFC 4469, April 2006. 1472 [IMAP-COMPRESS] 1473 Gulbrandsen, A., "The IMAP COMPRESS Extension", 1474 draft-ietf-lemonade-compress-07 (work in progress), 1475 January 2007. 1477 [IMAP-CONDSTORE] 1478 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1479 STORE Operation or Quick Flag Changes Resynchronization", 1480 RFC 4551, June 2006. 1482 [IMAP-CONTEXT] 1483 Cridland, D. and C. King, "Contexts for IMAP4", 1484 draft-cridland-imap-context-00 (work in progress), 1485 October 2006. 1487 [IMAP-CONVERT] 1488 Maes, S. and R. Cromwell, "CONVERT", 1489 draft-ietf-lemonade-convert-05 (work in progress), 1490 October 2006. 1492 [IMAP-ESEARCH] 1493 Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH 1494 Command for Controlling What Kind of Information Is 1495 Returned", RFC 4731, November 2006. 1497 [IMAP-IDLE] 1498 Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 1500 [IMAP-LISTEXT] 1501 Leiba, B. and A. Melnikov, "IMAP4 LIST Command 1502 Extensions", draft-ietf-imapext-list-extensions-18 (work 1503 in progress), September 2006. 1505 [IMAP-LITERAL+] 1506 Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 1507 January 1997. 1509 [IMAP-METADATA] 1510 Daboo, C., "IMAP METADATA Extension", 1511 draft-daboo-imap-annotatemore-11 (work in progress), 1512 February 2007. 1514 [IMAP-NAMESPACE] 1515 Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 1516 May 1998. 1518 [IMAP-NOTIFY] 1519 King, C., "The IMAP NOTIFY Extension", 1520 draft-gulbrandsen-imap-notify-03 (work in progress), 1521 March 2007. 1523 [IMAP-QRESYNC] 1524 Melnikov, A., "IMAP4 Extensions for Quick Mailbox 1525 Resynchronization", 1526 draft-ietf-lemonade-reconnect-client-03 (work in 1527 progress), February 2007. 1529 [IMAP-UIDPLUS] 1530 Crispin, M., "Internet Message Access Protocol (IMAP) - 1531 UIDPLUS extension", RFC 4315, December 2005. 1533 [IMAP-URLAUTH] 1534 Crispin, M., "Internet Message Access Protocol (IMAP) - 1535 URLAUTH Extension", RFC 4467, May 2006. 1537 [IMAP-WITHIN] 1538 Maes, S., "WITHIN Search extension to the IMAP Protocol", 1539 draft-ietf-lemonade-search-within-04 (work in progress), 1540 March 2007. 1542 [KEYWORDS] 1543 Bradner, S., "Key words for use in RFCs to Indicate 1544 Requirement Levels", BCP 14, RFC 2119, March 1997. 1546 [SMTP-8BITMIME] 1547 Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 1548 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 1549 RFC 1652, July 1994. 1551 [SMTP-AUTH] 1552 Myers, J., "SMTP Service Extension for Authentication", 1553 RFC 2554, March 1999. 1555 [SMTP-BINARYMIME] 1556 Vaudreuil, G., "SMTP Service Extensions for Transmission 1557 of Large and Binary MIME Messages", RFC 3030, 1558 December 2000. 1560 [SMTP-BURL] 1561 Newman, C., "Message Submission BURL Extension", RFC 4468, 1562 May 2006. 1564 [SMTP-DSN] 1565 Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1566 Extension for Delivery Status Notifications (DSNs)", 1567 RFC 3461, January 2003. 1569 [SMTP-PIPELINING] 1570 Freed, N., "SMTP Service Extension for Command 1571 Pipelining", RFC 2197, September 1997. 1573 [SMTP-SIZE] 1574 Klensin, J., Freed, N., and K. Moore, "SMTP Service 1575 Extension for Message Size Declaration", STD 10, RFC 1870, 1576 November 1995. 1578 [SMTP-STATUSCODES] 1579 Freed, N., "SMTP Service Extension for Returning Enhanced 1580 Error Codes", RFC 2034, October 1996. 1582 [SMTP-TLS] 1583 Hoffman, P., "SMTP Service Extension for Secure SMTP over 1584 Transport Layer Security", RFC 3207, February 2002. 1586 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", 1587 RFC 4409, April 2006. 1589 [TLS-COMP] 1590 Hollenbeck, S., "Transport Layer Security Protocol 1591 Compression Methods", RFC 3749, May 2004. 1593 14.2. Informative References 1595 [ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1596 April 2001. 1598 [IMAP-SYNC-HOWTO] 1599 Melnikov, A., "Synchronization Operations for Disconnected 1600 IMAP4 Clients", RFC 4549, June 2006. 1602 [LEMONADE-DEPLOYMENTS] 1603 Gellens, R., "Deployment Considerations for lemonade- 1604 compliant Mobile Email", 1605 draft-ietf-lemonade-deployments-06 (work in progress), 1606 March 2007. 1608 [MANAGESIEVE] 1609 Martin, T. and A. Melnikov, "A Protocol for Remotely 1610 Managing Sieve Scripts", draft-martin-managesieve-07 (work 1611 in progress), November 2006. 1613 [MEM-arch] 1614 Open Mobile Alliance, "Mobile Email Architecture 1615 Document", OMA (Work in Progress), 1616 http://www.openmobilealliance.org/, October 2005. 1618 [MEM-req] Open Mobile Alliance, "Mobile Email Requirements 1619 Document", OMA http://www.openmobilealliance.org/ 1620 release_program/docs/RD/ 1621 OMA-RD-MobileEmail-V1_0_20051018-C.pdf, Oct 2005. 1623 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 1624 Language", draft-ietf-sieve-3028bis-12 (work in progress), 1625 February 2007. 1627 Authors' Addresses 1629 Dave Cridland (editor) 1630 Isode Limited 1631 5 Castle Business Village 1632 36 Station Road 1633 Hampton, Middlesex TW12 2BX 1634 UK 1636 Email: dave.cridland@isode.com 1637 Alexey Melnikov (editor) 1638 Isode Limited 1639 5 Castle Business Village 1640 36 Station Road 1641 Hampton, Middlesex TW12 2BX 1642 UK 1644 Email: Alexey.Melnikov@isode.com 1646 Stephane H. Maes (editor) 1647 Oracle 1648 MS 4op634, 500 Oracle Parkway 1649 Redwood Shores, CA 94539 1650 USA 1652 Phone: +1-203-300-7786 1653 Email: stephane.maes@oracle.com 1655 Full Copyright Statement 1657 Copyright (C) The IETF Trust (2007). 1659 This document is subject to the rights, licenses and restrictions 1660 contained in BCP 78, and except as set forth therein, the authors 1661 retain all their rights. 1663 This document and the information contained herein are provided on an 1664 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1665 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1666 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1667 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1668 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1669 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1671 Intellectual Property 1673 The IETF takes no position regarding the validity or scope of any 1674 Intellectual Property Rights or other rights that might be claimed to 1675 pertain to the implementation or use of the technology described in 1676 this document or the extent to which any license under such rights 1677 might or might not be available; nor does it represent that it has 1678 made any independent effort to identify any such rights. Information 1679 on the procedures with respect to rights in RFC documents can be 1680 found in BCP 78 and BCP 79. 1682 Copies of IPR disclosures made to the IETF Secretariat and any 1683 assurances of licenses to be made available, or the result of an 1684 attempt made to obtain a general license or permission for the use of 1685 such proprietary rights by implementers or users of this 1686 specification can be obtained from the IETF on-line IPR repository at 1687 http://www.ietf.org/ipr. 1689 The IETF invites any interested party to bring to its attention any 1690 copyrights, patents or patent applications, or other proprietary 1691 rights that may cover technology that may be required to implement 1692 this standard. Please address the information to the IETF at 1693 ietf-ipr@ietf.org. 1695 Acknowledgment 1697 Funding for the RFC Editor function is provided by the IETF 1698 Administrative Support Activity (IASA).