IMAPEXT Working Group                                        A. Melnikov
Internet Draft                                                Isode Ltd.
Document: draft-melnikov-imap-postaddress-01                 August 2004
Expires: February 2005

                          IMAP4 POSTADDRESS extension

Status of this Memo

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed, or
    will be disclosed, and any of which I become aware will be disclosed,
    in accordance with RFC 3668.

    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.  Internet Drafts may be updated, replaced, or obsoleted
    by other documents at any time.  It is not appropriate 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.


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


.   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 recipient,
    returned by LIST (POSTADDRESS) command, during the SMTP transaction.

    A server that supports POSTADDRESS parameter to the LIST command SHALL
    return "POSTADDRESS" in its capability response.


. LIST command with the POSTADDRESS parameter

    This document defines a new return option POSTADDRESS to the LIST command
    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 LIST with 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 (POSTADDRESS) doesn't have the "p" right
    on the mailbox, the extended LIST response MUST return NIL in POSTADDRESS
    information.

    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 () "" inbox.Drafts RETURN (POSTADDRESS)
                S: * LIST () "/" inbox.Drafts (("POSTADDRESS" NIL))
                S: A002 OK List with postaddress info completed


. Extended LIST response with POSTADDRESS information

    Contents:   name attributes
                hierarchy delimiter
                mailbox name
                email address for posting to the mailbox

      This version of LIST response occurs as a result of a LIST
      (POSTADDRESS) command. The proposed syntax conforms to the syntax of
      an extended LIST response as defined by mbox-list-extended ABNF
      element of [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 that can be used to post email to the mailbox.

    Example:    S: * LIST () "/" Sent (("POSTADDRESS" "user+Sent@example.com"))


.   Formal Syntax

    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
    Non-terminals referenced but not defined below are as defined by
    [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.

    return-option   =/ "POSTADDRESS"
                      ;; <return-option> is defined in [LISTEXT]

    postaddr_data   = "(" <"> "POSTADDRESS" <"> SP email_address ")"
                      ;; postaddr_data conforms to the syntax of
                      ;; mbox-list-extended-item from [LISTEXT]

    email_address   = nstring
                      ;; NIL if email address is not known


.   Security Considerations

    Unless proper access restrictions are implemented, the POSTADDRESS
    extension can be used by a user to harvest email addresses.

    Additional security considerations are discussed in Section 3.


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


.  Normative References

    [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
    Requirement Levels", RFC 2119, Harvard University, March 1997.

    [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
    ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
    November 1997.

    [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] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie Mellon,
    January 1997.


.  Aknowledgements

    The author would like to thank Ken Murchison for reminding that
    POSTADDRESS extension should not be a part of ACL2.


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


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

.   Full Copyright Statement

    Copyright (C) The Internet Society (2004).  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.