idnits 2.17.1 draft-melnikov-imap-postaddress-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 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 (September 22, 2010) is 4936 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 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Message ORGanization Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Intended status: Standards Track September 22, 2010 5 Expires: March 26, 2011 7 IMAP4 POSTADDRESS extension 8 draft-melnikov-imap-postaddress-07 10 Abstract 12 The POSTADDRESS extension of the Internet Message Access Protocol 13 (RFC 3501) permits a client to discover an email address that can be 14 used to send messages to a user's IMAP mailbox. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 26, 2011. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Table of Contents 62 1. Conventions used in this document . . . . . . . . . . . . . 3 64 2. Introduction and Overview . . . . . . . . . . . . . . . . . 3 65 2.1. Comparison of POSTADDRESS with URLAUTH/BURL . . . . . . . . 3 67 3. LIST command with the POSTADDRESS parameter . . . . . . . . 4 69 4. Extended LIST response with POSTADDRESS information . . . . 6 71 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 7 73 6. Security Considerations . . . . . . . . . . . . . . . . . . 7 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . . 9 81 9.2. Informative References . . . . . . . . . . . . . . . . . . . 9 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Conventions used in this document 87 In examples, "C:" indicates lines sent by a client that is connected 88 to a server. "S:" indicates lines sent by the server to the client. 90 In all examples "/" character is used as hierarchy separator. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 96 2. Introduction and Overview 98 IMAP POSTADDRESS extension can be used to discover an email address 99 for a given IMAP mailbox. Many email clients support saving a copy 100 of an outgoing message in "sent messages" or "outbox" mailbox. 101 Typically, those email clients send the message first using SMTP. 102 After that they upload a copy of the message using IMAP APPEND. 103 Effectively, the message is sent twice: once using SMTP and once 104 using IMAP. If the IMAP server supports the POSTADDRESS extension, 105 the mail client can avoid uploading a copy of the message using IMAP 106 APPEND. This can be achieved by specifying an additional SMTP 107 recipient, returned by LIST RETURN (POSTADDRESS) command, during 108 submission. 110 Note: Similar functionality can be provided when the message to be 111 sent out is first uploaded with IMAP APPEND command to the IMAP 112 server and then submitted using IMAP [RFC4467] and SMTP [RFC4468] 113 extensions. See section 2.1 for the detailed comparison between 114 POSTADDRESS and URLAUTH/BURL. 116 A server that supports POSTADDRESS parameter to the LIST command MUST 117 return "POSTADDRESS" in its capability response. Any server 118 supporting the POSTADDRESS extension defined in this document MUST 119 also support the LIST-EXTENDED extension defined in [LISTEXT]. 121 2.1. Comparison of POSTADDRESS with URLAUTH/BURL 123 Note that the POSTADDRESS extension is easier to implement on the 124 server then the combination of IMAP [RFC4467] and SMTP [RFC4468] 125 extensions. 127 There are certain situations when the POSTADDRESS extension provides 128 functionality not otherwise available with URLAUTH/BURL: 130 1. The POSTADDRESS extension can be used when message assembly is 131 done during submission using multiple BDAT [RFC3030] and/or BURL 133 [RFC4468] commands. URLAUTH/BURL requires that a fully assembled 134 message is first uploaded/created in an IMAP mailbox. 136 2. The POSTADDRESS extension can be used to save a copy of the 137 message in multiple email accounts on one or different server, or 138 in the IMAP mailbox located on a different IMAP server. For 139 example, a user might have access to different IMAP accounts in 140 her client, but would like to save all messages she sent in a 141 mailbox on one of the servers. 143 3. A POSTADDRRESS email address can be used as the envelope MAIL 144 FROM address (to capture bounces), or as the RFC2822 From 145 address, for subscribing to mailing lists, etc. 147 There are some performance related advantages of using POSTADDRESS: 149 If all the message data is generated locally, use of APPEND/ 150 GENURLAUTH [RFC4467] takes 2 round-trips: 152 C: IMAP APPEND 153 S: ...returns the UID of the appended message... 154 C: GENURLAUTH for the appended message (using URL constructed 155 from the UID) 156 S: URL to be used in BURL 158 Some clients may require an additional round-trip to determine if the 159 submission server supports BURL. This may be elided if the server 160 advertises "BURL imap" in the first EHLO response, or if the client 161 either assumes this to be the case, or if it has this capability 162 cached. 164 When using POSTADDRESS, the client needs to discover the posting 165 email address for a mailbox once and can cache it after that. The 166 two round-trips mentioned above will be saved for each submitted 167 message. This is a plus for links with high latency. 169 Note, that any returned POSTADDRESS email address may be subject to 170 user-controlled delivery filtering, such as [RFC5228], which may 171 cause a message sent to the email address to be delivered into a 172 different mailbox or be discarded. 174 3. LIST command with the POSTADDRESS parameter 176 This document defines a new return option POSTADDRESS to the extended 177 LIST command [LISTEXT] that requests the server to return an email 178 address that can be used to post email to a mailbox returned by the 179 LIST command. The POSTADDRESS return option causes the server to 180 return the LIST response with the POSTADDRESS information (see 181 section 4). 183 The returned email address (if any, see below) doesn't have to be 184 permanently available and MAY be different for different invocations 185 of the LIST command. However if the returned address is generated 186 anew each time, it MUST be valid for use for at least 2 hours since 187 the moment it was generated. 189 If posting to the mailbox is not allowed or not supported the server 190 MUST return NIL. For example, if the server also supports [ACL] 191 extension and if the user that is issuing LIST RETURN (POSTADDRESS) 192 is not granted the "p" right on the mailbox (the "p" right might be 193 granted to the user directly, or through one of the groups the user 194 belongs to, e.g. it may be granted to the "anonymous"), the extended 195 LIST response MUST return NIL in POSTADDRESS information. Note, that 196 the last requirement doesn't eliminate the need for the SMTP server 197 to enforce access controls on delivery, as the returned email address 198 may be passed by the IMAP client to a third party, not trusted by the 199 SMTP server. 201 Also note, that if the server also supports [ACL] extension and if 202 the user doesn't have either "l" or "r" right on the mailbox, the 203 server MUST NOT disclose the mailbox existence. 205 Example: C: A002 LIST () "" INBOX RETURN (POSTADDRESS) 206 S: * LIST () "/" INBOX ("POSTADDRESS" ( 207 "user1@example.com")) 208 S: A002 OK List with postaddress info completed 210 Note that the empty () after the LIST command name are not required, 211 which is shown below: 213 Example: C: A002 LIST "" Drafts RETURN (POSTADDRESS) 214 S: * LIST (\Marked) "/" Drafts ("POSTADDRESS" NIL) 215 S: A002 OK List with postaddress info completed 217 The following 2 examples demonstrate email addresses that require RFC 218 2821 quoting of the localpart: 220 Example: C: A002 LIST "" "foo bar" RETURN (POSTADDRESS) 221 S: * LIST () "/" "foo bar" ("POSTADDRESS" ( 222 "\"user1+foo bar\"@example.com")) 223 S: A002 OK List with postaddress info completed 225 Example: C: A002 LIST () "" "foo bar" RETURN (POSTADDRESS) 226 S: * LIST () "/" "foo bar" (POSTADDRESS ({27} 227 S: "user1+foo bar"@example.com)) 228 S: A002 OK List with postaddress info completed 230 The following example demonstrates that a non-existent subscribed 231 mailbox doesn't have a corresponding post address: 233 Example: C: A03 LIST (SUBSCRIBED) "" "*" RETURN (POSTADDRESS) 234 ... 235 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" 236 (POSTADDRESS NIL) 237 ... 239 The SUBSCRIBED selection option is described in [LISTEXT]. 241 4. Extended LIST response with POSTADDRESS information 243 Contents: name attributes 244 hierarchy delimiter 245 mailbox name 246 email address for posting to the mailbox 248 This version of the LIST response occurs as a result of a LIST RETURN 249 (POSTADDRESS) command. The proposed syntax conforms to the syntax of 250 an extended LIST response as defined by mailbox-list ABNF element 251 from [LISTEXT]. 253 The meaning of "name attributes" and "hierarchy delimiter" is 254 described in section 7.2.2 of [RFC3501]. This is followed by the 255 extension part that includes "POSTADDRESS" tag followed by an email 256 address (enclosed in parenthesis) that can be used to post email to 257 the mailbox. The returned email address MUST match the "Mailbox" 258 ABNF production from [RFC5321]. If no such address exists for the 259 mailbox, the server MUST return NIL. 261 The POSTADDRESS extended data item can occur only once in an extended 262 LIST response. If the server knows multiple email addresses 263 associated with a mailbox, it must return only one of them. 265 Example: S: * LIST () "/" Sent ("POSTADDRESS" ( 266 "user+Sent@example.com")) 268 5. Formal Syntax 270 Formal syntax is defined using ABNF [ABNF], extending the ABNF rules 271 in section 9 of [RFC3501]. Non-terminals referenced but not defined 272 below are as defined in [RFC3501] and [LISTEXT]. 274 Except as noted otherwise, all alphabetic characters are case- 275 insensitive. The use of upper or lower case characters to define 276 token strings is for editorial clarity only. Implementations MUST 277 accept these strings in a case-insensitive fashion. 279 capability =/ "POSTADDRESS" 280 ;;capability is defined in [RFC3501] 282 postaddr-label = "POSTADDRESS" 284 return-option =/ postaddr-label 285 ;; is defined in [LISTEXT] 287 postaddr-labret = postaddr-label / 288 DQUOTE postaddr-label DQUOTE / 289 "{11}" CRLF postaddr-label 290 ;; POSTADDRESS label represented as IMAP atom, 291 ;; quoted or literal string 293 postaddr-data = postaddr-labret SP emaddr-or-nil 294 ;; postaddr-data conforms to the syntax of 295 ;; mbox-list-extended-item from [LISTEXT] 297 emaddr-or-nil = "(" email-address ")" / 298 NIL 299 ;; NIL if email address is not known 301 email-address = astring 303 6. Security Considerations 305 Unless proper access restrictions are implemented, the POSTADDRESS 306 extension can be used by a user to harvest email addresses. Note 307 that email address harvesting is limited to users who already have 308 IMAP access to the service. Also note that some IMAP servers allow 309 for anonymous access. 311 Note that some implementations might return IMAP mailbox names in the 312 addresses returned by POSTADDRESS (e.g. if "subaddressing" is used 313 (see Section 3.1.1 of [RFC5598])), which might be considered a 314 confidential information. Use of connection encryption such as TLS 315 [RFC5246] is recommended to protect such confidential information. 317 Also note that interception of the addresses returned by the 318 POSTADDRESS extension may enable a third party to inject mail to a 319 specific mailbox. However this issue is not specific to this 320 extension and can also be seen whenever "subaddressing" is used. 322 Additional security considerations are discussed in Section 3. 324 7. IANA Considerations 326 IMAP4 capabilities are registered by publishing a standards track or 327 IESG approved experimental RFC. The registry is currently located 328 at: 330 http://www.iana.org/assignments/imap4-capabilities 332 This document defines the POSTADDRESS IMAP capability. IANA is 333 requested to add it to the registry. 335 IANA is also requested to register the following LISTEXT return 336 option as specified in [LISTEXT]: 338 To: iana@iana.org 339 Subject: Registration of LISTEXT option POSTADDRESS 340 LISTEXT option name: POSTADDRESS 341 LISTEXT option type: RETURN 342 LISTEXT option description: Causes the LIST command to return 343 email address (if any) for posting to a returned mailbox. 344 Published specification : this RFC, section 3. 345 Security considerations: this RFC, section 6. 346 Intended usage: COMMON 347 Person & email address to contact for further information: 348 Alexey Melnikov 349 Owner/Change controller: IESG 351 8. Acknowledgements 353 The author would like to thank Ken Murchison for reminding that 354 POSTADDRESS extension should not be a part of ACL2. 356 The author would also like to thank Dave Cridland, Philip Guenther, 357 Arnt Gulbrandsen and Lisa Dusseault for corrections and suggestions 358 to this document. 360 9. References 362 9.1. Normative References 364 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 365 Specifications: ABNF", RFC 5234, January 2008. 367 [ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 368 RFC 4314. 370 [KEYWORDS] 371 Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", RFC 2119, March 1997. 374 [LISTEXT] Leiba, B. and A. Melnikov, "IMAP4 LIST Command 375 Extensions", RFC 5258, June 2008. 377 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 378 4rev1", RFC 3501, March 2003. 380 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 381 October 2008. 383 9.2. Informative References 385 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 386 of Large and Binary MIME Messages", RFC 3030, 387 December 2000. 389 [RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - 390 URLAUTH Extension", RFC 4467, May 2006. 392 [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, 393 May 2006. 395 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 396 Language", RFC 5228, January 2008. 398 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 399 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 401 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 402 July 2009. 404 Author's Address 406 Alexey Melnikov 407 Isode Limited 408 5 Castle Business Village 409 36 Station Road 410 Hampton, Middlesex TW12 2BX 411 UK 413 Email: Alexey.Melnikov@isode.com 414 URI: http://www.melnikov.ca/