IMAPEXT Working Group A. Melnikov Internet Draft Isode Ltd. Document: draft-melnikov-imap-postaddress-05 November 2006 Expires: May 2007 IMAP4 POSTADDRESS extension Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. Distribution of this draft is unlimited. Abstract The POSTADDRESS extension of the Internet Message Access Protocol [IMAP4] permits a client to discover an email address that can be used to send messages to an IMAP mailbox. 1. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. In all examples "/" character is used as hierarchy separator. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 2. Introduction and Overview IMAP POSTADDRESS extension can be used to discover an email address for a given IMAP mailbox. Many email clients support saving a copy of an outgoing message in "sent messages" or "outbox" mailbox. Typically, those email clients send the message first using SMTP. After that they upload a copy of the message using IMAP APPEND. Effectively, the message is sent twice: once using SMTP and once using IMAP. If the IMAP server supports the POSTADDRESS extension, the mail client can avoid uploading a copy of the message using IMAP APPEND. This can be achieved by specifying an additional SMTP recipient, returned by LIST RETURN (POSTADDRESS) command, during submission. A server that supports POSTADDRESS parameter to the LIST command MUST return "POSTADDRESS" in its capability response. Any server supporting the POSTADDRESS extension defined in this document MUST also support the LIST-EXTENDED extension defined in [LISTEXT]. 3. LIST command with the POSTADDRESS parameter This document defines a new return option POSTADDRESS to the extended LIST command [LISTEXT] that requests the server to return an email address that can be used to post email to a mailbox returned by the LIST command. The POSTADDRESS return option causes the server to return the LIST response with the POSTADDRESS information (see section 4). If posting to the mailbox is not allowed or not supported the server MUST return NIL. For example, if the server also supports [ACL] extension and if the user that is issuing LIST RETURN (POSTADDRESS) is not granted the "p" right on the mailbox (the "p" right might be granted to the user directly, or through one of the groups the user belongs to, e.g. it may be granted to the "anonymous"), the extended LIST response MUST return NIL in POSTADDRESS information. Note, that the last requirement doesn't eliminate the need for the SMTP server to enforce access controls on delivery, as the returned email address may be passed by the IMAP client to a third party, not trusted by the SMTP server. Also note, that if the server also supports [ACL] extension and if the user doesn't have either "l" or "r" right on the mailbox, the server MUST NOT disclose the mailbox existence. Example: C: A002 LIST () "" INBOX RETURN (POSTADDRESS) S: * LIST () "/" INBOX ("POSTADDRESS" ( "user1@example.com")) S: A002 OK List with postaddress info completed Note that the empty () after the LIST command name are not required, which is shown below: Example: C: A002 LIST "" Drafts RETURN (POSTADDRESS) S: * LIST (\Marked) "/" Drafts ("POSTADDRESS" NIL) S: A002 OK List with postaddress info completed The following 2 examples demonstrate email addresses that require RFC 2821 quoting of the localpart: Example: C: A002 LIST "" "foo bar" RETURN (POSTADDRESS) S: * LIST () "/" "foo bar" ("POSTADDRESS" ( "\"user1+foo bar\"@example.com")) S: A002 OK List with postaddress info completed Example: C: A002 LIST () "" "foo bar" RETURN (POSTADDRESS) S: * LIST () "/" "foo bar" (POSTADDRESS ({27} S: "user1+foo bar"@example.com)) S: A002 OK List with postaddress info completed The following example demonstrates that a non-existent subscribed mailbox doesn't have a corresponding post address: Example: C: A03 LIST (SUBSCRIBED) "" "*" RETURN (POSTADDRESS) ... S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" (POSTADDRESS NIL) The SUBSCRIBED selection option is described in [LISTEXT]. 4. Extended LIST response with POSTADDRESS information Contents: name attributes hierarchy delimiter mailbox name email address for posting to the mailbox This version of the LIST response occurs as a result of a LIST RETURN (POSTADDRESS) command. The proposed syntax conforms to the syntax of an extended LIST response as defined by mailbox-list ABNF element from [LISTEXT]. The meaning of "name attributes" and "hierarchy delimiter" is described in section 7.2.2 of [IMAP4]. This is followed by the extension part that includes "POSTADDRESS" tag followed by an email address (enclosed in parenthesis) that can be used to post email to the mailbox. The returned email address MUST match the "Mailbox" ABNF production from [SMTP]. If no such address exists for the mailbox, the server MUST return NIL. Note, that any returned email address may be subject to user-controlled delivery filtering, such as [Sieve], which may cause a message sent to the email address to be delivered into a different mailbox or be discarded. The POSTADDRESS extended data item can occur only once in an extended LIST response. If the server knows multiple email addresses associated with a mailbox, it must return only one of them. Example: S: * LIST () "/" Sent ("POSTADDRESS" ( "user+Sent@example.com")) 5. Formal Syntax Formal syntax is defined using ABNF [ABNF], extending the ABNF rules in section 9 of [IMAP4]. Non-terminals referenced but not defined below are as defined by [ABNF], [IMAP4] or [LISTEXT]. Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ "POSTADDRESS" ;;capability is defined in [IMAP4] postaddr-label = "POSTADDRESS" return-option =/ postaddr-label ;; <return-option> is defined in [LISTEXT] postaddr-labret = postaddr-label / DQUOTE postaddr-label DQUOTE / "{11}" CRLF postaddr-label ;; POSTADDRESS label represented as IMAP atom, ;; quoted or literal string postaddr-data = postaddr-labret SP emaddr-or-nil ;; postaddr-data conforms to the syntax of ;; mbox-list-extended-item from [LISTEXT] emaddr-or-nil = "(" email-address ")" / NIL ;; NIL if email address is not known email-address = astring 6. Security Considerations Unless proper access restrictions are implemented, the POSTADDRESS extension can be used by a user to harvest email addresses. Note that email address harvesting is limited to users who already have IMAP access to the service. Also note that some IMAP servers allow for anonymous access. Additional security considerations are discussed in Section 3. 7. IANA Considerations IANA is requested to register the following LISTEXT return option as specified in [LISTEXT]: To: iana@iana.org Subject: Registration of LISTEXT option POSTADDRESS LISTEXT option name: POSTADDRESS LISTEXT option type: RETURN LISTEXT option description: Causes the LIST command to return email address (if any) for posting to a returned mailbox. Published specification : this RFC, section 3. Security considerations: this RFC, section 6. Intended usage: COMMON Person & email address to contact for further information: Alexey Melnikov <Alexey.Melnikov@isode.com> Owner/Change controller: IESG <iesg@ietf.org> 8. Normative References [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [ABNF] Crocker, D. (Ed.) and P. Overell , "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, March 2003. [LISTEXT] Leiba, B. and A. Melnikov, "IMAP4 LIST Command Extensions", work in progress, draft-ietf-imapext-list-extensions-xx.txt. [ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", STD 10, RFC 2821, April 2001. 9. Informative References [Sieve] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001. 10. Aknowledgements The author would like to thank Ken Murchison for reminding that POSTADDRESS extension should not be a part of ACL2. The author would also like to thank Philip Guenther and Arnt Gulbrandsen for corrections and suggestions to this document. 11. Author's Address Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX, UK Email: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/ 12. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 13. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.
Datatracker
draft-melnikov-imap-postaddress-05
Internet-Draft
