idnits 2.17.1 draft-ietf-lemonade-profile-bis-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4550, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2009) is 5534 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) ** Obsolete normative reference: RFC 4551 (ref. 'IMAP-CONDSTORE') (Obsoleted by RFC 7162) ** Obsolete normative reference: RFC 1652 (ref. 'SMTP-8BITMIME') (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 4409 (ref. 'SUBMIT') (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 4 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 Obsoletes: 4550 (if approved) Isode Limited 5 Intended status: Standards Track S. Maes, Ed. 6 Expires: August 27, 2009 Oracle 7 February 23, 2009 9 The Lemonade Profile 10 draft-ietf-lemonade-profile-bis-12.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 27, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 Abstract 61 This document describes a profile (a set of required extensions, 62 restrictions and usage modes), dubbed Lemonade, of the IMAP, mail 63 submission and Sieve protocols. This profile allows clients 64 (especially those that are constrained in memory, bandwidth, 65 processing power, or other areas) to efficiently use IMAP and 66 Submission to access and submit mail. This includes the ability to 67 forward received mail without needing to download and upload the 68 mail, to optimize submission and to efficiently resynchronize in case 69 of loss of connectivity with the server. 71 The Lemonade profile relies upon several extensions to IMAP and Mail 72 Submission protocols. 74 Table of Contents 76 1. Conventions used in this document . . . . . . . . . . . . . . 4 77 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Summary of the required support . . . . . . . . . . . . . . . 6 79 3.1. Lemonade Submission Servers . . . . . . . . . . . . . . . 6 80 3.2. Lemonade Message Stores . . . . . . . . . . . . . . . . . 7 81 3.3. Lemonade Message Delivery Agents . . . . . . . . . . . . . 8 82 4. Lemonade Submission Servers . . . . . . . . . . . . . . . . . 9 83 4.1. Forward Without Download . . . . . . . . . . . . . . . . . 9 84 4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.3. DSN Support . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.4. Message size declaration . . . . . . . . . . . . . . . . . 9 87 4.5. Enhanced status code Support . . . . . . . . . . . . . . . 10 88 4.6. Encryption and Compression . . . . . . . . . . . . . . . . 10 89 5. Lemonade Message Stores . . . . . . . . . . . . . . . . . . . 11 90 5.1. Quick resynchronization . . . . . . . . . . . . . . . . . 11 91 5.2. Message part handling . . . . . . . . . . . . . . . . . . 11 92 5.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 12 93 5.4. Notifications . . . . . . . . . . . . . . . . . . . . . . 12 94 5.4.1. IMAP Notifications . . . . . . . . . . . . . . . . . . 12 95 5.4.2. External Notifications . . . . . . . . . . . . . . . . 13 96 5.5. Searching and View Filters . . . . . . . . . . . . . . . . 13 97 5.6. Mailbox Handling . . . . . . . . . . . . . . . . . . . . . 14 98 5.7. Forward Without Download . . . . . . . . . . . . . . . . . 14 99 5.7.1. Support for PARTIAL in CATENATE and URLAUTH . . . . . 14 100 5.8. Additional IMAP extensions . . . . . . . . . . . . . . . . 14 101 5.9. Registration of $Forwarded IMAP keyword . . . . . . . . . 15 102 5.10. Registration of $SubmitPending and $Submitted IMAP 103 keywords . . . . . . . . . . . . . . . . . . . . . . . . . 15 104 5.11. Related IMAP extensions . . . . . . . . . . . . . . . . . 15 105 6. Lemonade Message Delivery Agents . . . . . . . . . . . . . . . 16 106 7. Lemonade Mail User Agents . . . . . . . . . . . . . . . . . . 17 107 8. Forward without download . . . . . . . . . . . . . . . . . . . 17 108 8.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 17 109 8.2. Message Sending Overview . . . . . . . . . . . . . . . . . 18 110 8.3. Traditional Strategy . . . . . . . . . . . . . . . . . . . 18 111 8.4. A new strategy . . . . . . . . . . . . . . . . . . . . . . 19 112 8.4.1. Message assembly using IMAP CATENATE extension . . . . 20 113 8.4.2. Message assembly using SMTP CHUNKING and BURL 114 extensions . . . . . . . . . . . . . . . . . . . . . . 24 115 8.5. Security Considerations for pawn-tickets. . . . . . . . . 28 116 8.6. Copies of Sent messages: The fcc problem . . . . . . . . . 28 117 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 29 118 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 119 10.1. Confidentiality Protection of Submitted Messages . . . . . 29 120 10.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 121 10.3. Additional extensions and deployment models . . . . . . . 30 122 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30 123 12. Version history . . . . . . . . . . . . . . . . . . . . . . . 31 124 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 125 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 126 14.1. Normative References . . . . . . . . . . . . . . . . . . . 32 127 14.2. Informative References . . . . . . . . . . . . . . . . . . 36 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 130 1. Conventions used in this document 132 In examples, "M:", "I:" and "S:" indicate lines sent by the client 133 messaging user agent, IMAP e-mail server and SMTP submit server 134 respectively. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [KEYWORDS]. 140 Other capitalised words are typically names of extensions or commands 141 - these are uppercased for clarity only, and are case-insensitive. 143 All examples in this document are optimized for Lemonade use and 144 might not represent examples of proper protocol usage for a general 145 use Submit/IMAP client. In particular, examples assume that Submit 146 and IMAP servers support all Lemonade extensions described in this 147 document, so they do not demonstrate fallbacks in the absence of an 148 extension. 150 2. Introduction 152 The Lemonade Profile, or simply Lemonade, provides enhancements to 153 Internet email to support diverse service environments. Lemonade 154 Mail Servers provide both a Lemonade Submission Server and a Lemonade 155 Message Store, which are based on the existing [SUBMIT] and [IMAP] 156 protocols respectively. They MAY also include a Lemonade Message 157 Delivery Agent, which provides delivery-time filtering services based 158 on [SIEVE]. 160 This document describes the Lemonade profile that includes: 161 o General common enhancements to Internet Mail, described in 162 Section 5 and Section 4. 163 o "Forward without download" that describes exchanges between 164 Lemonade clients and servers to allow to submit new email messages 165 incorporating content which resides on locations external to the 166 client, described in Section 8. 167 o Quick mailbox resynchronization, described in Section 5.1. 168 o Extensions to support more precise, and broader, notifications 169 from the store in support of notifications and view filters, 170 described in Section 5.4.1 and Section 5.5. 171 o Delivery-time filtering in support of typical mail management use- 172 cases, as described in Section 3.3. 174 The LEMONADE WG used the architecture shown in [LEMONADE-ARCH] to 175 develop the Lemonade Profile. 177 It is intended that the Lemonade profile support realizations of the 178 OMA's mobile email enabler (MEM) (see [OMA-MEM-REQ] and 179 [OMA-MEM-ARCH]) using Internet Mail protocols defined by the IETF. 181 3. Summary of the required support 183 3.1. Lemonade Submission Servers 185 Lemonade Submission Servers MUST provide a service as described in 186 [SUBMIT], and MUST support the following. Note that the Lemonade 187 Profile imposes further requirements for some cases, detailed in the 188 sections cited. 190 +---------------------+--------------------+--------------+ 191 | SMTP extension | Reference | Requirements | 192 +---------------------+--------------------+--------------+ 193 | 8BITMIME | [SMTP-8BITMIME] | [SMTP-BURL] | 194 | AUTH | [SMTP-AUTH] | [SUBMIT] | 195 | BINARYMIME | [SMTP-BINARYMIME] | Section 4.1 | 196 | BURL imap | [SMTP-BURL] | Section 8 | 197 | CHUNKING | [SMTP-BINARYMIME] | Section 4.1 | 198 | DSN | [SMTP-DSN] | Section 4.3 | 199 | ENHANCEDSTATUSCODES | [SMTP-STATUSCODES] | Section 4.5 | 200 | PIPELINING | [SMTP-PIPELINING] | Section 4.2 | 201 | SIZE | [SMTP-SIZE] | Section 4.4 | 202 | STARTTLS | [SMTP-TLS] | Section 4.6 | 203 +---------------------+--------------------+--------------+ 205 3.2. Lemonade Message Stores 207 Lemonade Message Stores MUST provide a service as described in 208 [IMAP], and MUST support the following. Note that the Lemonade 209 Profile imposes further requirements for some cases, detailed in the 210 sections cited. 212 +------------------------+------------------+---------------+ 213 | IMAP extension | Reference | Requirements | 214 +------------------------+------------------+---------------+ 215 | BINARY | [IMAP-BINARY] | Section 5.2 | 216 | CATENATE | [IMAP-CATENATE] | Section 5.7 | 217 | COMPRESS=DEFLATE | [IMAP-COMPRESS] | Section 5.3 | 218 | CONDSTORE | [IMAP-CONDSTORE] | Section 5.1 | 219 | CONTEXT=SEARCH | [IMAP-CONTEXT] | Section 5.5 | 220 | CONTEXT=SORT | [IMAP-CONTEXT] | Section 5.5 | 221 | CONVERT | [IMAP-CONVERT] | Section 5.2 | 222 | ENABLE | [IMAP-ENABLE] | Section 5.1 | 223 | ESEARCH | [IMAP-ESEARCH] | Section 5.5 | 224 | ESORT | [IMAP-CONTEXT] | Section 5.5 | 225 | I18NLEVEL=1 | [IMAP-I18N] | Section 5.8 | 226 | IDLE | [IMAP-IDLE] | Section 5.4.1 | 227 | LITERAL+ | [IMAP-LITERAL+] | Section 5.8 | 228 | NAMESPACE | [IMAP-NAMESPACE] | Section 5.6 | 229 | NOTIFY | [IMAP-NOTIFY] | Section 5.4.1 | 230 | QRESYNC | [IMAP-QRESYNC] | Section 5.1 | 231 | SASL-IR | [IMAP-SASL-IR] | Section 5.8 | 232 | SORT | [IMAP-SORT] | Section 5.5 | 233 | STARTTLS | [IMAP] | - | 234 | UIDPLUS | [IMAP-UIDPLUS] | Section 5.7 | 235 | URLAUTH | [IMAP-URLAUTH] | Section 5.7 | 236 | URL-PARTIAL | Section 5.7.1 | Section 5.7 | 237 | $Forwarded keyword | - | Section 5.9 | 238 | $SubmitPending keyword | - | Section 5.10 | 239 | $Submitted keyword | - | Section 5.10 | 240 +------------------------+------------------+---------------+ 242 In addition to this list, any Lemonade Message Stores MUST send the 243 CAPABILITY response code (see Section 7.1 of [IMAP]) in the initial 244 server greeting and after the LOGIN/AUTHENTICATE commands. 246 3.3. Lemonade Message Delivery Agents 248 Lemonade Message Delivery Agents MUST support Sieve mail filtering 249 language as described in [SIEVE], and MUST support the following 250 Sieve extensions. Note that the Lemonade Profile imposes further 251 requirements for some cases, detailed in the sections cited. 253 +------------------------------+--------------------+--------------+ 254 | Sieve extension | Reference | Requirements | 255 +------------------------------+--------------------+--------------+ 256 | ENOTIFY | [SIEVE-NOTIFY] | Section 6 | 257 | IMAP4FLAGS | [SIEVE-IMAP4FLAGS] | Section 6 | 258 | RELATIONAL | [SIEVE-RELATIONAL] | Section 6 | 259 | VACATION | [SIEVE-VACATION] | Section 6 | 260 | VARIABLES | [SIEVE-VARIABLES] | Section 6 | 261 | comparator-i;unicode-casemap | [UNICODE-CASEMAP] | Section 6 | 262 +------------------------------+--------------------+--------------+ 264 Lemonade Message Delivery Agents should also consider supporting a 265 Sieve script management protocol, such as [MANAGESIEVE]. 267 4. Lemonade Submission Servers 269 All Lemonade Submission Servers implement the Mail Submission 270 protocol described in [SUBMIT], which is in turn a specific profile 271 of [ESMTP]. Therefore any MUA designed to submit email via [SUBMIT] 272 or [ESMTP] will interoperate with Lemonade Submission Servers. 274 In addition, Lemonade Submission Servers implement the following set 275 of SMTP and Submission extensions to increase message submission 276 efficiency. 278 4.1. Forward Without Download 280 In order to optimize network usage for the typical case where message 281 content is copied to, or sourced from, the IMAP store, Lemonade 282 provides support for a suite of extensions collectively known as 283 Forward Without Download, discussed in detail in Section 8. 285 Lemonade Submission Servers MUST support BURL [SMTP-BURL], 8BITMIME 286 [SMTP-8BITMIME], BINARYMIME [SMTP-BINARYMIME] and CHUNKING 287 [SMTP-BINARYMIME] SMTP extensions. 289 BURL MUST support URLAUTH type URLs [IMAP-URLAUTH], and thus MUST 290 advertise the "imap" option following the BURL EHLO keyword (See 291 [SMTP-BURL] for more details). 293 4.2. Pipelining 295 Some clients regularly use networks with a relatively high latency, 296 such as Mobile or Satellite based networks. Avoidance of round-trips 297 within a transaction has a great advantage for the reduction in both 298 bandwidth and total transaction time. For this reason Lemonade 299 compliant mail submission servers MUST support the SMTP Service 300 Extensions for Command Pipelining [SMTP-PIPELINING]. 302 4.3. DSN Support 304 Lemonade compliant mail submission servers MUST support SMTP service 305 extensions for delivery status notifications [SMTP-DSN]. 307 4.4. Message size declaration 309 There is a distinct advantage in detecting failure cases as early as 310 possible in many cases, such as where the user is charged per-octet, 311 or where bandwidth is low. This is especially true of large message 312 sizes. 314 Lemonade Submission Servers MUST support the SMTP Service Extension 315 for Message Size Declaration [SMTP-SIZE]. 317 Lemonade Submission Servers MUST expand all BURL parts before 318 evaluating if the supplied message size is acceptable. 320 A Lemonade capable client SHOULD use message size declaration. In 321 particular the client MUST NOT send a message to a mail submission 322 server, if it knows that the message exceeds the maximal message size 323 advertised by the submission server. When including a message size 324 in the MAIL FROM command, the client MUST use a value that is at 325 least as large as the size of the assembled message data after 326 resolution of all BURL parts. 328 4.5. Enhanced status code Support 330 Lemonade compliant mail submission servers MUST support SMTP Service 331 Extension for Returning Enhanced Error Codes [SMTP-STATUSCODES]. 332 These allow a client to determine the precise cause of failure. 334 4.6. Encryption and Compression 336 Lemonade Compliant mail submission servers MUST support SMTP Service 337 Extension for Secure SMTP over TLS [SMTP-TLS]. 339 Support for the DEFLATE compression method, as described in 340 [TLS-COMP], is RECOMMENDED. 342 5. Lemonade Message Stores 344 All Lemonade Message Stores implement Internet Message Access 345 Protocol, as defined in [IMAP]. Therefore any MUA written to access 346 messages using the facilities described in [IMAP] will interoperate 347 with a Lemonade Message Store. 349 In addition, Lemonade Message Stores provide a set of extensions to 350 address the limitations of some clients and networks. 352 5.1. Quick resynchronization 354 Resynchronization is a costly part of an IMAP session, and mobile 355 networks are generally more prone to unintended disconnection, which 356 in turn makes this problem more acute. Therefore Lemonade Message 357 Stores provide a suite of extensions to reduce the synchronization 358 cost. 360 Lemonade Compliant IMAP servers MUST support the CONDSTORE 361 [IMAP-CONDSTORE], the QRESYNC [IMAP-QRESYNC] and the ENABLE 362 [IMAP-ENABLE] extensions. These allow a client to quickly 363 resynchronize any mailbox by asking the server to return all flag 364 changes and expunges that have occurred since a previously recorded 365 state. This can also speed up client reconnect in case the transport 366 layer is cut, whether accidentally or as part of a change in network. 368 [IMAP-SYNC-HOWTO] details how clients perform efficient mailbox 369 resynchronization. 371 5.2. Message part handling 373 The handling of message parts, especially attachments, represents a 374 set of challenges to limited devices, both in terms of the bandwidth 375 used, and the capability of the device. 377 Lemonade Compliant IMAP servers MUST support the BINARY [IMAP-BINARY] 378 extension. This moves MIME body part decoding operations from the 379 client to the server. The decoded data is equal or less in size than 380 the encoded representation, so this reduces bandwidth effectively. 382 [IMAP-BINARY] allows for servers to refuse to accept uploaded 383 messages containing binary data, by not accepting the Binary content- 384 transfer-encoding; however Lemonade Compliant IMAP servers SHALL 385 always accept binary encoded MIME messages in APPEND commands for any 386 folder. 388 [IMAP-CONVERT] MUST also be supported by servers, which allows 389 clients to request conversions between media types, and allows for 390 scaling images, etc. This provides the ability to view attachments 391 (and sometimes body parts) without the facility to cope with a wide 392 range of media types, or to efficiently view attachments. 394 5.3. Compression 396 Lemonade Message Stores SHOULD support the Deflate compression 397 algorithm for TLS, as defined in [TLS-COMP], in order to facilitate 398 compression at as low a level as possible. 400 However, the working group acknowledges that for many endpoints, this 401 is a rarely deployed technology, and as such, Lemonade Message Stores 402 MUST provide [IMAP-COMPRESS] support for fallback application-level 403 stream compression, where TLS is not actively providing compression. 405 5.4. Notifications 407 The addition of Server-to-client notifications transforms the 408 LEMONADE profile into an event-based synchronization protocol. 409 Whenever an event occurs that interests the MUA, a notification can 410 be generated. The LEMONADE WG used the notifications architecture 411 shown in [LEMONADE-NOTIFICATIONS] to develop the Lemonade Profile. 413 If the MUA is connected to the IMAP server, inband notifications are 414 generated using the facilities outlined in Section 5.4.1. 416 When the MUA is not connected, the Notification filter generates a 417 outband notification. The notification filter may be considered as 418 acting on a push email repository. 420 If the MUA is not connected, and outband notification is disabled, 421 the client must perform a quick-sync on reconnect to determine 422 mailbox changes, using the mechanisms outlined in Section 5.1. 424 5.4.1. IMAP Notifications 426 Lemonade Message Stores MUST support the IDLE [IMAP-IDLE] extension. 427 The extension allows clients to receive unsolicited notifications 428 about changes in the selected mailbox, without needing to poll for 429 changes. The responses forming these notifications MUST be sent in a 430 timely manner when such changes happen. 432 Lemonade Message Stores also provide the NOTIFY extension described 433 in [IMAP-NOTIFY], which allows clients to request specific event 434 types to be sent immediately to the client, both for the currently 435 selected folder and others. Such event types include message 436 delivery, and mailbox renames. 438 5.4.2. External Notifications 440 Lemonade, and TCP, provide for long-lived idle connections between 441 the client and mail store, allowing the server to push notifications 442 within IMAP. Some mobile networks support dormancy, which shuts down 443 the radio traffic channel during idle periods to conserve handset and 444 network resources, while maintaining IP and TCP state. (See the 445 [LEMONADE-DEPLOYMENTS] document for more information.) 447 However, there are environments where the email client cannot remain 448 active indefinitely, or where it is not advisable (or even always 449 possible) for TCP connections to the server to remain up while idle 450 for extended periods. In these situations, a good user experience 451 requires that when "interesting" events occur in the mail store, the 452 client be informed so that it can connect and resynchronize. At an 453 absolute minimum, this requires that at least the arrival of new mail 454 generate some sort of wake-up to the email client. A number of 455 vendors have implemented various solutions to this. As examples of 456 what has been done, for many years (long pre-dating cellular 457 handsets) the technique described in [FINGER-HACK] has been 458 supported. Today, a number of email vendors include facilities to 459 send SMS or other simple non-stream messages to clients on handsets 460 when new mail arrives. OMA has published a mechanism that uses WAP 461 PUSH to send a basic message containing a URL [OMA-EMN]. The IETF is 462 investigating ways to standardize enhanced functionality in this 463 area. 465 A "push email" user experience can be achieved using any number of 466 techniques, ranging from always-on TCP connectivity to the server and 467 the NOTIFY extension described above, to OMA EMN, or even a non- 468 standard trigger message over SMS. In any technique, the client 469 learns of the existence of new mail, and decides to fetch information 470 about it, some part of it, or all of it, and then presents this to 471 the user. 473 5.5. Searching and View Filters 475 Lemonade Message Stores MUST support the ESEARCH [IMAP-ESEARCH] 476 extension. The extension allows clients to efficiently find the 477 first or last messages, find a count of matching messages, and obtain 478 a list of matching messages in a considerably more compact 479 representation. 481 Lemonade Message Stores also provide a mechanism for clients to avoid 482 handling an entire mailbox, instead accessing a view of the mailbox. 483 This technique, common in many desktop clients as a client-side 484 capability, is useful for constrained clients to minimize the 485 quantity of messages and notification data. 487 Lemonade Message Stores therefore MUST implement the CONTEXT=SEARCH, 488 ESORT and CONTEXT=SORT extensions defined in [IMAP-CONTEXT], as well 489 as the SORT extension defined in [IMAP-SORT]. 491 5.6. Mailbox Handling 493 Lemonade Message Stores MUST support the NAMESPACE [IMAP-NAMESPACE] 494 extension. The extension allows clients to discover shared mailboxes 495 and mailboxes belonging to other users, and provide a normalized 496 hierarchy view of the mailboxes available. 498 Lemonade Message Stores MUST support the I18NLEVEL= [IMAP-I18N] 499 extension, with having value 1 or 2. It adds support for non- 500 English (internationalized) search and sort functions. (Note that 501 I18NLEVEL=2 implies support for I18NLEVEL=1, so a Lemonade compliant 502 client that make use of this extension MUST recognize either one.) 504 5.7. Forward Without Download 506 In order to optimize network usage for the typical case where message 507 content is copied to, or sourced from, the IMAP store, Lemonade 508 provides support for a suite of extensions collectively known as 509 Forward Without Download, discussed in detail in Section 8. 511 Lemonade Message Stores MUST support CATENATE [IMAP-CATENATE], 512 UIDPLUS [IMAP-UIDPLUS] and URLAUTH [IMAP-URLAUTH]. Lemonade Message 513 Stores MUST also support URL-PARTIAL as described in Section 5.7.1. 515 5.7.1. Support for PARTIAL in CATENATE and URLAUTH 517 [IMAP-URL] introduced a new syntactic element for referencing a byte 518 range of a message/body part. This is done using the ;PARTIAL= 519 field. If an IMAP server supports PARTIAL in IMAP URL used in 520 CATENATE and URLAUTH extensions, then it MUST advertise the URL- 521 PARTIAL capability in the CAPABILITY response/response code. 523 5.8. Additional IMAP extensions 525 Lemonade Message Stores MUST support the LITERAL+ [IMAP-LITERAL+] 526 extension. The extension allows clients to save a round trip each 527 time a non-synchronizing literal is sent. 529 Lemonade Message Stores MUST also implement the SASL-IR 530 [IMAP-SASL-IR] extension, which allows clients to save a round trip 531 during authentication, potentially pipelining the entire 532 authentication sequence. 534 Lemonade Compliant IMAP servers MUST support IMAP over TLS [IMAP] as 535 required by [IMAP]. As noted above in Section 5.3, servers SHOULD 536 support the deflate compression algorithm for TLS, as specified in 537 [TLS-COMP]. 539 5.9. Registration of $Forwarded IMAP keyword 541 The $Forwarded IMAP keyword is used by several IMAP clients to 542 specify that the marked message was forwarded to another email 543 address, embedded within or attached to a new message. A mail client 544 sets this keyword when it successfully forwards the message to 545 another email address. Typical usage of this keyword is to show a 546 different (or additional) icon for a message that has been forwarded. 547 Once set the flag SHOULD NOT be cleared. 549 Lemonade Message Stores MUST be able to store the $Forwarded keyword. 550 They MUST preserve it on the COPY operation. The servers MUST 551 support the SEARCH KEYWORD $Forwarded. 553 5.10. Registration of $SubmitPending and $Submitted IMAP keywords 555 The $SubmitPending IMAP keyword designates the message as awaiting to 556 be submitted. This keyword allows to store messages waiting to be 557 submitted in the same mailbox where messages that were already 558 submitted and/or being edited are stored. A mail client sets this 559 keyword when it decides that the message needs to be sent out. When 560 a client (it might be a different client from the one that decided 561 that the message is pending submission) starts sending the message, 562 it atomically (using "STORE (UNCHANGEDSINCE)") adds the $Submitted 563 keyword. Once submission is successful, the $SubmitPending keyword 564 is atomically cleared. The two keywords allow to distinguish 565 messages being actively submitted (messages that have both $Submitted 566 and $SubmitPending keywords set) from messages awaiting to be 567 submitted, or from messages already submitted. They also allow to 568 find all messages that were supposed to be submitted, if the client 569 submitting them crashes or quits before submitting them. 571 Lemonade Message Stores MUST be able to store the $SubmitPending and 572 the $Submitted keyword. Lemonade Message Stores MUST preserve them 573 on the COPY operation. The servers MUST support the SEARCH KEYWORD 574 $SubmitPending and SEARCH KEYWORD $Submitted. 576 5.11. Related IMAP extensions 578 Section 5.11 is non-normative. 580 Server implementations targeting to fulfil OMA MEM requirements 581 [OMA-MEM-REQ] should consider implementing [IMAP-FILTERS], which 582 provides a way to persist definition of virtual mailboxes on the 583 server. They should also consider implementing METADATA-SERVER 584 [METADATA] extension, which provides a way of storing user-defined 585 data associated with a user account. 587 6. Lemonade Message Delivery Agents 589 Lemonade Message Delivery Agents MUST support the [SIEVE] filtering 590 language at the point of delivery, allowing the user to control which 591 messages are accepted, and where they are filed. 593 Lemonade Message Delivery Agents MUST support the Sieve Vacation 594 extension [SIEVE-VACATION], which allows the client to setup an auto- 595 responder, typically to report being on vacation (thus the name of 596 the Sieve extension). 598 Lemonade Message Delivery Agents MUST support the Sieve Enotify 599 extension [SIEVE-NOTIFY], which allows a Sieve script to generate 600 notifications (such as XMPP, SIP or email) about received messages. 602 Lemonade Message Delivery Agents MUST support the Sieve Variables 603 extension [SIEVE-VARIABLES], which adds support for variables to the 604 Sieve scripting language. This extension is typically used with 605 Sieve Enotify or Vacation to customize responses/notifications. 607 Lemonade Message Delivery Agents MUST support the Sieve Relational 608 extension [SIEVE-RELATIONAL], which adds support for relational 609 comparisons to the Sieve scripting language. This extension is 610 typically used together with Sieve Enotify. 612 Lemonade Message Delivery Agents MUST support the Sieve Imap4Flags 613 extension [SIEVE-IMAP4FLAGS], which allows a Sieve script to set IMAP 614 flags/keywords when delivering a message to a mailbox. For example 615 this can be used to automatically mark certain messages as 616 interesting, urgent, etc. 618 Lemonade Message Delivery Agents MUST support the i;unicode-casemap 619 comparator in Sieve [UNICODE-CASEMAP], which is declared as 620 "comparator-i;unicode-casemap" in the Sieve "require" statement. The 621 comparator allows for case-insensitive matching of Unicode 622 characters. 624 Lemonade Message Delivery Agents should consider supporting Sieve 625 script management using the [MANAGESIEVE] protocol. If they do, they 626 MUST also advertise in [MANAGESIEVE] all Sieve extensions listed in 627 this section. 629 7. Lemonade Mail User Agents 631 Although all existing IMAP MUAs are Lemonade compliant in as much as 632 all Lemonade services are based on the existing [IMAP] and [SUBMIT] 633 protocols, client implementors are encouraged to take full advantage 634 of the facilities provided by Lemonade Submission Servers and 635 Lemonade Message Stores, as described in Section 4 and Section 5 636 respectively. 638 Note that the explicit usage of [SUBMIT] means that when opening a 639 connection to the submission server, clients MUST do so using port 640 587 unless explicitly configured to use an alternate port [RFC5068]. 641 If the TCP connection to the submission server fails to open using 642 port 587, the client MAY then immediately retry using a different 643 port, such as 25. See [SUBMIT] information on why using port 25 is 644 likely to fail depending on the current location of the client, and 645 may result in a failure code during the SMTP transaction. 647 In addition, some specifications are useful to support interoperable 648 messaging with an enhanced user experience. 650 Lemonade capable clients SHOULD support the Format and DelSp 651 parameters to the text/plain media type described in [FLOWED], and 652 generate this format for messages. 654 Lemonade capable clients SHOULD support, and use, the $Forwarded 655 keyword described in Section 5.9. 657 8. Forward without download 659 8.1. Motivations 661 The advent of client/server email using the [IMAP] and [SUBMIT] 662 protocols changed what formerly were local disk operations to become 663 repetitive network data transmissions. 665 Lemonade "forward without download" makes use of the [SMTP-BURL] 666 extension to enable access to external sources during the submission 667 of a message. In combination with the [IMAP-URLAUTH] extension, 668 inclusion of message parts or even entire messages from the IMAP mail 669 store is possible with a minimal trust relationship between the IMAP 670 and SMTP SUBMIT servers. 672 Lemonade "forward without download" has the advantage of maintaining 673 one submission protocol, and thus avoids the risk of having multiple 674 parallel and possibly divergent mechanisms for submission. The 675 client can use [SUBMIT] extensions without these being added to IMAP. 677 Furthermore, by keeping the details of message submission in the SMTP 678 SUBMIT server, Lemonade "forward without download" can work with 679 other message retrieval protocols such as POP, NNTP, or whatever else 680 may be designed in the future. 682 8.2. Message Sending Overview 684 The act of sending an email message can be thought of as involving 685 multiple steps: initiation of a new draft, draft editing, message 686 assembly, and message submission. 688 Initiation of a new draft and draft editing takes place in the MUA. 689 Frequently, users choose to save more complex messages on an [IMAP] 690 server (via the APPEND command with the \Draft flag) for later recall 691 by the MUA and resumption of the editing process. 693 Message assembly is the process of producing a complete message from 694 the final revision of the draft and external sources. At assembly 695 time, external data is retrieved and inserted in the message. 697 Message submission is the process of inserting the assembled message 698 into the [ESMTP] infrastructure, typically using the [SUBMIT] 699 protocol. 701 8.3. Traditional Strategy 703 Traditionally, messages are initiated, edited, and assembled entirely 704 within an MUA, although drafts may be saved to an [IMAP] server and 705 later retrieved from the server. The completed text is then 706 transmitted to an MSA for delivery. 708 There is often no clear boundary between the editing and assembly 709 process. If a message is forwarded, its content is often retrieved 710 immediately and inserted into the message text. Similarly, when 711 external content is inserted or attached, the content is usually 712 retrieved immediately and made part of the draft. 714 As a consequence, each save of a draft and subsequent retrieve of the 715 draft transmits that entire (possibly large) content, as does message 716 submission. 718 In the past, this was not much of a problem, because drafts, external 719 data, and the message submission mechanism were typically located on 720 the same system as the MUA. The most common problem was running out 721 of disk quota. 723 8.4. A new strategy 725 The model distinguishes between a Messaging User Agent (MUA), an 726 IMAPv4Rev1 Server ([IMAP]) and a SMTP submit server ([SUBMIT]), as 727 illustrated in Figure 1. 729 +--------------------+ +--------------+ 730 | | <------------ | | 731 | MUA (M) | | IMAPv4Rev1 | 732 | | | Server | 733 | | ------------> | (Server I) | 734 +--------------------+ +--------------+ 735 ^ | ^ | 736 | | | | 737 | | | | 738 | | | | 739 | | | | 740 | | | | 741 | | | v 742 | | +--------------+ 743 | |----------------------> | SMTP | 744 | | Submit | 745 |-----------------------------| Server | 746 | (Server S) | 747 +--------------+ 749 Figure 1: Lemonade "forward without download" 751 Lemonade "forward without download" allows a Messaging User Agent to 752 compose and forward an e-mail combining fragments that are located in 753 an IMAP server, without having to download these fragments to the 754 client. 756 There are two ways to perform "forward without download" based on 757 where the message assembly takes place. The first uses extended 758 APPEND command [IMAP-CATENATE] to edit a draft message in the message 759 store and cause the message assembly on the IMAP server. This is 760 most often used when a copy of the message is to be retained on the 761 IMAP server, as discussed in Section 8.6. 763 The second uses a succession of BURL and BDAT commands to submit and 764 assemble through concatenation, message data from the client and 765 external data fetched from the provided URL. The two subsequent 766 sections provide step-by-step instructions on how "forward without 767 download" is achieved. 769 8.4.1. Message assembly using IMAP CATENATE extension 771 In the [SMTP-BURL]/[IMAP-CATENATE] variant of the Lemonade "forward 772 without download" strategy, messages are initially composed and 773 edited within an MUA. The [IMAP-CATENATE] extension to [IMAP] is 774 then used to create the messages on the IMAP server by transmitting 775 new text and assembling them. The UIDPLUS [IMAP-UIDPLUS] IMAP 776 extension is used by the client in order to learn the UID of the 777 created messages. Finally a [IMAP-URLAUTH] format URL is given to a 778 [SUBMIT] server for submission using the BURL [SMTP-BURL] extension. 780 The flow involved to support such a use case consists of: 782 M: {to I -- Optional} The client connects to the IMAP server, 783 optionally starts TLS (if data confidentiality is required), 784 authenticates, opens a mailbox ("INBOX" in the example below) and 785 fetches body structures (See [IMAP]). 787 Example: 789 M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) 790 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 791 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( 792 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 793 "trip.txt") 794 "<960723163407.20117h@washington.example.com>" 795 "Your trip details" "BASE64" 4554 73) "MIXED")) 796 I: A0051 OK completed 798 M: {to I} The client invokes CATENATE (See [IMAP-CATENATE] for 799 details of the semantics and steps) -- this allows the MUA to create 800 messages on the IMAP server using new data combined with one or more 801 message parts already present on the IMAP server. 803 Note that the example for this step doesn't use the LITERAL+ 804 [IMAP-LITERAL+] extension. Without LITERAL+ the new message is 805 constructed using 3 round-trips. If LITERAL+ is used, the new 806 message can be constructed using one round-trip. 808 M: A0052 APPEND Sent FLAGS (\Draft \Seen $MDNSent) 809 CATENATE (TEXT {475} 810 I: + Ready for literal data 811 M: Message-ID: <419399E1.6000505@caernarfon.example.org> 812 M: Date: Thu, 12 Nov 2004 16:57:05 +0000 813 M: From: Bob Ar 814 M: MIME-Version: 1.0 815 M: To: foo@example.net 816 M: Subject: About our holiday trip 817 M: Content-Type: multipart/mixed; 818 M: boundary="------------030308070208000400050907" 819 M: 820 M: --------------030308070208000400050907 821 M: Content-Type: text/plain; format=flowed 822 M: 823 M: Our travel agent has sent the updated schedule. 824 M: 825 M: Cheers, 826 M: Bob 827 M: --------------030308070208000400050907 828 M: URL "/INBOX;UIDVALIDITY=385759045/; 829 UID=25627/;Section=2.MIME" URL "/INBOX; 830 UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44} 831 I: + Ready for literal data 832 M: 833 M: --------------030308070208000400050907-- 834 M: ) 835 I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed 837 M: {to I} The client uses GENURLAUTH command to request a URLAUTH URL 838 (See [IMAP-URLAUTH]). 839 I: {to M} The IMAP server returns a URLAUTH URL suitable for later 840 retrieval with URLFETCH (See [IMAP-URLAUTH] for details of the 841 semantics and steps). 843 M: A0053 GENURLAUTH "imap://bob.ar@example.org/Sent; 844 UIDVALIDITY=387899045/;uid=45;expire=2005-10- 845 28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL 846 I: * GENURLAUTH "imap://bob.ar@example.org/Sent; 847 UIDVALIDITY=387899045/;uid=45;expire= 848 2005-10-28T23:59:59Z;urlauth=submit+bob.ar: 849 internal:91354a473744909de610943775f92038" 850 I: A0053 OK GENURLAUTH completed 852 M: {to S} The client connects to the mail submission server and 853 starts a new mail transaction. It uses BURL to let the SMTP submit 854 server fetch the content of the message from the IMAP server (See 855 [IMAP-URLAUTH] for details of the semantics and steps -- this allows 856 the MUA to authorize the SMTP submit server to access the message 857 composed as a result of the CATENATE step). Note that the second 858 EHLO command is required after a successful STARTTLS command. Also 859 note that there might be a third required EHLO command if the second 860 EHLO response doesn't list any BURL options. Section 8.4.2 861 demonstrates this. 863 S: 220 owlry.example.org ESMTP 864 M: EHLO potter.example.org 865 S: 250-owlry.example.com 866 S: 250-8BITMIME 867 S: 250-BINARYMIME 868 S: 250-PIPELINING 869 S: 250-BURL imap 870 S: 250-CHUNKING 871 S: 250-AUTH PLAIN 872 S: 250-DSN 873 S: 250-SIZE 10240000 874 S: 250-STARTTLS 875 S: 250 ENHANCEDSTATUSCODES 876 M: STARTTLS 877 S: 220 Ready to start TLS 878 ...TLS negotiation, subsequent data is encrypted... 879 M: EHLO potter.example.org 880 S: 250-owlry.example.com 881 S: 250-8BITMIME 882 S: 250-BINARYMIME 883 S: 250-PIPELINING 884 S: 250-BURL imap 885 S: 250-CHUNKING 886 S: 250-AUTH PLAIN 887 S: 250-DSN 888 S: 250-SIZE 10240000 889 S: 250 ENHANCEDSTATUSCODES 890 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 891 M: MAIL FROM: 892 M: RCPT TO: 893 S: 235 2.7.0 PLAIN authentication successful. 894 S: 250 2.5.0 Address Ok. 895 S: 250 2.1.5 foo@example.net OK. 896 M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/; 897 uid=45/;urlauth=submit+bar:internal: 898 91354a473744909de610943775f92038 LAST 900 S: {to I} The mail submission server uses URLFETCH to fetch the 901 message to be sent (See [IMAP-URLAUTH] for details of the semantics 902 and steps. The so-called "pawn-ticket" authorization mechanism uses 903 a URI which contains its own authorization credentials.). 905 I: {to S} Provides the message composed as a result of the CATENATE 906 step). 908 Mail submission server opens IMAP connection to the IMAP server: 910 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ 911 CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com 912 IMAP server ready 913 S: a000 STARTTLS 914 I: a000 Start TLS negotiation now 915 ...TLS negotiation, if successful - subsequent data 916 is encrypted... 917 S: a001 LOGIN submitserver secret 918 I: a001 OK submitserver logged in 919 S: a002 URLFETCH "imap://bob.ar@example.org/Sent; 920 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: 921 internal:91354a473744909de610943775f92038" 922 I: * URLFETCH "imap://bob.ar@example.org/Sent; 923 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: 924 internal:91354a473744909de610943775f92038" {15065} 925 ...message body follows... 926 S: a002 OK URLFETCH completed 927 I: a003 LOGOUT 928 S: * BYE See you later 929 S: a003 OK Logout successful 931 Note that if data confidentiality is not required the mail submission 932 server may omit the STARTTLS command before issuing the LOGIN 933 command. 935 S: {to M} Submission server assembles the complete message and if the 936 assembly succeeds it returns OK to the MUA: 938 S: 250 2.5.0 Ok. 940 M: {to I} The client marks the message containing the forwarded 941 attachment on the IMAP server. 943 M: A0054 UID STORE 25627 +FLAGS.SILENT ($Forwarded) 944 I: * 215 FETCH (UID 25627 MODSEQ (12121231000)) 945 I: A0054 OK STORE completed 947 Note: the UID STORE command shown above will only work if the marked 948 message is in the currently selected mailbox; otherwise, it requires 949 a SELECT. This command can be omitted, as it simply changes non- 950 operational metadata not essential to client operations or 951 interoperability. The untagged FETCH response is due to 952 [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in 953 Section 5.9. 955 8.4.2. Message assembly using SMTP CHUNKING and BURL extensions 957 In the [IMAP-URLAUTH]/[SMTP-BURL] variant of the Lemonade "forward 958 without download" strategy, messages are initially composed and 959 edited within an MUA. During submission [SUBMIT], BURL [SMTP-BURL] 960 and BDAT [SMTP-BINARYMIME] commands are used to create the messages 961 from multiple parts. New body parts are supplied using BDAT 962 commands, while existing body parts are referenced using 963 [IMAP-URLAUTH] format URLs in BURL commands. 965 The flow involved to support such a use case consists of: 966 M: {to I -- Optional} The client connects to the IMAP server, 967 optionally starts TLS (if data confidentiality is required), 968 authenticates, opens a mailbox ("INBOX" in the example below) and 969 fetches body structures (See [IMAP]). 971 Example: 973 M: B0051 UID FETCH 25627 (UID BODYSTRUCTURE) 974 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 975 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( 976 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 977 "trip.txt") 978 "<960723163407.20117h@washington.example.com>" 979 "Your trip details" "BASE64" 4554 73) "MIXED")) 980 I: B0051 OK completed 982 M: {to I} The client uses GENURLAUTH command to request URLAUTH URLs 983 (See [IMAP-URLAUTH]) referencing pieces of the message to be 984 assembled. 985 I: {to M} The IMAP server returns URLAUTH URLs suitable for later 986 retrieval with URLFETCH (See [IMAP-URLAUTH] for details of the 987 semantics and steps). 989 M: B0052 GENURLAUTH "imap://bob.ar@example.org/INBOX; 990 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 991 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" 992 INTERNAL "imap://bob.ar@example.org/INBOX; 993 UIDVALIDITY=385759045/;UID=25627/;Section=2; 994 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL 995 I: * GENURLAUTH "imap://bob.ar@example.org/INBOX; 996 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 997 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 998 internal:A0DEAD473744909de610943775f9BEEF" 999 "imap://bob.ar@example.org/INBOX; 1000 UIDVALIDITY=385759045/;UID=25627/;Section=2; 1001 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1002 internal:BEEFA0DEAD473744909de610943775f9" 1003 I: B0052 OK GENURLAUTH completed 1005 M: {to S} The client connects to the mail submission server and 1006 starts a new mail transaction. It uses BURL to instruct the SMTP 1007 submit server to fetch from the IMAP server pieces of the message to 1008 be sent (See [SMTP-BURL] for details of the semantics and steps). 1010 Note that the second EHLO command is required after a successful 1011 STARTTLS command. The third EHLO command is required if and only if 1012 the second EHLO response doesn't list any BURL options. See 1013 Section 8.4.1 for an example of submission where the third EHLO 1014 command/response is not present. 1016 S: 220 owlry.example.org ESMTP 1017 M: EHLO potter.example.org 1018 S: 250-owlry.example.com 1019 S: 250-8BITMIME 1020 S: 250-BINARYMIME 1021 S: 250-PIPELINING 1022 S: 250-BURL 1023 S: 250-CHUNKING 1024 S: 250-AUTH DIGEST-MD5 1025 S: 250-DSN 1026 S: 250-SIZE 10240000 1027 S: 250-STARTTLS 1028 S: 250 ENHANCEDSTATUSCODES 1029 M: STARTTLS 1030 S: 220 Ready to start TLS 1031 ...TLS negotiation, subsequent data is encrypted... 1032 M: EHLO potter.example.org 1033 S: 250-owlry.example.com 1034 S: 250-8BITMIME 1035 S: 250-BINARYMIME 1036 S: 250-PIPELINING 1037 S: 250-BURL 1038 S: 250-CHUNKING 1039 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL 1040 S: 250-DSN 1041 S: 250-SIZE 10240000 1042 S: 250 ENHANCEDSTATUSCODES 1043 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 1044 S: 235 2.7.0 PLAIN authentication successful. 1045 M: EHLO potter.example.org 1046 S: 250-owlry.example.com 1047 S: 250-8BITMIME 1048 S: 250-BINARYMIME 1049 S: 250-PIPELINING 1050 S: 250-BURL imap imap://imap.example.org 1051 S: 250-CHUNKING 1052 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL 1053 S: 250-DSN 1054 S: 250-SIZE 10240000 1055 S: 250 ENHANCEDSTATUSCODES 1056 M: MAIL FROM: BODY=BINARY 1057 S: 250 2.5.0 Address Ok. 1058 M: RCPT TO: 1059 S: 250 2.1.5 foo@example.net OK. 1060 M: BDAT 475 1061 M: Message-ID: <419399E1.6000505@caernarfon.example.org> 1062 M: Date: Thu, 12 Nov 2004 16:57:05 +0000 1063 M: From: Bob Ar 1064 M: MIME-Version: 1.0 1065 M: To: foo@example.net 1066 M: Subject: About our holiday trip 1067 M: Content-Type: multipart/mixed; 1068 M: boundary="------------030308070208000400050907" 1069 M: 1070 M: --------------030308070208000400050907 1071 M: Content-Type: text/plain; format=flowed 1072 M: 1073 M: Our travel agent has sent the updated schedule. 1074 M: 1075 M: Cheers, 1076 M: Bob 1077 M: --------------030308070208000400050907 1078 S: 250 2.5.0 OK 1079 M: BURL imap://bob.ar@example.org/INBOX; 1080 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 1081 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1082 internal:A0DEAD473744909de610943775f9BEEF 1083 S: 250 2.5.0 OK 1084 M: BURL imap://bob.ar@example.org/INBOX; 1085 UIDVALIDITY=385759045/;UID=25627/;Section=2; 1086 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1087 internal:BEEFA0DEAD473744909de610943775f9 1088 S: 250 2.5.0 OK 1089 M: BDAT 44 LAST 1090 M: 1091 M: --------------030308070208000400050907-- 1093 S: {to I} The mail submission server uses URLFETCH to fetch the 1094 pieces of the message to be sent (See [SMTP-BURL] for details of the 1095 semantics and steps. The so-called "pawn-ticket" authorization 1096 mechanism uses a URI which contains its own authorization 1097 credentials.). 1098 I: {to S} Returns the requested body parts. 1100 Mail submission server opens IMAP connection to the IMAP server: 1102 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ 1103 CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com 1104 IMAP server ready 1105 S: b000 STARTTLS 1106 I: b000 Start TLS negotiation now 1107 ...TLS negotiation, if successful - subsequent data 1108 is encrypted... 1109 S: b001 LOGIN submitserver secret 1110 I: b001 OK submitserver logged in 1111 S: b002 URLFETCH "imap://bob.ar@example.org/INBOX; 1112 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 1113 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1114 internal:A0DEAD473744909de610943775f9BEEF" "imap:// 1115 bob.ar@example.org/INBOX; 1116 UIDVALIDITY=385759045/;UID=25627/;Section=2; 1117 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1118 internal:BEEFA0DEAD473744909de610943775f9" 1119 I: * URLFETCH "imap://bob.ar@example.org/INBOX; 1120 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 1121 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1122 internal:A0DEAD473744909de610943775f9BEEF" {84} 1123 ...message section follows... 1124 "imap://bob.ar@example.org/INBOX; 1125 UIDVALIDITY=385759045/;UID=25627/;Section=2; 1126 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1127 internal:BEEFA0DEAD473744909de610943775f9" {15065} 1128 ...message section follows... 1129 S: b002 OK URLFETCH completed 1130 I: b003 LOGOUT 1131 S: * BYE See you later 1132 S: b003 OK Logout successful 1134 Note that if data confidentiality is not required the mail submission 1135 server may omit the STARTTLS command before issuing the LOGIN 1136 command. 1138 S: {to M} Submission server assembles the complete message and if the 1139 assembly succeeds it acknowledges acceptance of the message by 1140 sending 250 response to the last BDAT command: 1142 S: 250 2.5.0 Ok, message accepted. 1144 M: {to I} The client marks the message containing the forwarded 1145 attachment on the IMAP server. 1147 M: B0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) 1148 I: * 215 FETCH (UID 25627 MODSEQ (12121231000)) 1149 I: B0053 OK STORE completed 1151 Note: the UID STORE command shown above will only work if the marked 1152 message is in the currently selected mailbox; otherwise, it requires 1153 a SELECT. As in the previous example, this command is not critical, 1154 and can be omitted. The untagged FETCH response is due to 1155 [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in 1156 Section 5.9. 1158 8.5. Security Considerations for pawn-tickets. 1160 The so-called "pawn-ticket" authorization mechanism uses a URI, which 1161 contains its own authorization credentials using [IMAP-URLAUTH]. The 1162 advantage of this mechanism is that the SMTP submit [SUBMIT] server 1163 cannot access any data on the [IMAP-URLAUTH] server without a "pawn- 1164 ticket" created by the client. 1166 The "pawn-ticket" grants access only to the specific data that the 1167 SMTP submit [SUBMIT] server is authorized to access, can be revoked 1168 by the client, and can have a time-limited validity. 1170 8.6. Copies of Sent messages: The fcc problem 1172 The "fcc problem" refers to delivering a copy of a message to a 1173 mailbox, or "file carbon copy". By far, the most common case of fcc 1174 is a client leaving a copy of outgoing mail in a "Sent Mail" or 1175 "Outbox" mailbox. 1177 In the traditional strategy, the MUA duplicates the effort spent in 1178 transmitting to the MSA by writing the message to the fcc destination 1179 in a separate step. This may be a write to a local disk file or an 1180 APPEND to a mailbox on an IMAP server. The latter is one of the 1181 "repetitive network data transmissions" which represents the 1182 "problem" aspect of the "fcc problem". 1184 The BURL [SMTP-BURL] extension can be used to eliminate the 1185 additional transmission. The final message is uploaded to the 1186 mailbox designed for outgoing mail, by the APPEND command of [IMAP]. 1187 Note that when doing so the client ought to use the $SubmitPending 1188 and $Submitted IMAP keywords described in Section 5.10. Also note 1189 that APPEND, including when enhanced by [IMAP-CATENATE], can only 1190 create a single copy of the message and this is only of use on the 1191 server which stages the outgoing message for submission. Additional 1192 copies of the message on the same server can be created by using one 1193 or more COPY commands. 1195 9. Deployment Considerations 1197 Deployment considerations are discussed extensively in 1198 [LEMONADE-DEPLOYMENTS]. 1200 10. Security Considerations 1202 Implementors are advised to examine the Security Considerations of 1203 all the referenced documents. This section merely highlights these, 1204 and advises implementors on specific issues relating to the 1205 combination of extensions. 1207 Security considerations on Lemonade "forward without download" are 1208 discussed throughout Section 8. Additional security considerations 1209 can be found in [IMAP] and other documents describing other SMTP and 1210 IMAP extensions comprising the Lemonade Profile. 1212 Note that the mandatory-to-implement authentication mechanism for 1213 SMTP submission is described in [SMTP-AUTH]. The mandatory-to- 1214 implement authentication mechanism for IMAP is described in [IMAP]. 1216 10.1. Confidentiality Protection of Submitted Messages 1218 When clients submit new messages, link protection such as [TLS] 1219 guards against an eavesdropper seeing the contents of the submitted 1220 message. It is worth noting, however, that even if TLS is not used, 1221 the security risks are no worse if BURL is used to reference the text 1222 than if the text is submitted directly. If BURL is not used, an 1223 eavesdropper gains access to the full text of the message. If BURL 1224 is used, the eavesdropper may or may not be able to gain such access, 1225 depending on the form of BURL used. For example, some forms restrict 1226 use of the URL to an entity authorized as a submission server or a 1227 specific user. 1229 10.2. TLS 1231 When Lemonade clients use the BURL extension for mail submission, an 1232 extension that requires sending a URLAUTH token to the mail 1233 submission server, such a token should be protected from interception 1234 to avoid a replay attack that may disclose the contents of the 1235 message to an attacker. [TLS] based encryption of both the IMAP 1236 session that issues GENURLAUTH and the mail submission path will 1237 provide protection against this attack. 1239 Lemonade compliant mail submission servers SHOULD use TLS-protected 1240 IMAP connections when fetching message content using the URLAUTH 1241 token provided by the Lemonade client. 1243 When a client uses SMTP STARTTLS to send a BURL command which 1244 references non-public information, there is a user expectation that 1245 the entire message content will be treated confidentially. To meet 1246 this expectation, the message submission server SHOULD use STARTTLS 1247 or a mechanism providing equivalent data confidentiality when 1248 fetching the content referenced by that URL. 1250 10.3. Additional extensions and deployment models 1252 This specification provides no additional security measures beyond 1253 those in the referenced Internet Mail and Lemonade documents. 1255 We note however the security risks associated with: 1256 o Outband notifications 1257 o Server configuration by client 1258 o Client configuration by server 1259 o Presence of proxy servers 1260 o Presence of servers as intermediaries 1261 o In general the deployment models considered by OMA MEM that are 1262 not conventional IETF deployment models. 1263 o Measures to address a perceived need to traverse firewalls and 1264 mobile network intermediaries. 1265 Deployments that provide these additional services or operate in 1266 these environments need to consult the security considerations for 1267 the relevant standards and organizational security practices. 1269 11. IANA considerations 1271 IMAP4 capabilities are registered by publishing a standards track or 1272 IESG approved experimental RFC. The registry is currently located at 1273 . This document 1274 defines the URL-PARTIAL IMAP capability Section 5.7.1. IANA is 1275 requested to add this extension to the IANA IMAP Capability registry. 1277 12. Version history 1279 o Version 11: 1280 * Made ManageSieve reference Informative. 1281 * Renamed $PendingSubmission to $SubmitPending, dropped 1282 $BeingSubmitted and added $Submitted IMAP keywords. 1283 o Version 10: 1284 * Added ManageSieve. 1285 * Added a requirement to support i;unicode-casemap in Sieve 1286 (already required in IMAP). 1287 * Added description of various Sieve extensions. 1288 * Added definition of URL-PARTIAL IMAP extension. 1289 * Added definition of $PendingSubmission and $BeingSubmitted IMAP 1290 keywords. 1291 o Version 9: 1292 * Updated references and removed extensions that there was an 1293 agreement to remove. 1294 o Version 08: 1295 * Removed LIST-EXTENDED, WITHIN and QUICKSTART. 1296 * Updated names of required extensions when they were renamed 1297 (e.g. COMPARATOR ==> I18NLEVEL=1). 1298 o Version 06: 1299 * Updated references and added extensions agreed at the Lemonade 1300 interim in Spring 2007. 1301 * Require any Lemonade compliant IMAP server to support 1302 CAPABILITY response code. 1303 o Version 04: 1304 * Major reorganization of text. 1305 * Move checklist summary to beginning of document, collate 1306 Submission and Store server requirements. 1307 o Version 03: 1308 * Replaced RECONNECT (server side quick reconned) with QRESYNC 1309 (client side quick reconnect) 1310 * Added WITHIN and LIST-EXTENDED. 1311 * Moved IDLE extension to a separate section. 1312 * Added requirement for clients to use Format=flowed. 1313 o Version 02: 1314 * Update of references and how they are displayed in the text 1315 (Comments from Randy Gellens) 1316 * Update of list of extensions to support as MUST by the Lemonade 1317 Profile Bis 1318 * Update of options for compression via placeholder imap- 1319 compression section describing compression requirements 1320 * Update of support of TCP chalenged environments 1321 * Update of support of object level encryption 1322 * Clarified the use of $Forwarded in the examples, and 1323 demonstrated how to remove the \Draft flag from the sent 1324 message 1326 * Clarified $Forwarded 1327 * Added RECONNECT to imap-condstore section 1328 * Add new section imap-bodypart, "Message part handling", 1329 describing BINARY and CONVERT requirements 1330 * Added placeholder section for notifications 1331 * Added various extensions to imap-other section, and added 1332 clarifying comments to IDLE, NAMESPACE, and a further 1333 references to TLS DEFLATE compression 1334 * Added extension names to IMAP table 1335 * Fixed all issues found with original Lemonade profile so far. 1336 o Version 01: 1337 * Lemonade profile has been introduced in-line, with some updates 1338 / corrections. 1339 * Subsequent re-organization of the text 1340 * Details of extensions proper to Lemonade Profile-bis have been 1341 updated to refer to the drafts newly accepted as WG IETF 1342 drafts. 1343 * Addition of appendix on attachements streaming. 1344 o Version 00: 1345 * It evolved from a combination of the content of Lemonade 1346 profile and the OMA MEM realization internet draft. 1348 13. Acknowledgements 1350 The editors acknowledge and appreciate the work and comments of the 1351 IETF Lemonade working group and the OMA MEM working group. 1353 In particular, the editors would like to thank Eric Burger, Glenn 1354 Parsons, Randall Gellens, Filip Navara, Zoltan Ordogh, Greg 1355 Vaudreuil, and Fan Xiaohui for their comments and reviews. 1357 14. References 1359 14.1. Normative References 1361 [FLOWED] Gellens, R., "The Text/Plain Format and DelSp Parameters", 1362 RFC 3676, February 2004. 1364 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1365 4rev1", RFC 3501, March 2003. 1367 [IMAP-BINARY] 1368 Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, 1369 April 2003. 1371 [IMAP-CATENATE] 1372 Resnick, P., "Internet Message Access Protocol (IMAP) 1373 CATENATE Extension", RFC 4469, April 2006. 1375 [IMAP-COMPRESS] 1376 Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, 1377 August 2007. 1379 [IMAP-CONDSTORE] 1380 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1381 STORE Operation or Quick Flag Changes Resynchronization", 1382 RFC 4551, June 2006. 1384 [IMAP-CONTEXT] 1385 Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, 1386 July 2008. 1388 [IMAP-CONVERT] 1389 Melnikov, A. and P. Coates, "Internet Message Access 1390 Protocol - CONVERT Extension", RFC 5259, July 2008. 1392 [IMAP-ENABLE] 1393 Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE 1394 Extension", RFC 5161, March 2008. 1396 [IMAP-ESEARCH] 1397 Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH 1398 Command for Controlling What Kind of Information Is 1399 Returned", RFC 4731, November 2006. 1401 [IMAP-I18N] 1402 Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 1403 Message Access Protocol Internationalization", RFC 5255, 1404 June 2008. 1406 [IMAP-IDLE] 1407 Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 1409 [IMAP-LITERAL+] 1410 Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 1411 January 1997. 1413 [IMAP-NAMESPACE] 1414 Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 1415 May 1998. 1417 [IMAP-NOTIFY] 1418 Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP 1419 NOTIFY Extension", RFC 5465, February 2009. 1421 [IMAP-QRESYNC] 1422 Melnikov, A., Cridland, D., and C. Wilson, "IMAP4 1423 Extensions for Quick Mailbox Resynchronization", 1424 draft-ietf-lemonade-5162bis-00 (work in progress), 1425 October 2008. 1427 [IMAP-SASL-IR] 1428 Siemborski, R. and A. Gulbrandsen, "IMAP Extension for 1429 Simple Authentication and Security Layer (SASL) Initial 1430 Client Response", RFC 4959, September 2007. 1432 [IMAP-SORT] 1433 Crispin, M. and K. Murchison, "Internet Message Access 1434 Protocol - SORT and THREAD Extensions", RFC 5256, 1435 June 2008. 1437 [IMAP-UIDPLUS] 1438 Crispin, M., "Internet Message Access Protocol (IMAP) - 1439 UIDPLUS extension", RFC 4315, December 2005. 1441 [IMAP-URL] 1442 Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 1443 November 2007. 1445 [IMAP-URLAUTH] 1446 Crispin, M., "Internet Message Access Protocol (IMAP) - 1447 URLAUTH Extension", RFC 4467, May 2006. 1449 [KEYWORDS] 1450 Bradner, S., "Key words for use in RFCs to Indicate 1451 Requirement Levels", BCP 14, RFC 2119, March 1997. 1453 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 1454 Language", RFC 5228, January 2008. 1456 [SIEVE-IMAP4FLAGS] 1457 Melnikov, A., "Sieve Email Filtering: Imap4flags 1458 Extension", RFC 5232, January 2008. 1460 [SIEVE-NOTIFY] 1461 Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 1462 "Sieve Email Filtering: Extension for Notifications", 1463 RFC 5435, January 2009. 1465 [SIEVE-RELATIONAL] 1466 Segmuller, W. and B. Leiba, "Sieve Email Filtering: 1467 Relational Extension", RFC 5231, January 2008. 1469 [SIEVE-VACATION] 1470 Showalter, T. and N. Freed, "Sieve Email Filtering: 1471 Vacation Extension", RFC 5230, January 2008. 1473 [SIEVE-VARIABLES] 1474 Homme, K., "Sieve Email Filtering: Variables Extension", 1475 RFC 5229, January 2008. 1477 [SMTP-8BITMIME] 1478 Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 1479 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 1480 RFC 1652, July 1994. 1482 [SMTP-AUTH] 1483 Siemborski, R. and A. Melnikov, "SMTP Service Extension 1484 for Authentication", RFC 4954, July 2007. 1486 [SMTP-BINARYMIME] 1487 Vaudreuil, G., "SMTP Service Extensions for Transmission 1488 of Large and Binary MIME Messages", RFC 3030, 1489 December 2000. 1491 [SMTP-BURL] 1492 Newman, C., "Message Submission BURL Extension", RFC 4468, 1493 May 2006. 1495 [SMTP-DSN] 1496 Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1497 Extension for Delivery Status Notifications (DSNs)", 1498 RFC 3461, January 2003. 1500 [SMTP-PIPELINING] 1501 Freed, N., "SMTP Service Extension for Command 1502 Pipelining", STD 60, RFC 2920, September 2000. 1504 [SMTP-SIZE] 1505 Klensin, J., Freed, N., and K. Moore, "SMTP Service 1506 Extension for Message Size Declaration", STD 10, RFC 1870, 1507 November 1995. 1509 [SMTP-STATUSCODES] 1510 Freed, N., "SMTP Service Extension for Returning Enhanced 1511 Error Codes", RFC 2034, October 1996. 1513 [SMTP-TLS] 1514 Hoffman, P., "SMTP Service Extension for Secure SMTP over 1515 Transport Layer Security", RFC 3207, February 2002. 1517 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", 1518 RFC 4409, April 2006. 1520 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1521 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1523 [TLS-COMP] 1524 Hollenbeck, S., "Transport Layer Security Protocol 1525 Compression Methods", RFC 3749, May 2004. 1527 [UNICODE-CASEMAP] 1528 Crispin, M., "i;unicode-casemap - Simple Unicode Collation 1529 Algorithm", RFC 5051, October 2007. 1531 14.2. Informative References 1533 [ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1534 October 2008. 1536 [FINGER-HACK] 1537 Gellens, R., "Simple New Mail Notification", RFC 4146, 1538 August 2005. 1540 [IMAP-FILTERS] 1541 Melnikov, A. and C. King, "IMAP4 Extension for Named 1542 Searches (Filters)", RFC 5466, February 2009. 1544 [IMAP-SYNC-HOWTO] 1545 Melnikov, A., "Synchronization Operations for Disconnected 1546 IMAP4 Clients", RFC 4549, June 2006. 1548 [LEMONADE-ARCH] 1549 Burger, E. and G. Parsons, "LEMONADE Architecture - 1550 Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) 1551 using Internet Mail", draft-ietf-lemonade-architecture-04 1552 (work in progress), November 2008. 1554 [LEMONADE-DEPLOYMENTS] 1555 Gellens, R., "Deployment Considerations for Lemonade- 1556 Compliant Mobile Email", BCP 143, RFC 5383, October 2008. 1558 [LEMONADE-NOTIFICATIONS] 1559 Gellens, R. and S. Maes, "Lemonade Notifications 1560 Architecture", draft-ietf-lemonade-notifications-10 (work 1561 in progress), July 2008. 1563 [MANAGESIEVE] 1564 Melnikov, A. and T. Martin, "A Protocol for Remotely 1565 Managing Sieve Scripts", draft-martin-managesieve-12 (work 1566 in progress), September 2008. 1568 [METADATA] 1569 Daboo, C., "The IMAP METADATA Extension", RFC 5464, 1570 February 2009. 1572 [OMA-EMN] Open Mobile Alliance, "Open Mobile Alliance Email 1573 Notification Version 1.0", OMA http:// 1574 www.openmobilealliance.org/Technical/release_program/ 1575 emn_v10.aspx, October 2007. 1577 [OMA-MEM-ARCH] 1578 Open Mobile Alliance, "Mobile Email Architecture 1579 Document", OMA (Work in Progress), 1580 http://www.openmobilealliance.org/, October 2005. 1582 [OMA-MEM-REQ] 1583 Open Mobile Alliance, "Mobile Email Requirements 1584 Document", OMA http://www.openmobilealliance.org/ 1585 release_program/docs/RD/ 1586 OMA-RD-MobileEmail-V1_0_20051018-C.pdf, Oct 2005. 1588 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 1589 Finch, "Email Submission Operations: Access and 1590 Accountability Requirements", BCP 134, RFC 5068, 1591 November 2007. 1593 Authors' Addresses 1595 Dave Cridland (editor) 1596 Isode Limited 1597 5 Castle Business Village 1598 36 Station Road 1599 Hampton, Middlesex TW12 2BX 1600 UK 1602 Email: dave.cridland@isode.com 1603 Alexey Melnikov (editor) 1604 Isode Limited 1605 5 Castle Business Village 1606 36 Station Road 1607 Hampton, Middlesex TW12 2BX 1608 UK 1610 Email: Alexey.Melnikov@isode.com 1612 Stephane H. Maes (editor) 1613 Oracle 1614 MS 4op634, 500 Oracle Parkway 1615 Redwood Shores, CA 94539 1616 USA 1618 Phone: +1-203-300-7786 1619 Email: stephane.maes@oracle.com