[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                          B. van Hartingsveldt, Ed.
Internet-Draft                                         November 23, 2019
Intended status: Standards Track
Expires: May 26, 2020

                        IMAP4 INBOXES extension


   The INBOXES extension to the Internet Message Access Protocol -
   Version 4rev1 (IMAP4rev1) protocol gives the client the possibility
   to manage multiple inboxes (mail addresses) with the same username
   and password.  Without this extension you only have access to one

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on May 26, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

van Hartingsveldt         Expires May 26, 2020                  [Page 1]

Internet-Draft           IMAP4 INBOXES extension           November 2019

1.  Introduction

   The IMAP4rev1 protocol described in [RFC2060] provides a method for
   accessing remote mail stores, but it provides no facility to access
   multiple inboxes with only one username and password.  This makes it
   impossible to access other inboxes where the user also has access to
   and forces the mail provider to make the other inboxes accessible
   using an REST API for example.

   The INBOXES command provides a facility to get a list of inboxes that
   are available for the user and gives the possiblilty to switch from
   inbox and get all the data belonging to that inbox, like
   subscriptions, drafts, sent items and other mailboxes (folders).

2.  Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].  The
   conventions used in this document are the same as specified in
   [RFC2060].  In examples, "C:" and "S:" indicate lines sent by the
   client and server respectively.  Line breaks have been inserted for

3.  Specification

   The sole purpose of the INBOXES extension is to enable clients and
   servers to access multiple inboxes using only one username and

3.1.  INBOXES Command

   Arguments:  mail-address or NIL

   Responses:  OPTIONAL untagged response: INBOXES

      OK inboxes successfully shown or switched inbox successfully
      BAD command unknown or arguments invalid

   The INBOXES command is used to get a list of inboxes as well as
   switching to one of this mailboxes.

   This command is valid in the Authenticated State.

van Hartingsveldt         Expires May 26, 2020                  [Page 2]

Internet-Draft           IMAP4 INBOXES extension           November 2019

3.2.  INBOXES Response

   If NIL is given as parameter, the server MUST NOT switch from
   mailbox, but MUST send untagged INBOXES responses back for every
   inbox the user has access to.  If there is only one inbox, it isn't
   possible to switch inbox.  There is no need to return this inbox in
   the response, but the server MAY do it.  If there is at least one
   inbox, there should be one inbox which is the default inbox.  That
   inbox has "DEFAULT" behind the mail address.

   After switching inbox, you are able to access other inboxes other
   then the DEFAULT inbox.  Every inbox can have his own INBOX mailbox.
   It is also possible for the server to give two different users access
   to one shared inbox with that inbox having a username and password on

   The first example shows how to get a list of inboxes:

   C:      a023 INBOXES NIL
   S:      * INBOXES info@example.com
   S:      * INBOXES user@example.com DEFAULT
   S:      * INBOXES verification@example.com
   S:      a023 OK Shown all inboxes

                                 Example 1

   The second example shows how to get switch inbox:

   C:      a023 INBOXES info@example.com
   S:      a023 OK Switched inbox

                                 Example 2

4.  Formal Syntax

   This syntax is intended to augment the grammar specified in [RFC2060]
   in order to provide for the INBOXES command.  This specification uses
   the augmented Backus-Naur Form (BNF) notation as used in [RFC2060].

van Hartingsveldt         Expires May 26, 2020                  [Page 3]

Internet-Draft           IMAP4 INBOXES extension           November 2019

command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / inboxes
        ;; adds inboxes command to command_any in [RFC2060]

inboxes ::= "INBOXES" [SPACE inboxes_param_email]

inboxes_response ::= "INBOXES" [SPACE inboxes_param_email [SPACE "DEFAULT"]]

inboxes_param_email ::= string "@" string

response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
        mailbox_data / message_data / capability_data / inboxes_response)

5.  References

   [RFC2060]  Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 2060, DOI 10.17487/RFC2060, December 1996,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

Author's Address

   Ben van Hartingsveldt (editor)

van Hartingsveldt         Expires May 26, 2020                  [Page 4]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/