Message ORGanization Working Group B. Leiba
Internet-Draft Huawei Technologies
Intended status: Standards Track J. Nicolson
Expires: December 20, 2010 Google
June 18, 2010
IMAP LIST extension for special-use mailboxes
draft-ietf-morg-list-specialuse-02
Abstract
Some IMAP message stores include special-use mailboxes, such as those
used to hold draft messages or sent messages. Many mail clients
allow users to specify where draft or sent messages should be put,
but configuring them requires that the user know which mailboxes the
server has set aside for these purposes. This extension adds new
mailbox flags that a server MAY include in IMAP LIST command
responses to identify special-use mailboxes to the client, easing
configuration.
Note
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, and should be sent to
morg@ietf.org.
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 http://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 December 20, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Leiba & Nicolson Expires December 20, 2010 [Page 1]
Internet-Draft IMAP LIST: special-use mailboxes June 2010
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 3
1.2. Change log . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . . 3
2. New mailbox flags identifying special-use mailboxes . . . . 4
3. Extension to IMAP CREATE command to set special-use
flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Example of an IMAP LIST command . . . . . . . . . . . . . . 6
4.2. Example of an extended IMAP LIST command . . . . . . . . . 6
4.3. Example of an IMAP CREATE command . . . . . . . . . . . . . 6
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
7.1. Registration of CREATE-SPECIAL-USE IMAP capability . . . . 8
7.2. Registration of SPECIAL-USE return option . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 9
Leiba & Nicolson Expires December 20, 2010 [Page 2]
Internet-Draft IMAP LIST: special-use mailboxes June 2010
1. Introduction
Some IMAP message stores include special-use mailboxes, such as those
used to hold draft messages or sent messages. Many mail clients
allow users to specify where draft or sent messages should be put,
but configuring them requires that the user know which mailboxes the
server has set aside for these purposes. This extension adds new
mailbox flags that a server MAY include in IMAP LIST command
responses to identify special-use mailboxes to the client, easing
configuration.
In addition, this extension adds an OPTIONAL parameter on the IMAP
CREATE command, allowing a client to assign a special use to a
mailbox when it is created. Servers MAY choose to support this part
of the extension, but are not required to.
1.1. Conventions used in this document
In examples, "C:" indicates lines sent by a client that is connected
to a server. "S:" indicates lines sent by the server to the client.
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 [RFC2119].
1.2. Change log
[[RFC EDITOR: Please remove this section and its subsections.]]
1.2.1. Changes from -00 to -01
Added wording about list-extended; added reference to RFC 5258;
added example; added registration of list-extended return option.
Changed CREATE syntax to use RFC 4466; added reference to RFC
4466; fixed example.
Added "\Archive" use flag.
Noted that multiple mailboxes might have the same flag in some
implementations.
Changed some use flag names to be more general: \All (was
\AllMail), \Junk (was \Spam), \Flagged (was \Starred).
Leiba & Nicolson Expires December 20, 2010 [Page 3]
Internet-Draft IMAP LIST: special-use mailboxes June 2010
2. New mailbox flags identifying special-use mailboxes
An IMAP server that supports this extension MAY include any or all of
the following flags in responses to the non-extended IMAP LIST
command. The new flags are included along with existing flags, such
as "\Marked" and "\Noselect". A given mailbox may have none, one, or
more than one of these flags. In some cases, a special use is advice
to a client about what to put in that mailbox. In other cases, it's
advice to a client about what to expect to find there.
For the extended list command [RFC5258], this extension adds a new
return option, "SPECIAL-USE". The new special-use flags SHOULD be
returned if the client specifies the SPECIAL-USE return option, and
MAY be returned even if the client does not specify it.
The new flags defined here are as follows:
\Drafts
This mailbox is used to hold draft messages -- typically,
messages that are being composed but have not yet been sent. In
some server implementations, this might be a virtual mailbox,
containing messages from other mailboxes that are marked with
the "\Draft" message flag. Alternatively, this might just be
advice that a client put drafts here.
\Flagged
This mailbox presents all messages marked in some way as
"important". When this special use is supported, it is likely
to represent a virtual mailbox collecting messages (from other
mailboxes) that are marked with the "\Flagged" message flag.
\Junk
This mailbox is where messages deemed to be junk mail are held.
Some server implementations might put messages here
automatically. Alternatively, this might just be advice to a
client-side spam filter.
\Sent
This mailbox is used to hold copies of messages that have been
sent. Some server implementations might put messages here
automatically. Alternatively, this might just be advice that a
client save sent messages here.
\Trash
This mailbox is used to hold messages that have been deleted, or
marked for deletion. In some server implementations, this might
be a virtual mailbox, containing messages from other mailboxes
that are marked with the "\Deleted" message flag.
Leiba & Nicolson Expires December 20, 2010 [Page 4]
Internet-Draft IMAP LIST: special-use mailboxes June 2010
Alternatively, this might just be advice that a client that
chooses not to use the IMAP "\Deleted" model should use this as
its trash location. In server implementations that strictly
expect the IMAP "\Deleted" model, this special use is likely not
to be supported.
\All
This mailbox presents all messages in the user's message store.
Implementations MAY omit some messages, such as, perhaps, those
in \Trash and \Junk. When this special use is supported, it is
almost certain to represent a virtual mailbox.
\Archive
This mailbox is used to archive messages. The meaning of an
"archival" mailbox is server-dependent; typically, it will be
used to get messages out of the inbox, or otherwise keep them
out of the user's way, while still making them accessible.
All of the above flags are OPTIONAL, and any given server or message
store may support any combination of the flags, or none at all. In
some server or message store implementations it might be possible for
multiple mailboxes to have the same special-use flag. There is no
capability string associated with this feature.
3. Extension to IMAP CREATE command to set special-use flags
As an OPTIONAL feature, a server MAY allow clients to designate a
mailbox, at creation, as having one or more special uses. This
extension defines the "USE" parameter to the IMAP CREATE command for
that purpose (using the syntax defined in RFC 4466 section 2.2
[RFC4466]). The new OPTIONAL "USE" parameter is followed by a
parenthesized list of zero or more special-use flags, as defined
above.
In some server implementations, some special uses may imply automatic
action by the server. For example, creation of a "\Junk" mailbox
might cause the server to start placing messages that have been
evaluated as spam into the mailbox.
In some server implementations, some special uses may result in a
mailbox with unusual characteristics or side effects. For example,
creation of an "\All" mailbox might cause the server to create a
virtual mailbox, rather than a standard one, and that mailbox might
behave in unexpected ways (COPY into it might fail, for example).
Servers MAY allow the creation of a special-use mailbox even if one
so designated already exists, having the effect of moving the special
Leiba & Nicolson Expires December 20, 2010 [Page 5]
Internet-Draft IMAP LIST: special-use mailboxes June 2010
use from the old mailbox to the new one. Alternatively, servers MAY
refuse the creation, considering the designation to be a conflict.
If the server can not create a mailbox with the designated special
use defined, for whatever reason, it MUST NOT create the mailbox, and
MUST respond to the CREATE command with a tagged NO response.
An IMAP server that supports this OPTIONAL feature will advertise the
CREATE-SPECIAL-USE capability string. Clients MUST NOT use the "USE"
parameter unless the server advertises the capability.
4. Examples
4.1. Example of an IMAP LIST command
This example shows an IMAP LIST response from a server that supports
this extension. Note that not all of the flags are used. This
server also supports the Child Mailbox extension [RFC3348].
C: t1 LIST "" "%"
S: * LIST (\Marked \HasNoChildren) "/" Inbox
S: * LIST (\HasNoChildren) "/" ToDo
S: * LIST (\HasChildren) "/" Projects
S: * LIST (\Sent \HasNoChildren) "/" SentMail
S: * LIST (\Marked \Drafts \HasNoChildren) "/" MyDrafts
S: * LIST (\Trash \HasNoChildren) "/" Trash
S: t1 OK done
4.2. Example of an extended IMAP LIST command
This example shows an IMAP LIST response from a server that supports
this extension. The client uses the extended IMAP LIST command.
C: t1 LIST "" "%" RETURN (SPECAL-USE)
S: * LIST (\Marked) "/" Inbox
S: * LIST () "/" ToDo
S: * LIST () "/" Projects
S: * LIST (\Sent) "/" SentMail
S: * LIST (\Marked \Drafts) "/" MyDrafts
S: * LIST (\Trash) "/" Trash
S: t1 OK done
4.3. Example of an IMAP CREATE command
This example shows an IMAP CREATE command that might be used to
create a mailbox designated to hold draft and sent messages. It also
attempts to create a mailbox that will contain all the user's
Leiba & Nicolson Expires December 20, 2010 [Page 6]
Internet-Draft IMAP LIST: special-use mailboxes June 2010
messages, but the server does not support that special use for this
user's message store.
C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 CREATE-SPECIAL-USE
S: t1 OK done
C: t2 CREATE MySpecial (USE (\Drafts \Sent))
S: t2 OK MySpecial created
C: t3 CREATE Everything (USE (\All))
S: t3 NO \All not supported
5. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [RFC5234].
create-param =/ "USE" SP "(" [use-flag *(SP use-flag)] ")"
; Extends "create-param" from RFC 4466 [RFC4466]
mbx-list-oflag =/ use-flag
; Extends "mbx-list-oflag" from IMAP base [RFC3501]
return-option =/ "SPECIAL-USE"
; Extends "return-option" from
; LIST-extended [RFC5258]
use-flag = "\All" / "\Archive" / "\Drafts" / "\Flagged" /
"\Junk" / "\Sent" / "\Trash" / use-flag-ext
use-flag-ext = "\" atom
; Reserved for future extensions. Clients
; MUST ignore list flags they do not understand
; Server implementations MUST NOT generate
; extension flags except as defined by
; future standards-track revisions of or
; extensions to this specification.
6. Security Considerations
LIST response: There are no security issues with conveying special-
use information to a client.
CREATE command "USE" parameter: In some server implementations, some
special uses may imply automatic action by the server. For example,
creation of a "\Junk" mailbox might cause the server to start placing
messages that have been evaluated as spam into the mailbox. Server
Leiba & Nicolson Expires December 20, 2010 [Page 7]
Internet-Draft IMAP LIST: special-use mailboxes June 2010
implementors SHOULD consider the consequences of allowing a user (or
client program) to designate the target of such automatic action.
7. IANA Considerations
7.1. Registration of CREATE-SPECIAL-USE IMAP capability
This document defines a new IMAP capability. IANA is asked to add
"CREATE-SPECIAL-USE" to the imap4-capabilities registry.
7.2. Registration of SPECIAL-USE return option
This document defines a new IMAP4 List Extended return option. IANA
is asked to add "SPECIAL-USE" to the imap4-list-extended registry, as
follows:
To: iana@iana.org
Subject: Registration of LIST-EXTENDED option SPECIAL-USE
LIST-EXTENDED option name: SPECIAL-USE
LIST-EXTENDED option type: RETURN
LIST-EXTENDED option description: Request special-use mailbox
information
Published specification: [[this RFC]]
Security considerations: none
Intended usage: COMMON
Person and email address to contact for further information: Authors'
Addresses at the end of [[this RFC]]
Owner/Change controller: iesg@ietf.org
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3501] Crispin, M., Ed., "Internet Message Access Protocol",
RFC 3501, March 2003.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
Leiba & Nicolson Expires December 20, 2010 [Page 8]
Internet-Draft IMAP LIST: special-use mailboxes June 2010
Protocol version 4 - LIST Command Extensions", RFC 5258,
June 2008.
8.2. Informative References
[RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action
Protocol (IMAP4) Child Mailbox Extension", RFC 3348,
July 2002.
Authors' Addresses
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
Jamie Nicolson
Google
Email: nicolson@google.com
Leiba & Nicolson Expires December 20, 2010 [Page 9]
