PIM
/
offlineimap
mirror of https://github.com/OfflineIMAP/offlineimap.git
1
0
Fork 0
Code Issues Releases Wiki Activity

rfcs: update RFCs and provide better filenames 

Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
This commit is contained in:
Nicolas Sebrecht 2015-03-06 21:27:52 +01:00
parent 5ecd557dfb
commit 2377353cae
63 changed files with 20499 additions and 7239 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/rfcs/README.md
View File

@ -1,6 +1,4 @@
All RFCs related to IMAP.
TODO:
- rename the files to know what they are talking about.
- Add a brief introduction here to introduce the most important RFCs.
TODO: Add a brief introduction here to introduce the most important RFCs.

0
docs/rfcs/rfc1731.txt → docs/rfcs/rfc1731.IMAP4_auth.txt
View File

0
docs/rfcs/rfc1732.txt → docs/rfcs/rfc1732.compatibiliy_IMAP2-IMAP2bis.txt
View File

0
docs/rfcs/rfc1733.txt → docs/rfcs/rfc1733.models_in_IMAP4.txt
View File

439
docs/rfcs/rfc1734.POP3_AUTHentication Normal file
View File

@ -0,0 +1,439 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="robots" content="index,follow" />
<meta name="creator" content="rfcmarkup version 1.111" />
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<meta name="DC.Identifier" content="urn:ietf:rfc:1734" />
<meta name="DC.Description.Abstract" content="This document describes the optional AUTH command, for indicating an
authentication mechanism to the server, performing an authentication
protocol exchange, and optionally negotiating a protection mechanism
for subsequent protocol interactions. [STANDARDS-TRACK]" />
<meta name="DC.Creator" content="J. Myers" />
<meta name="DC.Date.Issued" content="December, 1994" />
<meta name="DC.Title" content="POP3 AUTHentication command" />
<link rel="icon" href="/images/rfc.png" type="image/png" />
<link rel="shortcut icon" href="/images/rfc.png" type="image/png" />
<title>RFC 1734 - POP3 AUTHentication command</title>
<style type="text/css">
body {
margin: 0px 8px;
font-size: 1em;
}
h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
font-weight: bold;
line-height: 0pt;
display: inline;
white-space: pre;
font-family: monospace;
font-size: 1em;
font-weight: bold;
}
pre {
font-size: 1em;
margin-top: 0px;
margin-bottom: 0px;
}
.pre {
white-space: pre;
font-family: monospace;
}
.header{
font-weight: bold;
}
.newpage {
page-break-before: always;
}
.invisible {
text-decoration: none;
color: white;
}
a.selflink {
color: black;
text-decoration: none;
}
@media print {
body {
font-family: monospace;
font-size: 10.5pt;
}
h1, h2, h3, h4, h5, h6 {
font-size: 1em;
}
a:link, a:visited {
color: inherit;
text-decoration: none;
}
.noprint {
display: none;
}
}
@media screen {
.grey, .grey a:link, .grey a:visited {
color: #777;
}
.docinfo {
background-color: #EEE;
}
.top {
border-top: 7px solid #EEE;
}
.bgwhite { background-color: white; }
.bgred { background-color: #F44; }
.bggrey { background-color: #666; }
.bgbrown { background-color: #840; }
.bgorange { background-color: #FA0; }
.bgyellow { background-color: #EE0; }
.bgmagenta{ background-color: #F4F; }
.bgblue { background-color: #66F; }
.bgcyan { background-color: #4DD; }
.bggreen { background-color: #4F4; }
.legend { font-size: 90%; }
.cplate { font-size: 70%; border: solid grey 1px; }
}
</style>
<!--[if IE]>
<style>
body {
font-size: 13px;
margin: 10px 10px;
}
</style>
<![endif]-->
<script type="text/javascript"><!--
function addHeaderTags() {
var spans = document.getElementsByTagName("span");
for (var i=0; i < spans.length; i++) {
var elem = spans[i];
if (elem) {
var level = elem.getAttribute("class");
if (level == "h1" || level == "h2" || level == "h3" || level == "h4" || level == "h5" || level == "h6") {
elem.innerHTML = "<"+level+">"+elem.innerHTML+"</"+level+">";
}
}
}
}
var legend_html = "Colour legend:<br /> <table> <tr><td>Unknown:</td> <td><span class='cplate bgwhite'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Draft:</td> <td><span class='cplate bgred'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Informational:</td> <td><span class='cplate bgorange'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Experimental:</td> <td><span class='cplate bgyellow'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Best Common Practice:</td> <td><span class='cplate bgmagenta'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Proposed Standard:</td> <td><span class='cplate bgblue'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Internet Standard:</td> <td><span class='cplate bggreen'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Historic:</td> <td><span class='cplate bggrey'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Obsolete:</td> <td><span class='cplate bgbrown'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> </table>";
function showElem(id) {
var elem = document.getElementById(id);
elem.innerHTML = eval(id+"_html");
elem.style.visibility='visible';
}
function hideElem(id) {
var elem = document.getElementById(id);
elem.style.visibility='hidden';
elem.innerHTML = "";
}
// -->
</script>
</head>
<body onload="addHeaderTags()">
<div style="height: 13px;">
<div onmouseover="this.style.cursor='pointer';"
onclick="showElem('legend');"
onmouseout="hideElem('legend')"
style="height: 6px; position: absolute;"
class="pre noprint docinfo bgbrown"
title="Click for colour legend." > </div>
<div id="legend"
class="docinfo noprint pre legend"
style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; "
onmouseover="showElem('legend');"
onmouseout="hideElem('legend');">
</div>
</div>
<span class="pre noprint docinfo top">[<a href="../html/" title="Document search and retrieval page">Docs</a>] [<a href="/rfc/rfc1734.txt" title="Plaintext version of this document">txt</a>|<a href="/pdf/rfc1734" title="PDF version of this document">pdf</a>] [<a href="./draft-myers-pop3-auth" title="draft-myers-pop3-auth">draft-myers-pop3-...</a>] [<a href="/rfcdiff?difftype=--hwdiff&amp;url2=rfc1734" title="Inline diff (wdiff)">Diff1</a>] [<a href="/rfcdiff?url2=rfc1734" title="Side-by-side diff">Diff2</a>] </span><br />
<span class="pre noprint docinfo"> </span><br />
<span class="pre noprint docinfo">Obsoleted by: <a href="./rfc5034">5034</a> PROPOSED STANDARD</span><br />
<span class="pre noprint docinfo"> </span><br />
<pre>
Network Working Group J. Myers
Request for Comments: 1734 Carnegie Mellon
Category: Standards Track December 1994
<span class="h1">POP3 AUTHentication command</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
<span class="h2"><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</span>
This document describes the optional AUTH command, for indicating an
authentication mechanism to the server, performing an authentication
protocol exchange, and optionally negotiating a protection mechanism
for subsequent protocol interactions. The authentication and
protection mechanisms used by the POP3 AUTH command are those used by
IMAP4.
<span class="h2"><a class="selflink" name="section-2" href="#section-2">2</a>. The AUTH command</span>
AUTH mechanism
Arguments:
a string identifying an IMAP4 authentication mechanism,
such as defined by [<a href="#ref-IMAP4-AUTH" title="&quot;IMAP4 Authentication Mechanisms&quot;">IMAP4-AUTH</a>]. Any use of the string
"imap" used in a server authentication identity in the
definition of an authentication mechanism is replaced with
the string "pop".
Restrictions:
may only be given in the AUTHORIZATION state
Discussion:
The AUTH command indicates an authentication mechanism to
the server. If the server supports the requested
authentication mechanism, it performs an authentication
protocol exchange to authenticate and identify the user.
Optionally, it also negotiates a protection mechanism for
subsequent protocol interactions. If the requested
authentication mechanism is not supported, the server
<span class="grey">Myers [Page 1]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a>
<span class="grey"><a href="./rfc1734">RFC 1734</a> POP3 AUTH December 1994</span>
should reject the AUTH command by sending a negative
response.
The authentication protocol exchange consists of a series
of server challenges and client answers that are specific
to the authentication mechanism. A server challenge,
otherwise known as a ready response, is a line consisting
of a "+" character followed by a single space and a BASE64
encoded string. The client answer consists of a line
containing a BASE64 encoded string. If the client wishes
to cancel an authentication exchange, it should issue a
line with a single "*". If the server receives such an
answer, it must reject the AUTH command by sending a
negative response.
A protection mechanism provides integrity and privacy
protection to the protocol session. If a protection
mechanism is negotiated, it is applied to all subsequent
data sent over the connection. The protection mechanism
takes effect immediately following the CRLF that concludes
the authentication exchange for the client, and the CRLF of
the positive response for the server. Once the protection
mechanism is in effect, the stream of command and response
octets is processed into buffers of ciphertext. Each
buffer is transferred over the connection as a stream of
octets prepended with a four octet field in network byte
order that represents the length of the following data.
The maximum ciphertext buffer length is defined by the
protection mechanism.
The server is not required to support any particular
authentication mechanism, nor are authentication mechanisms
required to support any protection mechanisms. If an AUTH
command fails with a negative response, the session remains
in the AUTHORIZATION state and client may try another
authentication mechanism by issuing another AUTH command,
or may attempt to authenticate by using the USER/PASS or
APOP commands. In other words, the client may request
authentication types in decreasing order of preference,
with the USER/PASS or APOP command as a last resort.
Should the client successfully complete the authentication
exchange, the POP3 server issues a positive response and
the POP3 session enters the TRANSACTION state.
Possible Responses:
+OK maildrop locked and ready
-ERR authentication exchange failed
<span class="grey">Myers [Page 2]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a>
<span class="grey"><a href="./rfc1734">RFC 1734</a> POP3 AUTH December 1994</span>
Examples:
S: +OK POP3 server ready
C: AUTH KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: +OK Kerberos V4 authentication successful
...
C: AUTH FOOBAR
S: -ERR Unrecognized authentication type
Note: the line breaks in the first client answer are
for editorial clarity and are not in real authentica-
tors.
<span class="grey">Myers [Page 3]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a>
<span class="grey"><a href="./rfc1734">RFC 1734</a> POP3 AUTH December 1994</span>
<span class="h2"><a class="selflink" name="section-3" href="#section-3">3</a>. Formal Syntax</span>
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in <a href="./rfc822">RFC 822</a>.
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.
ATOM_CHAR ::= &lt;any CHAR except atom_specials&gt;
atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" /
&lt;"&gt; / "\"
auth ::= "AUTH" 1*(SPACE / TAB) auth_type *(CRLF base64)
CRLF
auth_type ::= 1*ATOM_CHAR
base64 ::= *(4base64_CHAR) [base64_terminal]
base64_char ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
"I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
"Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
"Y" / "Z" /
"a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
"i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
"q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
"y" / "z" /
"0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
"8" / "9" / "+" / "/"
;; Case-sensitive
base64_terminal ::= (2base64_char "==") / (3base64_char "=")
CHAR ::= &lt;any 7-bit US-ASCII character except NUL,
0x01 - 0x7f&gt;
continue_req ::= "+" SPACE base64 CRLF
CR ::= &lt;ASCII CR, carriage return, 0x0C&gt;
CRLF ::= CR LF
CTL ::= &lt;any ASCII control character and DEL,
0x00 - 0x1f, 0x7f&gt;
<span class="grey">Myers [Page 4]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a>
<span class="grey"><a href="./rfc1734">RFC 1734</a> POP3 AUTH December 1994</span>
LF ::= &lt;ASCII LF, line feed, 0x0A&gt;
SPACE ::= &lt;ASCII SP, space, 0x20&gt;
TAB ::= &lt;ASCII HT, tab, 0x09&gt;
<span class="h2"><a class="selflink" name="section-4" href="#section-4">4</a>. References</span>
[<a name="ref-IMAP4-AUTH" id="ref-IMAP4-AUTH">IMAP4-AUTH</a>] Myers, J., "IMAP4 Authentication Mechanisms", <a href="./rfc1731">RFC 1731</a>,
Carnegie Mellon, December 1994.
<span class="h2"><a class="selflink" name="section-5" href="#section-5">5</a>. Security Considerations</span>
Security issues are discussed throughout this memo.
<span class="h2"><a class="selflink" name="section-6" href="#section-6">6</a>. Author's Address</span>
John G. Myers
Carnegie-Mellon University
5000 Forbes Ave
Pittsburgh, PA 15213
EMail: jgm+@cmu.edu
Myers [Page 5]
</pre><br />
<span class="noprint"><small><small>Html markup produced by rfcmarkup 1.111, available from
<a href="https://tools.ietf.org/tools/rfcmarkup/">https://tools.ietf.org/tools/rfcmarkup/</a>
</small></small></span>
</body></html>

1291
docs/rfcs/rfc1939.txt
View File

File diff suppressed because it is too large Load Diff

0
docs/rfcs/rfc2061.txt → docs/rfcs/rfc2061.compatibility_IMAP4-IMAP2bis.txt
View File

451
docs/rfcs/rfc2062.txt
View File

@ -1,451 +0,0 @@
Network Working Group M. Crispin
Request for Comments: 2062 University of Washington
Category: Informational December 1996
Internet Message Access Protocol - Obsolete Syntax
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document describes obsolete syntax which may be encountered by
IMAP4 implementations which deal with older versions of the Internet
Mail Access Protocol. IMAP4 implementations MAY implement this
syntax in order to maximize interoperability with older
implementations.
This document repeats information from earlier documents, most
notably RFC 1176 and RFC 1730.
Obsolete Commands and Fetch Data Items
The following commands are OBSOLETE. It is NOT required to support
any of these commands or fetch data items in new server
implementations. These commands are documented here for the benefit
of implementors who may wish to support them for compatibility with
old client implementations.
The section headings of these commands are intended to correspond
with where they would be located in the main document if they were
not obsoleted.
6.3.OBS.1. FIND ALL.MAILBOXES Command
Arguments: mailbox name with possible wildcards
Data: untagged responses: MAILBOX
Result: OK - find completed
NO - find failure: can't list that name
BAD - command unknown or arguments invalid
Crispin Informational [Page 1]
RFC 2062 IMAP4 Obsolete December 1996
The FIND ALL.MAILBOXES command returns a subset of names from the
complete set of all names available to the user. It returns zero
or more untagged MAILBOX replies. The mailbox argument to FIND
ALL.MAILBOXES is similar to that for LIST with an empty reference,
except that the characters "%" and "?" match a single character.
Example: C: A002 FIND ALL.MAILBOXES *
S: * MAILBOX blurdybloop
S: * MAILBOX INBOX
S: A002 OK FIND ALL.MAILBOXES completed
6.3.OBS.2. FIND MAILBOXES Command
Arguments: mailbox name with possible wildcards
Data: untagged responses: MAILBOX
Result: OK - find completed
NO - find failure: can't list that name
BAD - command unknown or arguments invalid
The FIND MAILBOXES command returns a subset of names from the set
of names that the user has declared as being "active" or
"subscribed". It returns zero or more untagged MAILBOX replies.
The mailbox argument to FIND MAILBOXES is similar to that for LSUB
with an empty reference, except that the characters "%" and "?"
match a single character.
Example: C: A002 FIND MAILBOXES *
S: * MAILBOX blurdybloop
S: * MAILBOX INBOX
S: A002 OK FIND MAILBOXES completed
6.3.OBS.3. SUBSCRIBE MAILBOX Command
Arguments: mailbox name
Data: no specific data for this command
Result: OK - subscribe completed
NO - subscribe failure: can't subscribe to that name
BAD - command unknown or arguments invalid
The SUBSCRIBE MAILBOX command is identical in effect to the
SUBSCRIBE command. A server which implements this command must be
able to distinguish between a SUBSCRIBE MAILBOX command and a
SUBSCRIBE command with a mailbox name argument of "MAILBOX".
Crispin Informational [Page 2]
RFC 2062 IMAP4 Obsolete December 1996
Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
completed
C: A003 SUBSCRIBE MAILBOX
S: A003 OK SUBSCRIBE to MAILBOX completed
6.3.OBS.4. UNSUBSCRIBE MAILBOX Command
Arguments: mailbox name
Data: no specific data for this command
Result: OK - unsubscribe completed
NO - unsubscribe failure: can't unsubscribe that name
BAD - command unknown or arguments invalid
The UNSUBSCRIBE MAILBOX command is identical in effect to the
UNSUBSCRIBE command. A server which implements this command must
be able to distinguish between a UNSUBSCRIBE MAILBOX command and
an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
completed
C: A003 UNSUBSCRIBE MAILBOX
S: A003 OK UNSUBSCRIBE from MAILBOX completed
6.4.OBS.1 PARTIAL Command
Arguments: message sequence number
message data item name
position of first octet
number of octets
Data: untagged responses: FETCH
Result: OK - partial completed
NO - partial error: can't fetch that data
BAD - command unknown or arguments invalid
The PARTIAL command is equivalent to the associated FETCH command,
with the added functionality that only the specified number of
octets, beginning at the specified starting octet, are returned.
Only a single message can be fetched at a time. The first octet
of a message, and hence the minimum for the starting octet, is
octet 1.
Crispin Informational [Page 3]
RFC 2062 IMAP4 Obsolete December 1996
The following FETCH items are valid data for PARTIAL: RFC822,
RFC822.HEADER, RFC822.TEXT, BODY[<section>], as well as any .PEEK
forms of these.
Any partial fetch that attempts to read beyond the end of the text
is truncated as appropriate. If the starting octet is beyond the
end of the text, an empty string is returned.
The data are returned with the FETCH response. There is no
indication of the range of the partial data in this response. It
is not possible to stream multiple PARTIAL commands of the same
data item without processing and synchronizing at each step, since
streamed commands may be executed out of order.
There is no requirement that partial fetches follow any sequence.
For example, if a partial fetch of octets 1 through 10000 breaks
in an awkward place for BASE64 decoding, it is permitted to
continue with a partial fetch of 9987 through 19987, etc.
The handling of the \Seen flag is the same as in the associated
FETCH command.
Example: C: A005 PARTIAL 4 RFC822 1 1024
S: * 1 FETCH (RFC822 {1024}
S: Return-Path: <gray@cac.washington.edu>
S: ...
S: ......... FLAGS (\Seen))
S: A005 OK PARTIAL completed
6.4.5.OBS.1 Obsolete FETCH Data Items
The following FETCH data items are obsolete:
BODY[<...>0] A body part number of 0 is the [RFC-822] header of
the message. BODY[0] is functionally equivalent to
BODY[HEADER], differing in the syntax of the
resulting untagged FETCH data (BODY[0] is
returned).
RFC822.HEADER.LINES <header_list>
Functionally equivalent to BODY.PEEK[HEADER.LINES
<header_list>], differing in the syntax of the
resulting untagged FETCH data (RFC822.HEADER is
returned).
Crispin Informational [Page 4]
RFC 2062 IMAP4 Obsolete December 1996
RFC822.HEADER.LINES.NOT <header_list>
Functionally equivalent to
BODY.PEEK[HEADER.LINES.NOT <header_list>],
differing in the syntax of the resulting untagged
FETCH data (RFC822.HEADER is returned).
RFC822.PEEK Functionally equivalent to BODY.PEEK[], except for
the syntax of the resulting untagged FETCH data
(RFC822 is returned).
RFC822.TEXT.PEEK
Functionally equivalent to BODY.PEEK[TEXT], except
for the syntax of the resulting untagged FETCH data
(RFC822.TEXT is returned).
Obsolete Responses
The following responses are OBSOLETE. Except as noted below, these
responses MUST NOT be transmitted by new server implementations.
Client implementations SHOULD accept these responses.
The section headings of these responses are intended to correspond
with where they would be located in the main document if they were
not obsoleted.
7.2.OBS.1. MAILBOX Response
Data: name
The MAILBOX response MUST NOT be transmitted by server
implementations except in response to the obsolete FIND MAILBOXES
and FIND ALL.MAILBOXES commands. Client implementations that do
not use these commands MAY ignore this response. It is documented
here for the benefit of implementors who may wish to support it
for compatibility with old client implementations.
This response occurs as a result of the FIND MAILBOXES and FIND
ALL.MAILBOXES commands. It returns a single name that matches the
FIND specification. There are no attributes or hierarchy
delimiter.
Example: S: * MAILBOX blurdybloop
Crispin Informational [Page 5]
RFC 2062 IMAP4 Obsolete December 1996
7.3.OBS.1. COPY Response
Data: none
The COPY response MUST NOT be transmitted by new server
implementations. Client implementations MUST ignore the COPY
response. It is documented here for the benefit of client
implementors who may encounter this response from old server
implementations.
In some experimental versions of this protocol, this response was
returned in response to a COPY command to indicate on a
per-message basis that the message was copied successfully.
Example: S: * 44 COPY
7.3.OBS.2. STORE Response
Data: message data
The STORE response MUST NOT be transmitted by new server
implementations. Client implementations MUST treat the STORE
response as equivalent to the FETCH response. It is documented
here for the benefit of client implementors who may encounter this
response from old server implementations.
In some experimental versions of this protocol, this response was
returned instead of FETCH in response to a STORE command to report
the new value of the flags.
Example: S: * 69 STORE (FLAGS (\Deleted))
Formal Syntax of Obsolete Commands and Responses
Each obsolete syntax rule that is suffixed with "_old" is added to
the corresponding name in the formal syntax. For example,
command_auth_old adds the FIND command to command_auth.
command_auth_old ::= find
command_select_old
::= partial
date_year_old ::= 2digit
;; (year - 1900)
date_time_old ::= <"> date_day_fixed "-" date_month "-" date_year
SPACE time "-" zone_name <">
Crispin Informational [Page 6]
RFC 2062 IMAP4 Obsolete December 1996
find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
list_mailbox
fetch_att_old ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list /
fetch_text_old
fetch_text_old ::= "BODY" [".PEEK"] section_old /
"RFC822" [".HEADER" / ".TEXT" [".PEEK"]]
msg_data_old ::= "COPY" / ("STORE" SPACE msg_att)
partial ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old SPACE
number SPACE number
section_old ::= "[" (number ["." number]) "]"
subscribe_old ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
zone_name ::= "UT" / "GMT" / "Z" / ;; +0000
"AST" / "EDT" / ;; -0400
"EST" / "CDT" / ;; -0500
"CST" / "MDT" / ;; -0600
"MST" / "PDT" / ;; -0700
"PST" / "YDT" / ;; -0800
"YST" / "HDT" / ;; -0900
"HST" / "BDT" / ;; -1000
"BST" / ;; -1100
"A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
"G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
"N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
"T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12
Security Considerations
Security issues are not discussed in this memo.
Crispin Informational [Page 7]
RFC 2062 IMAP4 Obsolete December 1996
Author's Address
Mark R. Crispin
Networks and Distributed Computing
University of Washington
4545 15th Aveneue NE
Seattle, WA 98105-4527
Phone: (206) 543-5762
EMail: MRC@CAC.Washington.EDU
Crispin Informational [Page 8]

0
docs/rfcs/rfc2086.txt → docs/rfcs/rfc2086.IMAP4_ACL_extension.txt
View File

0
docs/rfcs/rfc2087.txt → docs/rfcs/rfc2087.IMAP4_QUOTA_extension.txt
View File

0
docs/rfcs/rfc2088.txt → docs/rfcs/rfc2088.IMAP4_non_synchronizing_literals.txt
View File

0
docs/rfcs/rfc2095.txt → docs/rfcs/rfc2095.IMAP-POP_AUTHorize_extension.txt
View File

0
docs/rfcs/rfc2177.txt → docs/rfcs/rfc2177.IMAP4_IDLE_command.txt
View File

0
docs/rfcs/rfc2180.txt → docs/rfcs/rfc2180.IMAP4_multi-accessed_Mailbox_practice.txt
View File

0
docs/rfcs/rfc2192.txt → docs/rfcs/rfc2192.IMAP_URL_scheme.txt
View File

0
docs/rfcs/rfc2193.txt → docs/rfcs/rfc2193.IMAP4_Mailbox_referrals.txt
View File

0
docs/rfcs/rfc2195.txt → docs/rfcs/rfc2195.IMAP-POP_AUTHorize_extension.txt
View File

0
docs/rfcs/rfc2221.txt → docs/rfcs/rfc2221.IMAP4_Login_referrals.txt
View File

0
docs/rfcs/rfc2244.txt → docs/rfcs/rfc2244.ACAP.txt
View File

0
docs/rfcs/rfc2342.txt → docs/rfcs/rfc2342.IMAP4_Namespace.txt
View File

0
docs/rfcs/rfc2359.txt → docs/rfcs/rfc2359.IMAP4_UIDPLUS_extension.txt
View File

0
docs/rfcs/rfc2595.txt → docs/rfcs/rfc2595.TLS_with_IMAP-POP3_and_ACAP.txt
View File

0
docs/rfcs/rfc2683.txt → docs/rfcs/rfc2683.IMAP4_Implementation_recommendations.txt
View File

4427
docs/rfcs/rfc2821.txt
View File

File diff suppressed because it is too large Load Diff

1515
docs/rfcs/rfc2831.Obsolete_Digest_AUTHentication_as_a_SASL_mech.txt Normal file
View File

File diff suppressed because it is too large Load Diff

0
docs/rfcs/rfc2971.txt → docs/rfcs/rfc2971.IMAP4_ID_extension.txt
View File

0
docs/rfcs/rfc3028.txt → docs/rfcs/rfc3028.Sieve_Mail_filtering_language.txt
View File

0
docs/rfcs/rfc3348.txt → docs/rfcs/rfc3348.IMAP4_Child_Mailbox_extension.txt
View File

0
docs/rfcs/rfc3501.txt → docs/rfcs/rfc3501.IMAP4rev1.txt
View File

0
docs/rfcs/rfc3502.txt → docs/rfcs/rfc3502.MULTIAPPEND_extension.txt
View File

0
docs/rfcs/rfc3503.txt → docs/rfcs/rfc3503.Message_Disposition_Notification.txt
View File

0
docs/rfcs/rfc3516.txt → docs/rfcs/rfc3516.IMAP4_Binary_content_extension.txt
View File

1067
docs/rfcs/rfc3656.txt
View File

File diff suppressed because it is too large Load Diff

0
docs/rfcs/rfc3691.txt → docs/rfcs/rfc3691.IMAP_UNSELECT_command.txt
View File

0
docs/rfcs/rfc4314.txt → docs/rfcs/rfc4314.IMAP4_ACL_extension.txt
View File

0
docs/rfcs/rfc4315.txt → docs/rfcs/rfc4315.IMAP_UIDPLUS_extension.txt
View File

0
docs/rfcs/rfc4466.txt → docs/rfcs/rfc4466.Collected_extensions_to_IMAP4_ABNF.txt
View File

0
docs/rfcs/rfc4467.txt → docs/rfcs/rfc4467.IMAP_URLAUTH_extension.txt
View File

0
docs/rfcs/rfc4469.txt → docs/rfcs/rfc4469.IMAP_CATENATE_extension.txt
View File

0
docs/rfcs/rfc4549.txt → docs/rfcs/rfc4549.Sync_operations_for_disconnected_IMAP4_Clients.txt
View File

0
docs/rfcs/rfc4551.txt → docs/rfcs/rfc4551.IMAP_Conditional_STORE_or_Quick_flag_changes_resync.txt
View File

451
docs/rfcs/rfc4731.IMAP4_Extension_to_SEARCH_command.txt Normal file
View File

@ -0,0 +1,451 @@
Network Working Group A. Melnikov
Request for Comments: 4731 Isode Ltd
Category: Standards Track D. Cridland
Inventure Systems Ltd
November 2006
IMAP4 Extension to SEARCH Command for Controlling
What Kind of Information Is Returned
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands
with several result options, which can control what kind of
information is returned. The following result options are defined:
minimal value, maximal value, all found messages, and number of found
messages.
Table of Contents
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. IMAP Protocol Changes ...........................................2
3.1. New SEARCH/UID SEARCH Result Options .......................2
3.2. Interaction with CONDSTORE extension .......................4
4. Formal Syntax ...................................................5
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Normative References ............................................6
8. Acknowledgments .................................................6
Melnikov & Cridland Standards Track [Page 1]
RFC 4731 IMAP4 Extension to SEARCH November 2006
1. Introduction
[IMAPABNF] extended SEARCH and UID SEARCH commands with result
specifiers (also known as result options), which can control what
kind of information is returned.
A server advertising the ESEARCH capability supports the following
result options: minimal value, maximal value, all found messages,
and number of found messages. These result options allow clients to
get SEARCH results in more convenient forms, while also saving
bandwidth required to transport the results, for example, by finding
the first unseen message or returning the number of unseen or deleted
messages. Also, when a single MIN or a single MAX result option is
specified, servers can optimize execution of SEARCHes.
2. Conventions Used in This Document
In examples, "C:" and "S:" indicate lines sent by the client and
server, respectively.
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].
3. IMAP Protocol Changes
3.1. New SEARCH/UID SEARCH Result Options
The SEARCH/UID SEARCH commands are extended to allow for the
following result options:
MIN
Return the lowest message number/UID that satisfies the SEARCH
criteria.
If the SEARCH results in no matches, the server MUST NOT
include the MIN result option in the ESEARCH response; however,
it still MUST send the ESEARCH response.
MAX
Return the highest message number/UID that satisfies the SEARCH
criteria.
If the SEARCH results in no matches, the server MUST NOT
include the MAX result option in the ESEARCH response; however,
it still MUST send the ESEARCH response.
Melnikov & Cridland Standards Track [Page 2]
RFC 4731 IMAP4 Extension to SEARCH November 2006
ALL
Return all message numbers/UIDs that satisfy the SEARCH
criteria. Unlike regular (unextended) SEARCH, the messages are
always returned using the sequence-set syntax. A sequence-set
representation may be more compact and can be used as is in a
subsequent command that accepts sequence-set. Note, the client
MUST NOT assume that messages/UIDs will be listed in any
particular order.
If the SEARCH results in no matches, the server MUST NOT
include the ALL result option in the ESEARCH response; however,
it still MUST send the ESEARCH response.
COUNT
Return number of the messages that satisfy the SEARCH criteria.
This result option MUST always be included in the ESEARCH
response.
If one or more result options described above are specified, the
extended SEARCH command MUST return a single ESEARCH response
[IMAPABNF], instead of the SEARCH response.
An extended UID SEARCH command MUST cause an ESEARCH response with
the UID indicator present.
Note that future extensions to this document can allow servers to
return multiple ESEARCH responses for a single extended SEARCH
command. These extensions will have to describe how results from
multiple ESEARCH responses are to be amalgamated.
If the list of result options is empty, that requests the server to
return an ESEARCH response instead of the SEARCH response. This is
equivalent to "(ALL)".
Example: C: A282 SEARCH RETURN (MIN COUNT) FLAGGED
SINCE 1-Feb-1994 NOT FROM "Smith"
S: * ESEARCH (TAG "A282") MIN 2 COUNT 3
S: A282 OK SEARCH completed
Example: C: A283 SEARCH RETURN () FLAGGED
SINCE 1-Feb-1994 NOT FROM "Smith"
S: * ESEARCH (TAG "A283") ALL 2,10:11
S: A283 OK SEARCH completed
The following example demonstrates finding the first unseen message
as returned in the UNSEEN response code on a successful SELECT
command:
Melnikov & Cridland Standards Track [Page 3]
RFC 4731 IMAP4 Extension to SEARCH November 2006
Example: C: A284 SEARCH RETURN (MIN) UNSEEN
S: * ESEARCH (TAG "A284") MIN 4
S: A284 OK SEARCH completed
The following example demonstrates that if the ESEARCH UID indicator
is present, all data in the ESEARCH response is referring to UIDs;
for example, the MIN result specifier will be followed by a UID.
Example: C: A285 UID SEARCH RETURN (MIN MAX) 1:5000
S: * ESEARCH (TAG "A285") UID MIN 7 MAX 3800
S: A285 OK SEARCH completed
The following example demonstrates returning the number of deleted
messages:
Example: C: A286 SEARCH RETURN (COUNT) DELETED
S: * ESEARCH (TAG "A286") COUNT 15
S: A286 OK SEARCH completed
3.2. Interaction with CONDSTORE extension
When the server supports both the ESEARCH and the CONDSTORE
[CONDSTORE] extension, and the client requests one or more result
option described in section 3.1 together with the MODSEQ search
criterion in the same SEARCH/UID SEARCH command, then the server MUST
return the ESEARCH response containing the MODSEQ result option
(described in the following paragraph) instead of the extended SEARCH
response described in section 3.5 of [CONDSTORE].
If the SEARCH/UID SEARCH command contained a single MIN or MAX result
option, the MODSEQ result option contains the mod-sequence for the
found message. If the SEARCH/UID SEARCH command contained both MIN
and MAX result options and no ALL/COUNT option, the MODSEQ result
option contains the highest mod-sequence for the two returned
messages. Otherwise the MODSEQ result option contains the highest
mod-sequence for all messages being returned.
Example: The following example demonstrates how Example 15 from
[CONDSTORE] would look in the presence of one or more result option:
C: a1 SEARCH RETURN (MIN) MODSEQ "/flags/\\draft"
all 620162338
S: * ESEARCH (TAG "a1") MIN 2 MODSEQ 917162488
S: a1 OK Search complete
C: a2 SEARCH RETURN (MAX) MODSEQ "/flags/\\draft"
all 620162338
S: * ESEARCH (TAG "a2") MAX 23 MODSEQ 907162321
Melnikov & Cridland Standards Track [Page 4]
RFC 4731 IMAP4 Extension to SEARCH November 2006
S: a2 OK Search complete
C: a3 SEARCH RETURN (MIN MAX) MODSEQ "/flags/\\draft"
all 620162338
S: * ESEARCH (TAG "a3") MIN 2 MAX 23 MODSEQ 917162488
S: a3 OK Search complete
C: a4 SEARCH RETURN (MIN COUNT) MODSEQ "/flags/\\draft"
all 620162338
S: * ESEARCH (TAG "a4") MIN 2 COUNT 10 MODSEQ 917162500
S: a4 OK Search complete
4. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF].
Non-terminals referenced but not defined below are as defined by
[IMAP4], [CONDSTORE], or [IMAPABNF].
Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lowercase characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
capability =/ "ESEARCH"
search-return-data = "MIN" SP nz-number /
"MAX" SP nz-number /
"ALL" SP sequence-set /
"COUNT" SP number
;; conforms to the generic
;; search-return-data syntax defined
;; in [IMAPABNF]
search-return-opt = "MIN" / "MAX" / "ALL" / "COUNT"
;; conforms to generic search-return-opt
;; syntax defined in [IMAPABNF]
When the CONDSTORE [CONDSTORE] IMAP extension is also supported,
the ABNF is updated as follows:
search-return-data =/ "MODSEQ" SP mod-sequence-value
;; mod-sequence-value is defined
;; in [CONDSTORE]
Melnikov & Cridland Standards Track [Page 5]
RFC 4731 IMAP4 Extension to SEARCH November 2006
5. Security Considerations
In the general case, the IMAP SEARCH/UID SEARCH commands can be CPU
and/or IO intensive, and are seen by some as a potential attack point
for denial of service attacks, so some sites/implementations even
disable them entirely. This is quite unfortunate, as SEARCH command
is one of the best examples demonstrating IMAP advantage over POP3.
The ALL and COUNT return options don't change how SEARCH is working
internally; they only change how information about found messages is
returned. MIN and MAX SEARCH result options described in this
document can lighten the load on IMAP servers that choose to optimize
SEARCHes containing only one or both of them.
It is believed that this extension doesn't raise any additional
security concerns not already discussed in [IMAP4].
6. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track RFC
or an IESG-approved experimental RFC. The registry is currently
located at <http://www.iana.org/assignments/imap4-capabilities>.
This document defines the ESEARCH IMAP capability, which IANA added
to the registry.
7. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[ABNF] Crocker, D. (Ed.) and P. Overell , "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006..
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE", RFC 4551, June 2006.
8. Acknowledgments
Thanks to Michael Wener, Arnt Gulbrandsen, Cyrus Daboo, Mark Crispin,
and Pete Maclean for comments and corrections.
Melnikov & Cridland Standards Track [Page 6]
RFC 4731 IMAP4 Extension to SEARCH November 2006
Authors' Addresses
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex, TW12 2BX
UK
EMail: Alexey.Melnikov@isode.com
Dave A. Cridland
Inventure Systems Limited
EMail: dave.cridland@inventuresystems.co.uk
URL: http://invsys.co.uk/dave/
Melnikov & Cridland Standards Track [Page 7]
RFC 4731 IMAP4 Extension to SEARCH November 2006
Full Copyright Statement
Copyright (C) The IETF Trust (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, THE IETF TRUST,
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.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Melnikov & Cridland Standards Track [Page 8]

507
docs/rfcs/rfc4978.IMAP_Compress_extension.txt Normal file
View File

@ -0,0 +1,507 @@
Network Working Group A. Gulbrandsen
Request for Comments: 4978 Oryx Mail Systems GmbH
Category: Standards Track August 2007
The IMAP COMPRESS Extension
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
The COMPRESS extension allows an IMAP connection to be effectively
and efficiently compressed.
Table of Contents
1. Introduction and Overview .......................................2
2. Conventions Used in This Document ...............................2
3. The COMPRESS Command ............................................3
4. Compression Efficiency ..........................................4
5. Formal Syntax ...................................................6
6. Security Considerations .........................................6
7. IANA Considerations .............................................6
8. Acknowledgements ................................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................7
Gulbrandsen Standards Track [Page 1]
RFC 4978 The IMAP COMPRESS Extension August 2007
1. Introduction and Overview
A server which supports the COMPRESS extension indicates this with
one or more capability names consisting of "COMPRESS=" followed by a
supported compression algorithm name as described in this document.
The goal of COMPRESS is to reduce the bandwidth usage of IMAP.
Compared to PPP compression (see [RFC1962]) and modem-based
compression (see [MNP] and [V42BIS]), COMPRESS offers much better
compression efficiency. COMPRESS can be used together with Transport
Security Layer (TLS) [RFC4346], Simple Authentication and Security
layer (SASL) encryption, Virtual Private Networks (VPNs), etc.
Compared to TLS compression [RFC3749], COMPRESS has the following
(dis)advantages:
- COMPRESS can be implemented easily both by IMAP servers and
clients.
- IMAP COMPRESS benefits from an intimate knowledge of the IMAP
protocol's state machine, allowing for dynamic and aggressive
optimization of the underlying compression algorithm's parameters.
- When the TLS layer implements compression, any protocol using that
layer can transparently benefit from that compression (e.g., SMTP
and IMAP). COMPRESS is specific to IMAP.
In order to increase interoperation, it is desirable to have as few
different compression algorithms as possible, so this document
specifies only one. The DEFLATE algorithm (defined in [RFC1951]) is
standard, widely available and fairly efficient, so it is the only
algorithm defined by this document.
In order to increase interoperation, IMAP servers that advertise this
extension SHOULD also advertise the TLS DEFLATE compression mechanism
as defined in [RFC3749]. IMAP clients MAY use either COMPRESS or TLS
compression, however, if the client and server support both, it is
RECOMMENDED that the client choose TLS compression.
The extension adds one new command (COMPRESS) and no new responses.
2. Conventions Used in This Document
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 [RFC2119].
Formal syntax is defined by [RFC4234] as modified by [RFC3501].
Gulbrandsen Standards Track [Page 2]
RFC 4978 The IMAP COMPRESS Extension August 2007
In the examples, "C:" and "S:" indicate lines sent by the client and
server respectively. "[...]" denotes elision.
3. The COMPRESS Command
Arguments: Name of compression mechanism: "DEFLATE".
Responses: None
Result: OK The server will compress its responses and expects the
client to compress its commands.
NO Compression is already active via another layer.
BAD Command unknown, invalid or unknown argument, or COMPRESS
already active.
The COMPRESS command instructs the server to use the named
compression mechanism ("DEFLATE" is the only one defined) for all
commands and/or responses after COMPRESS.
The client MUST NOT send any further commands until it has seen the
result of COMPRESS. If the response was OK, the client MUST compress
starting with the first command after COMPRESS. If the server
response was BAD or NO, the client MUST NOT turn on compression.
If the server responds NO because it knows that the same mechanism is
active already (e.g., because TLS has negotiated the same mechanism),
it MUST send COMPRESSIONACTIVE as resp-text-code (see [RFC3501],
Section 7.1), and the resp-text SHOULD say which layer compresses.
If the server issues an OK response, the server MUST compress
starting immediately after the CRLF which ends the tagged OK
response. (Responses issued by the server before the OK response
will, of course, still be uncompressed.) If the server issues a BAD
or NO response, the server MUST NOT turn on compression.
For DEFLATE (as for many other compression mechanisms), the
compressor can trade speed against quality. When decompressing there
isn't much of a tradeoff. Consequently, the client and server are
both free to pick the best reasonable rate of compression for the
data they send.
When COMPRESS is combined with TLS (see [RFC4346]) or SASL (see
[RFC4422]) security layers, the sending order of the three extensions
MUST be first COMPRESS, then SASL, and finally TLS. That is, before
data is transmitted it is first compressed. Second, if a SASL
security layer has been negotiated, the compressed data is then
signed and/or encrypted accordingly. Third, if a TLS security layer
has been negotiated, the data from the previous step is signed and/or
Gulbrandsen Standards Track [Page 3]
RFC 4978 The IMAP COMPRESS Extension August 2007
encrypted accordingly. When receiving data, the processing order
MUST be reversed. This ensures that before sending, data is
compressed before it is encrypted, independent of the order in which
the client issues COMPRESS, AUTHENTICATE, and STARTTLS.
The following example illustrates how commands and responses are
compressed during a simple login sequence:
S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
C: a starttls
S: a OK TLS active
From this point on, everything is encrypted.
C: b login arnt tnra
S: b OK Logged in as arnt
C: c compress deflate
S: d OK DEFLATE active
From this point on, everything is compressed before being
encrypted.
The following example demonstrates how a server may refuse to
compress twice:
S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
[...]
C: c compress deflate
S: c NO [COMPRESSIONACTIVE] DEFLATE active via TLS
4. Compression Efficiency
This section is informative, not normative.
IMAP poses some unusual problems for a compression layer.
Upstream is fairly simple. Most IMAP clients send the same few
commands again and again, so any compression algorithm that can
exploit repetition works efficiently. The APPEND command is an
exception; clients that send many APPEND commands may want to
surround large literals with flushes in the same way as is
recommended for servers later in this section.
Downstream has the unusual property that several kinds of data are
sent, confusing all dictionary-based compression algorithms.
Gulbrandsen Standards Track [Page 4]
RFC 4978 The IMAP COMPRESS Extension August 2007
One type is IMAP responses. These are highly compressible; zlib
using its least CPU-intensive setting compresses typical responses to
25-40% of their original size.
Another type is email headers. These are equally compressible, and
benefit from using the same dictionary as the IMAP responses.
A third type is email body text. Text is usually fairly short and
includes much ASCII, so the same compression dictionary will do a
good job here, too. When multiple messages in the same thread are
read at the same time, quoted lines etc. can often be compressed
almost to zero.
Finally, attachments (non-text email bodies) are transmitted, either
in binary form or encoded with base-64.
When attachments are retrieved in binary form, DEFLATE may be able to
compress them, but the format of the attachment is usually not IMAP-
like, so the dictionary built while compressing IMAP does not help.
The compressor has to adapt its dictionary from IMAP to the
attachment's format, and then back. A few file formats aren't
compressible at all using deflate, e.g., .gz, .zip, and .jpg files.
When attachments are retrieved in base-64 form, the same problems
apply, but the base-64 encoding adds another problem. 8-bit
compression algorithms such as deflate work well on 8-bit file
formats, however base-64 turns a file into something resembling 6-bit
bytes, hiding most of the 8-bit file format from the compressor.
When using the zlib library (see [RFC1951]), the functions
deflateInit2(), deflate(), inflateInit2(), and inflate() suffice to
implement this extension. The windowBits value must be in the range
-8 to -15, or else deflateInit2() uses the wrong format.
deflateParams() can be used to improve compression rate and resource
use. The Z_FULL_FLUSH argument to deflate() can be used to clear the
dictionary (the receiving peer does not need to do anything).
A client can improve downstream compression by implementing BINARY
(defined in [RFC3516]) and using FETCH BINARY instead of FETCH BODY.
In the author's experience, the improvement ranges from 5% to 40%
depending on the attachment being downloaded.
A server can improve downstream compression if it hints to the
compressor that the data type is about to change strongly, e.g., by
sending a Z_FULL_FLUSH at the start and end of large non-text
literals (before and after '*CHAR8' in the definition of literal in
RFC 3501, page 86). Small literals are best left alone. A possible
boundary is 5k.
Gulbrandsen Standards Track [Page 5]
RFC 4978 The IMAP COMPRESS Extension August 2007
A server can improve the CPU efficiency both of the server and the
client if it adjusts the compression level (e.g., using the
deflateParams() function in zlib) at these points, to avoid trying to
compress incompressible attachments. A very simple strategy is to
change the level to 0 at the start of a literal provided the first
two bytes are either 0x1F 0x8B (as in deflate-compressed files) or
0xFF 0xD8 (JPEG), and to keep it at 1-5 the rest of the time. More
complex strategies are possible.
5. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC4234]. This syntax augments
the grammar specified in [RFC3501]. [RFC4234] defines SP and
[RFC3501] defines command-auth, capability, and resp-text-code.
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.
command-auth =/ compress
compress = "COMPRESS" SP algorithm
capability =/ "COMPRESS=" algorithm
;; multiple COMPRESS capabilities allowed
algorithm = "DEFLATE"
resp-text-code =/ "COMPRESSIONACTIVE"
Note that due the syntax of capability names, future algorithm names
must be atoms.
6. Security Considerations
As for TLS compression [RFC3749].
7. IANA Considerations
The IANA has added COMPRESS=DEFLATE to the list of IMAP capabilities.
Gulbrandsen Standards Track [Page 6]
RFC 4978 The IMAP COMPRESS Extension August 2007
8. Acknowledgements
Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther,
Randall Gellens, Tony Hansen, Cullen Jennings, Stephane Maes, Alexey
Melnikov, Lyndon Nerenberg, and Zoltan Ordogh have all helped with
this document.
The author would also like to thank various people in the rooms at
meetings, whose help is real, but not reflected in the author's
mailbox.
9. References
9.1. Normative References
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
9.2. Informative References
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)",
RFC 1962, June 1996.
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
April 2003.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
Compression Methods", RFC 3749, May 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[V42BIS] ITU, "V.42bis: Data compression procedures for data
circuit-terminating equipment (DCE) using error correction
procedures", http://www.itu.int/rec/T-REC-V.42bis, January
1990.
Gulbrandsen Standards Track [Page 7]
RFC 4978 The IMAP COMPRESS Extension August 2007
[MNP] Gilbert Held, "The Complete Modem Reference", Second
Edition, Wiley Professional Computing, ISBN 0-471-00852-4,
May 1994.
Author's Address
Arnt Gulbrandsen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germany
Fax: +49 89 4502 9758
EMail: arnt@oryx.com
Gulbrandsen Standards Track [Page 8]
RFC 4978 The IMAP COMPRESS Extension August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
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.
Gulbrandsen Standards Track [Page 9]

283
docs/rfcs/rfc5032.IMAP_WITHIN_Search_extension.txt Normal file
View File

@ -0,0 +1,283 @@
Network Working Group E. Burger, Ed.
Request for Comments: 5032 BEA Systems, Inc.
Updates: 3501 September 2007
Category: Standards Track
WITHIN Search Extension to the IMAP Protocol
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document describes the WITHIN extension to IMAP SEARCH. IMAP
SEARCH returns messages whose internal date is within or outside a
specified interval. The mechanism described here, OLDER and YOUNGER,
differs from BEFORE and SINCE in that the client specifies an
interval, rather than a date. WITHIN is useful for persistent
searches where either the device does not have the capacity to
perform the search at regular intervals or the network is of limited
bandwidth and thus there is a desire to reduce network traffic from
sending repeated requests and redundant responses.
1. Introduction
This extension exposes two new search keys, OLDER and YOUNGER, each
of which takes a non-zero integer argument corresponding to a time
interval in seconds. The server calculates the time of interest by
subtracting the time interval the client presents from the current
date and time of the server. The server then either returns messages
older or younger than the resultant time and date, depending on the
search key used.
1.1. Conventions Used in This Document
In examples, "C:" and "S:" indicate lines sent by the client and
server, respectively.
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].
Burger Standards Track [Page 1]
RFC 5032 Search Within September 2007
When describing the general syntax, we omit some definitions, as RFC
3501 [RFC3501] defines them.
2. Protocol Operation
An IMAP4 server that supports the capability described here MUST
return "WITHIN" as one of the server supported capabilities in the
CAPABILITY command.
For both the OLDER and YOUNGER search keys, the server calculates a
target date and time by subtracting the interval, specified in
seconds, from the current date and time of the server. The server
then compares the target time with the INTERNALDATE of the message,
as specified in IMAP [RFC3501]. For OLDER, messages match if the
INTERNALDATE is less recent than or equal to the target time. For
YOUNGER, messages match if the INTERNALDATE is more recent than or
equal to the target time.
Both OLDER and YOUNGER searches always result in exact matching, to
the resolution of a second. However, if one is doing a dynamic
evaluation, for example, in a context [CONTEXT], one needs to be
aware that the server might perform the evaluation periodically.
Thus, the server may delay the updates. Clients MUST be aware that
dynamic search results may not reflect the current state of the
mailbox. If the client needs a search result that reflects the
current state of the mailbox, we RECOMMEND that the client issue a
new search.
3. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation. Elements not defined here can be found in the
formal syntax of ABNF [RFC4234] and IMAP [RFC3501].
This document extends RFC 3501 [RFC3501] with two new search keys:
OLDER <interval> and YOUNGER <interval>.
search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number
; search-key defined in RFC 3501
4. Example
C: a1 SEARCH UNSEEN YOUNGER 259200
S: a1 * SEARCH 4 8 15 16 23 42
Search for all unseen messages within the past 3 days, or 259200
seconds, according to the server's current time.
Burger Standards Track [Page 2]
RFC 5032 Search Within September 2007
5. Security Considerations
The WITHIN extension does not raise any security considerations that
are not present in the base protocol. Considerations are the same as
for IMAP [RFC3501].
6. IANA Considerations
Per the IMAP RFC [RFC3501], registration of a new IMAP capability in
the IMAP Capability registry requires the publication of a standards-
track RFC or an IESG approved experimental RFC. The registry is
currently located at
<http://www.iana.org/assignments/imap4-capabilities>. This
standards-track document defines the WITHIN IMAP capability. IANA
has added this extension to the IANA IMAP Capability registry.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC3501] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
7.2. Informative References
[CONTEXT] Melnikov, D. and C. King, "Contexts for IMAP4", Work
in Progress, May 2006.
Burger Standards Track [Page 3]
RFC 5032 Search Within September 2007
Appendix A. Contributors
Stephane Maes and Ray Cromwell wrote the original version of this
document as part of P-IMAP, as well as the first versions for the
IETF. From an attribution perspective, they are clearly authors.
Appendix B. Acknowledgements
The authors want to thank all who have contributed key insight and
who have extensively reviewed and discussed the concepts of LPSEARCH.
They also thank the authors of its early introduction in P-IMAP.
We also want to give a special thanks to Arnt Gilbrandsen, Ken
Murchison, Zoltan Ordogh, and most especially Dave Cridland for their
review and suggestions. A special thank you goes to Alexey Melnikov
for his choice submission of text.
Author's Address
Eric W. Burger (editor)
BEA Systems, Inc.
USA
EMail: eric.burger@bea.com
URI: http://www.standardstrack.com
Burger Standards Track [Page 4]
RFC 5032 Search Within September 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
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.
Burger Standards Track [Page 5]

395
docs/rfcs/rfc5161.IMAP_ENABLE_extension.txt Normal file
View File

@ -0,0 +1,395 @@
Network Working Group A. Gulbrandsen, Ed.
Request for Comments: 5161 Oryx Mail Systems GmbH
Category: Standards Track A. Melnikov, Ed.
Isode Limited
March 2008
The IMAP ENABLE Extension
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
Most IMAP extensions are used by the client when it wants to and the
server supports it. However, a few extensions require the server to
know whether a client supports that extension. The ENABLE extension
allows an IMAP client to say which extensions it supports.
1. Overview
Several IMAP extensions allow the server to return unsolicited
responses specific to these extensions in certain circumstances.
However, servers cannot send those unsolicited responses until they
know that the clients support such extensions and thus won't choke on
the extension response data.
Up until now, extensions have typically stated that a server cannot
send the unsolicited responses until after the client has used a
command with the extension data (i.e., at that point the server knows
the client is aware of the extension). CONDSTORE ([RFC4551]),
ANNOTATE ([ANNOTATE]), and some extensions under consideration at the
moment use various commands to enable server extensions. For
example, CONDSTORE uses a SELECT or FETCH parameter, and ANNOTATE
uses a side effect of FETCH.
The ENABLE extension provides an explicit indication from the client
that it supports particular extensions. This is done using a new
ENABLE command.
An IMAP server that supports ENABLE advertises this by including the
word ENABLE in its capability list.
Gulbrandsen & Melnikov Standards Track [Page 1]
RFC 5161 The IMAP ENABLE Extension March 2008
Most IMAP extensions do not require the client to enable the
extension in any way.
2. Conventions Used in This Document
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 [RFC2119].
Formal syntax is defined by [RFC5234] and [RFC3501].
Example lines prefaced by "C:" are sent by the client and ones
prefaced by "S:" by the server. The five characters [...] means that
something has been elided.
3. Protocol Changes
3.1. The ENABLE Command
Arguments: capability names
Result: OK: Relevant capabilities enabled
BAD: No arguments, or syntax error in an argument
The ENABLE command takes a list of capability names, and requests the
server to enable the named extensions. Once enabled using ENABLE,
each extension remains active until the IMAP connection is closed.
For each argument, the server does the following:
- If the argument is not an extension known to the server, the server
MUST ignore the argument.
- If the argument is an extension known to the server, and it is not
specifically permitted to be enabled using ENABLE, the server MUST
ignore the argument. (Note that knowing about an extension doesn't
necessarily imply supporting that extension.)
- If the argument is an extension that is supported by the server and
that needs to be enabled, the server MUST enable the extension for
the duration of the connection. At present, this applies only to
CONDSTORE ([RFC4551]). Note that once an extension is enabled,
there is no way to disable it.
If the ENABLE command is successful, the server MUST send an untagged
ENABLED response (see Section 3.2).
Gulbrandsen & Melnikov Standards Track [Page 2]
RFC 5161 The IMAP ENABLE Extension March 2008
Clients SHOULD only include extensions that need to be enabled by the
server. At the time of publication, CONDSTORE is the only such
extension (i.e., ENABLE CONDSTORE is an additional "CONDSTORE
enabling command" as defined in [RFC4551]). Future RFCs may add to
this list.
The ENABLE command is only valid in the authenticated state (see
[RFC3501]), before any mailbox is selected. Clients MUST NOT issue
ENABLE once they SELECT/EXAMINE a mailbox; however, server
implementations don't have to check that no mailbox is selected or
was previously selected during the duration of a connection.
The ENABLE command can be issued multiple times in a session. It is
additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a
single command "ENABLE a b c". When multiple ENABLE commands are
issued, each corresponding ENABLED response SHOULD only contain
extensions enabled by the corresponding ENABLE command.
There are no limitations on pipelining ENABLE. For example, it is
possible to send ENABLE and then immediately SELECT, or a LOGIN
immediately followed by ENABLE.
The server MUST NOT change the CAPABILITY list as a result of
executing ENABLE; i.e., a CAPABILITY command issued right after an
ENABLE command MUST list the same capabilities as a CAPABILITY
command issued before the ENABLE command. This is demonstrated in
the following example:
C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
S: t1 OK foo
C: t2 ENABLE CONDSTORE X-GOOD-IDEA
S: * ENABLED X-GOOD-IDEA
S: t2 OK foo
C: t3 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
S: t3 OK foo again
In the following example, the client enables CONDSTORE:
C: a1 ENABLE CONDSTORE
S: * ENABLED CONDSTORE
S: a1 OK Conditional Store enabled
Gulbrandsen & Melnikov Standards Track [Page 3]
RFC 5161 The IMAP ENABLE Extension March 2008
3.2. The ENABLED Response
Contents: capability listing
The ENABLED response occurs as a result of an ENABLE command. The
capability listing contains a space-separated listing of capability
names that the server supports and that were successfully enabled.
The ENABLED response may contain no capabilities, which means that no
extensions listed by the client were successfully enabled.
3.3. Note to Designers of Extensions That May Use the ENABLE Command
Designers of IMAP extensions are discouraged from creating extensions
that require ENABLE unless there is no good alternative design.
Specifically, extensions that cause potentially incompatible behavior
changes to deployed server responses (and thus benefit from ENABLE)
have a higher complexity cost than extensions that do not.
4. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234] including the core
rules in Appendix B.1. [RFC3501] defines the non-terminals
"capability" and "command-any".
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 =/ "ENABLE"
command-any =/ "ENABLE" 1*(SP capability)
response-data =/ "*" SP enable-data CRLF
enable-data = "ENABLED" *(SP capability)
5. Security Considerations
It is believed that this extension doesn't add any security
considerations that are not already present in the base IMAP protocol
[RFC3501].
6. IANA Considerations
The IANA has added ENABLE to the IMAP4 Capabilities Registry.
Gulbrandsen & Melnikov Standards Track [Page 4]
RFC 5161 The IMAP ENABLE Extension March 2008
7. Acknowledgments
The editors would like to thank Randy Gellens, Chris Newman, Peter
Coates, Dave Cridland, Mark Crispin, Ned Freed, Dan Karp, Cyrus
Daboo, Ken Murchison, and Eric Burger for comments and corrections.
However, this doesn't necessarily mean that they endorse this
extension, agree with all details, or are responsible for errors
introduced by the editors.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE Operation or Quick Flag Changes Resynchronization",
RFC 4551, June 2006.
9. Informative References
[ANNOTATE] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work
in Progress, August 2006.
Gulbrandsen & Melnikov Standards Track [Page 5]
RFC 5161 The IMAP ENABLE Extension March 2008
Editors' Addresses
Arnt Gulbrandsen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germany
Fax: +49 89 4502 9758
EMail: arnt@oryx.com
Alexey Melnikov
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
EMail: Alexey.Melnikov@isode.com
Gulbrandsen & Melnikov Standards Track [Page 6]
RFC 5161 The IMAP ENABLE Extension March 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
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.
Gulbrandsen & Melnikov Standards Track [Page 7]

1291
docs/rfcs/rfc5162.IMAP4_Extensions_for_Quick_Mailbox_resync.txt Normal file
View File

File diff suppressed because it is too large Load Diff

731
docs/rfcs/rfc5182.IMAP_extension_last_SEARCH_result.txt Normal file
View File

@ -0,0 +1,731 @@
Network Working Group A. Melnikov
Request for Comments: 5182 Isode Ltd.
Updates: 3501 March 2008
Category: Standards Track
IMAP Extension for Referencing the Last SEARCH Result
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
Many IMAP clients use the result of a SEARCH command as the input to
perform another operation, for example, fetching the found messages,
deleting them, or copying them to another mailbox.
This can be achieved using standard IMAP operations described in RFC
3501; however, this would be suboptimal. The server will send the
list of found messages to the client; after that, the client will
have to parse the list, reformat it, and send it back to the server.
The client can't pipeline the SEARCH command with the subsequent
command, and, as a result, the server might not be able to perform
some optimizations.
This document proposes an IMAP extension that allows a client to tell
a server to use the result of a SEARCH (or Unique Identifier (UID)
SEARCH) command as an input to any subsequent command.
1. Introduction
Many IMAP clients use the result of a SEARCH command as the input to
perform another operation, for example, fetching the found messages,
deleting them, or copying them to another mailbox.
This document proposes an IMAP extension that allows a client to tell
a server to use the result of a SEARCH (or UID SEARCH) command as an
input to any subsequent command.
The SEARCH result reference extension defines a new SEARCH result
option [IMAPABNF] "SAVE" that tells the server to remember the result
of the SEARCH or UID SEARCH command (as well as any command based on
SEARCH, e.g., SORT and THREAD [SORT]) and store it in an internal
Melnikov Standards Track [Page 1]
RFC 5182 Last SEARCH Result Reference March 2008
variable that we will reference as the "search result variable". The
client can use the "$" marker to reference the content of this
internal variable. The "$" marker can be used instead of message
sequence or UID sequence in order to indicate that the server should
substitute it with the list of messages from the search result
variable. Thus, the client can use the result of the latest
remembered SEARCH command as a parameter to another command. The
search result marker has several advantages:
* it avoids wasted bandwidth and associated delay;
* it allows the client to pipeline a SEARCH [IMAP4] command with a
subsequent FETCH/STORE/COPY/SEARCH [IMAP4] or UID EXPUNGE
[UIDPLUS] command;
* the client doesn't need to spend time reformatting the result of
a SEARCH command into a message set used in the subsequent
command;
* it allows the server to perform optimizations. For example, if
the server can execute several pipelined commands in parallel
(or out of order), presence of the search result marker can
allow the server to decide which commands may or may not be
executed out of order.
In absence of any other SEARCH result option, the SAVE result option
also suppresses any SEARCH response that would have been otherwise
returned by the SEARCH command.
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 [KEYWORDS].
Explanatory comments in examples start with // and are not part of
the protocol.
Melnikov Standards Track [Page 2]
RFC 5182 Last SEARCH Result Reference March 2008
2. Overview
2.1. Normative Description of the SEARCHRES Extension
The SEARCH result reference extension described in this document is
present in any IMAP4 server implementation that returns "SEARCHRES"
as one of the supported capabilities in the CAPABILITY command
response. Any such server MUST also implement the [ESEARCH]
extension.
Upon successful completion of a SELECT or an EXAMINE command (after
the tagged OK response), the current search result variable is reset
to the empty sequence.
A successful SEARCH command with the SAVE result option sets the
value of the search result variable to the list of messages found in
the SEARCH command. For example, if no messages were found, the
search result variable will contain the empty list.
Any of the following SEARCH commands MUST NOT change the search
result variable:
o a SEARCH command that caused the server to return the BAD tagged
response,
o a SEARCH command with no SAVE result option that caused the
server to return NO tagged response,
o a successful SEARCH command with no SAVE result option.
A SEARCH command with the SAVE result option that caused the server
to return the NO tagged response sets the value of the search result
variable to the empty sequence.
When a message listed in the search result variable is EXPUNGEd, it
is automatically removed from the list. Implementors are reminded
that if the server stores the list as a list of message numbers, it
MUST automatically adjust them when notifying the client about
expunged messages, as described in Section 7.4.1 of [IMAP4].
If the server decides to send a new UIDVALIDITY value while the
mailbox is opened, this causes resetting of the search variable to
the empty list.
Melnikov Standards Track [Page 3]
RFC 5182 Last SEARCH Result Reference March 2008
Note that even if the "$" marker contains the empty list of messages,
it must be treated by all commands accepting message sets as
parameters as a valid, but non-matching list of messages. For
example, the "FETCH $" command would return a tagged OK response and
no FETCH responses. See also the Example 5 below.
Note that even if the "$" marker contains the empty list of messages,
it must be treated as a valid but non-matching list of messages, by
all commands that accept message sets as parameters.
Implementation note: server implementors should note that "$" can
reference IMAP message sequences or UID sequences, depending on the
context where it is used. For example, the "$" marker can be set as
a result of a SEARCH (SAVE) command and used as a parameter to a UID
FETCH command (which accepts a UID sequence, not a message sequence),
or the "$" marker can be set as a result of a UID SEARCH (SAVE)
command and used as a parameter to a FETCH command (which accepts a
message sequence, not a UID sequence).
2.2. Examples
1) The following example demonstrates how the client can use the
result of a SEARCH command to FETCH headers of interesting
messages:
Example 1:
C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
NOT FROM "Smith"
S: A282 OK SEARCH completed, result saved
C: A283 FETCH $ (UID INTERNALDATE FLAGS RFC822.HEADER)
S: * 2 FETCH (UID 14 ...
S: * 84 FETCH (UID 100 ...
S: * 882 FETCH (UID 1115 ...
S: A283 OK completed
The client can also pipeline the two commands:
Example 2:
C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
NOT FROM "Smith"
C: A283 FETCH $ (UID INTERNALDATE FLAGS RFC822.HEADER)
S: A282 OK SEARCH completed
S: * 2 FETCH (UID 14 ...
S: * 84 FETCH (UID 100 ...
S: * 882 FETCH (UID 1115 ...
S: A283 OK completed
Melnikov Standards Track [Page 4]
RFC 5182 Last SEARCH Result Reference March 2008
2) The following example demonstrates that the result of one SEARCH
command can be used as input to another SEARCH command:
Example 3:
C: A300 SEARCH RETURN (SAVE) SINCE 1-Jan-2004
NOT FROM "Smith"
S: A300 OK SEARCH completed
C: A301 UID SEARCH UID $ SMALLER 4096
S: * SEARCH 17 900 901
S: A301 OK completed
Note that the second command in Example 3 can be replaced with:
C: A301 UID SEARCH $ SMALLER 4096
and the result of the command would be the same.
3) The following example shows that the "$"
marker can be combined with other message numbers using the OR
SEARCH criterion.
Example 4:
C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
NOT FROM "Smith"
S: P282 OK SEARCH completed
C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8}
C: YYYYYYYY
S: * SEARCH 882 1102 3003 3005 3006
S: P283 OK completed
Note: Since this document format is restricted to 7-bit ASCII text,
it is not possible to show actual UTF-8 data. The "YYYYYYYY" is a
placeholder for what would be 8 octets of 8-bit data in an actual
transaction.
Melnikov Standards Track [Page 5]
RFC 5182 Last SEARCH Result Reference March 2008
4) The following example demonstrates that a failed SEARCH sets the
search result variable to the empty list.
Example 5:
C: B282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
NOT FROM "Smith"
S: B282 OK SEARCH completed
C: B283 SEARCH CHARSET KOI8-R (OR $ 1,3000:3021) TEXT {4}
C: XXXX
S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported
//After this command the saved result variable contains
//no messages. A client that wants to reissue the B283
//SEARCH command with another CHARSET would have to reissue
//the B282 command as well. One possible workaround for
//this is to include the desired CHARSET parameter
//in the earliest SEARCH RETURN (SAVE) command in a
//sequence of related SEARCH commands.
//A better approach might be to always use CHARSET UTF-8
//instead.
Note: Since this document format is restricted to 7-bit ASCII text,
it is not possible to show actual KOI8-R data. The "XXXX" is a
placeholder for what would be 4 octets of 8-bit data in an actual
transaction.
5) The following example demonstrates that it is not an error to use
the "$" marker when it contains no messages.
Example 6:
C: E282 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
NOT FROM "Eric"
C: E283 COPY $ "Other Messages"
//The "$" contains no messages
S: E282 OK SEARCH completed
S: E283 OK COPY completed, nothing copied
2.3. Multiple Commands in Progress
Use of a SEARCH RETURN (SAVE) command followed by a command using the
"$" marker creates direct dependency between the two commands. As
directed by Section 5.5 of [IMAP4], a server MUST execute the two
commands in the order they were received. (A server capable of
out-of-order execution can in some cases execute the two commands in
parallel, for example, if a SEARCH RETURN (SAVE) is followed by
"SEARCH $", the search criteria from the first command can be
directly substituted into the second command.)
Melnikov Standards Track [Page 6]
RFC 5182 Last SEARCH Result Reference March 2008
A client supporting this extension MAY pipeline a SEARCH RETURN
(SAVE) command with one or more command using the "$" marker, as long
as this doesn't create an ambiguity, as described in Section 5.5 of
[IMAP4].
Example 7:
C: F282 SEARCH RETURN (SAVE) KEYWORD $Junk
C: F283 COPY $ "Junk"
C: F284 STORE $ +FLAGS.Silent (\Deleted)
S: F282 OK SEARCH completed
S: F283 OK COPY completed
S: F284 OK STORE completed
Example 8:
C: G282 SEARCH RETURN (SAVE) KEYWORD $Junk
C: G283 SEARCH RETURN (ALL) SINCE 28-Oct-2006
FROM "Eric"
//The server can execute the two SEARCH commands
//in any order, as they don't have any dependency.
//Note that the second command is making use of
//the [ESEARCH] extension.
S: * ESEARCH (TAG "G283") ALL 3:15,27,29:103
S: G283 OK SEARCH completed
S: G282 OK SEARCH completed
The following example demonstrates that the result of the second
SEARCH always overrides the result of the first.
Example 9:
C: H282 SEARCH RETURN (SAVE) KEYWORD $Junk
C: H283 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
FROM "Eric"
S: H282 OK SEARCH completed
S: H283 OK SEARCH completed
2.4. Interaction with ESEARCH Extension
Servers that implement the extension defined in this document MUST
implement [ESEARCH] and conform to additional requirements listed in
this section.
The SAVE result option doesn't change whether the server would return
items corresponding to MIN, MAX, ALL, or COUNT [ESEARCH] result
options.
Melnikov Standards Track [Page 7]
RFC 5182 Last SEARCH Result Reference March 2008
When the SAVE result option is combined with the MIN or MAX [ESEARCH]
result option, and none of the other ESEARCH result options are
present, the corresponding MIN/MAX is returned (if the search result
is not empty), but the "$" marker would contain a single message as
returned in the MIN/MAX return item.
If the SAVE result option is combined with both MIN and MAX result
options, and none of the other ESEARCH result options are present,
the "$" marker would contain one or two messages as returned in the
MIN/MAX return items.
If the SAVE result option is combined with the ALL and/or COUNT
result option(s), the "$" marker would always contain all messages
found by the SEARCH or UID SEARCH command. (Note that the last rule
might affect ESEARCH implementations that optimize how the COUNT
result is constructed.)
The following table summarizes the additional requirement on ESEARCH
server implementations described in this section.
+----------------+-------------------+
| Combination of | "$" marker value |
| Result option | |
+----------------+-------------------+
| SAVE MIN | MIN |
+----------------+-------------------+
| SAVE MAX | MAX |
+----------------+-------------------+
| SAVE MIN MAX | MIN & MAX |
+----------------+-------------------+
| SAVE * [m] | all found messages|
+----------------+-------------------+
where '*' means "ALL" and/or "COUNT"
'[m]' means optional "MIN" and/or "MAX"
Melnikov Standards Track [Page 8]
RFC 5182 Last SEARCH Result Reference March 2008
The following example demonstrates behavioral difference for
different combinations of ESEARCH result options. Explanatory
comments start with // and are not part of the protocol:
Example 10:
C: C282 SEARCH RETURN (ALL) SINCE 12-Feb-2006
NOT FROM "Smith"
S: * ESEARCH (TAG "C283") ALL 2,10:15,21
//$ value hasn't changed
S: C282 OK SEARCH completed
C: C283 SEARCH RETURN (ALL SAVE) SINCE 12-Feb-2006
NOT FROM "Smith"
S: * ESEARCH (TAG "C283") ALL 2,10:15,21
//$ value is 2,10:15,21
S: C283 OK SEARCH completed
C: C284 SEARCH RETURN (SAVE MIN) SINCE 12-Feb-2006
NOT FROM "Smith"
S: * ESEARCH (TAG "C284") MIN 2
//$ value is 2
S: C284 OK SEARCH completed
C: C285 SEARCH RETURN (MAX SAVE MIN) SINCE
12-Feb-2006 NOT FROM "Smith"
S: * ESEARCH (TAG "C285") MIN 2 MAX 21
//$ value is 2,21
S: C285 OK SEARCH completed
C: C286 SEARCH RETURN (MAX SAVE MIN COUNT)
SINCE 12-Feb-2006 NOT FROM "Smith"
S: * ESEARCH (TAG "C286") MIN 2 MAX 21 COUNT 8
//$ value is 2,10:15,21
S: C286 OK SEARCH completed
C: C286 SEARCH RETURN (ALL SAVE MIN) SINCE
12-Feb-2006 NOT FROM "Smith"
S: * ESEARCH (TAG "C286") MIN 2 ALL 2,10:15,21
//$ value is 2,10:15,21
S: C286 OK SEARCH completed
Melnikov Standards Track [Page 9]
RFC 5182 Last SEARCH Result Reference March 2008
2.5. Refusing to Save Search Results
In some cases, the server MAY refuse to save a SEARCH (SAVE) result,
for example, if an internal limit on the number of saved results is
reached.
In this case, the server MUST return a tagged NO response containing
the NOTSAVED response code and set the search result variable to the
empty sequence, as described in Section 2.1.
3. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF]. Non-terminals
referenced but not defined below are as defined in [IMAP4] or
[IMAPABNF].
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 =/ "SEARCHRES"
;; capability is defined in [IMAP4]
sequence-set =/ seq-last-command
;; extends sequence-set to allow for
;; "result of the last command" indicator.
seq-last-command = "$"
search-return-opt = "SAVE"
;; conforms to generic search-return-opt
;; syntax defined in [IMAPABNF]
resp-text-code =/ "NOTSAVED"
;; <resp-text-code> from [IMAP4]
Melnikov Standards Track [Page 10]
RFC 5182 Last SEARCH Result Reference March 2008
4. Security Considerations
This extension requires the server to keep additional state, that may
be used to simplify Denial of Service attacks. In order to minimize
damage from such attacks, server implementations MAY limit the number
of saved searches they allow across all connections at any given time
and return the tagged NO response containing the NOTSAVED response
code (see Section 2.5) to a SEARCH RETURN (SAVE) command when this
limit is exceeded.
Apart from that, it is believed that this extension doesn't raise any
additional security concerns not already discussed in [IMAP4].
5. IANA Considerations
This document defines the "SEARCHRES" IMAP capability. IANA has
added it to the IMAP4 Capabilities Registry, which is currently
located at:
http://www.iana.org/assignments/imap4-capabilities
6. Acknowledgments
The author would like to thank Mark Crispin, Cyrus Daboo, and Curtis
King for remembering that this document had to be written, as well as
for comments and corrections received.
The author would also like to thank Dave Cridland, Mark Crispin,
Chris Newman, Dan Karp, and Spencer Dawkins for comments and
corrections received.
Valuable comments, both in agreement and in dissent, were received
from Arnt Gulbrandsen.
Melnikov Standards Track [Page 11]
RFC 5182 Last SEARCH Result Reference March 2008
7. References
7.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006.
[ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
Command for Controlling What Kind of Information Is
Returned", RFC 4731, November 2006.
7.2. Informative References
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, December 2005.
[SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS
PROTOCOL - SORT AND THREAD EXTENSIONS", Work in Progress,
Septemeber 2007.
Author's Address
Alexey Melnikov
Isode Ltd.
5 Castle Business Village,
36 Station Road,
Hampton, Middlesex,
TW12 2BX, United Kingdom
EMail: Alexey.Melnikov@isode.com
Melnikov Standards Track [Page 12]
RFC 5182 Last SEARCH Result Reference March 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
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.
Melnikov Standards Track [Page 13]

2355
docs/rfcs/rfc5182.Sieve_and_extensions.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1123
docs/rfcs/rfc5255.IMAP_i18n.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1739
docs/rfcs/rfc5257.IMAP_ANNOTATE_extension.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1739
docs/rfcs/rfc5258.IMAP4_LIST_command_extension.txt Normal file
View File

File diff suppressed because it is too large Load Diff

955
docs/rfcs/rfc5423.IM_Store_Events.txt Normal file
View File

@ -0,0 +1,955 @@
Network Working Group R. Gellens
Request for Comments: 5423 QUALCOMM Inc.
Category: Standards Track C. Newman
Sun Microsystems
March 2009
Internet Message Store Events
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
One of the missing features in the existing Internet mail and
messaging standards is a facility for server-to-server and server-to-
client event notifications related to message store events. As the
scope of Internet mail expands to support more diverse media (such as
voice mail) and devices (such as cell phones) and to provide rich
interactions with other services (such as web portals and legal
compliance systems), the need for an interoperable notification
system increases. This document attempts to enumerate the types of
events that interest real-world consumers of such a system.
This document describes events and event parameters that are useful
for several cases, including notification to administrative systems
and end users. This is not intended as a replacement for a message
access facility such as IMAP.
Gellens & Newman Standards Track [Page 1]
RFC 5423 Internet Message Store Events March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Message Addition and Deletion . . . . . . . . . . . . . . 5
4.2. Message Flags . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Access Accounting . . . . . . . . . . . . . . . . . . . . 8
4.4. Mailbox Management . . . . . . . . . . . . . . . . . . . . 8
5. Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Future Extensions . . . . . . . . . . . . . . . . . . 17
1. Introduction
A message store is used to organize Internet Messages [RFC5322] into
one or more mailboxes (possibly hierarchical), annotate them in
various ways, and provide access to these messages and associated
metadata. Three different standards-based protocols have been widely
deployed to remotely access a message store. The Post Office
Protocol (POP) [RFC1939] provides simple download-and-delete access
to a single mail drop (which is a subset of the functionality
typically associated with a message store). The Internet Message
Access Protocol (IMAP) [RFC3501] provides an extensible feature-rich
model for online, offline, and disconnected access to a message store
with minimal constraints on any associated "fat-client" user
interface. Finally, mail access applications built on top of the
Hypertext Transfer Protocol (HTTP) [RFC2616] that run in standards-
based web browsers provide a third standards-based access mechanism
for online-only access.
While simple and/or ad-hoc mechanisms for notifications have sufficed
to some degree in the past (e.g., "Simple New Mail Notification"
[RFC4146], "IMAP4 IDLE Command" [RFC2177]), as the scope and
importance of message stores expand, the demand for a more complete
store notification system increases. Some of the driving forces
behind this demand include:
o Mobile devices with intermittent network connectivity that have
"new mail" or "message count" indicators.
Gellens & Newman Standards Track [Page 2]
RFC 5423 Internet Message Store Events March 2009
o Unified messaging systems that include both Internet and voice
mail require support for a message-waiting indicator on phones.
o Interaction with systems for event-based or utility-computing
billing.
o Simplification of the process of passing message store events to
non-Internet notification systems.
o A calendar system may wish to subscribe to MessageNew
notifications in order to support iMIP [RFC2447].
o Some jurisdictions have laws or regulations for information
protection and auditing that require interoperable protocols
between message stores built by messaging experts and compliance
auditing systems built by compliance experts.
Vendors who have deployed proprietary notification systems for their
Internet message stores have seen significant demand to provide
notifications for more and more events. As a first step towards
building a notification system, this document attempts to enumerate
the core events that real-world customers demand.
This document includes those events that can be generated by the use
of IMAP4rev1 [RFC3501] and some existing extensions. As new IMAP
extensions are defined, or additional event types or parameters need
to be added, the set specified here can be extended by means of an
IANA registry with update requirements, as specified in Section 6.
1.1. Conventions Used in This Document
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].
When these words appear in lower-case or with initial capital
letters, they are not RFC 2119 key words.
2. Terminology
The following terminology is used in this document:
mailbox
A container for Internet messages and/or child mailboxes. A
mailbox may or may not permit delivery of new messages via a mail
delivery agent.
Gellens & Newman Standards Track [Page 3]
RFC 5423 Internet Message Store Events March 2009
mailbox identifier
A mailbox identifier provides sufficient information to identify a
specific mailbox on a specific server instance. An IMAP URL can
be a mailbox identifier.
message access protocols
Protocols that provide clients (e.g., a mail user agent or web
browser) with access to the message store, including but not
limited to IMAP, POP, and HTTP.
message context
As defined in [RFC3458].
UIDVALIDITY
As defined in IMAP4rev1 [RFC3501]. UIDVALIDITY is critical to the
correct operation of a caching mail client. When it changes, the
client MUST flush its cache. It's particularly important to
include UIDVALIDITY with event notifications related to message
addition or removal in order to keep the message data correctly
synchronized.
3. Event Model
The events that are generated by a message store depend to some
degree on the model used to represent a message store. The model the
IETF has for a message store is implicit from IMAP4rev1 and
extensions, so that model is assumed by this document.
A message store event typically has an associated mailbox name and
usually has an associated user name (or authorization identity if
using the terminology from "Simple Authentication and Security Layer"
(SASL) [RFC4422]). Events referring to a specific message can use an
IMAP URL [RFC5092] to do so. Events referring to a set of messages
can use an IMAP URL to the mailbox plus an IMAP UID (Unique
Identifier) set.
Each notification has a type and parameters. The type determines the
type of event, while the parameters supply information about the
context of the event that may be used to adjust subscription
preferences or may simply supply data associated with the event. The
types and parameter names in this document are restricted to US-ASCII
printable characters, so these events can be easily mapped to an
arbitrary notification system. However, this document assumes that
arbitrary parameter values (including large and multi-line values)
can be encoded with the notification system. Systems which lack that
feature could only implement a subset of these events.
Gellens & Newman Standards Track [Page 4]
RFC 5423 Internet Message Store Events March 2009
This document does not indicate which event parameters are mandatory
or optional. That is done in documents that specify specific message
formats or bindings to a notification system.
For scalability reasons, some degree of filtering at event generation
is necessary. At the very least, the ability to turn on and off
groups of related events and to suppress inclusion of large
parameters (such as messageContent) is needed. A sophisticated
publish/subscribe notification system may be able to propagate
cumulative subscription information to the publisher.
Some of these events might be logically collapsed into a single event
type with a required parameter to distinguish between the cases
(e.g., QuotaExceed and QuotaWithin). However, until such time that
an event subscription model is formulated, it's not practical to make
such decisions. We thus note only the fact that some of these events
may be viewed as a single event type.
4. Event Types
This section discusses the different types of events useful in a
message store event notification system. The intention is to
document the events sufficient to cover an overwhelming majority of
known use cases while leaving less common event types for the future.
This section mentions parameters that are important or specific to
the events described here. Event parameters likely to be included in
most or all notifications are discussed in the next section.
4.1. Message Addition and Deletion
This section includes events related to message addition and
deletion.
MessageAppend
A message was appended or concatenated to a mailbox by a message
access client. For the most part, this is identical to the
MessageNew event type except that the SMTP envelope information is
not included as a parameter, but information about which protocol
triggered the event MAY be included. See the MessageNew event for
more information.
MessageExpire
One or more messages were expired from a mailbox due to server
expiration policy and are no longer accessible by the end user.
The parameters include a mailbox identifier that MUST include
UIDVALIDITY and a UID set that describes the messages.
Gellens & Newman Standards Track [Page 5]
RFC 5423 Internet Message Store Events March 2009
Information about which server expiration policy was applied may
be included in the future.
MessageExpunge
One or more messages were expunged from a mailbox by an IMAP
CLOSE/EXPUNGE, POP3 DELE+QUIT, HTTP, or equivalent client action
and are no longer accessible by the end user.
The parameters include a mailbox identifier that MUST include
UIDVALIDITY, a UID set, and MAY also indicate which access
protocol triggered the event.
MessageNew
A new message was received into a mailbox via a message delivery
agent.
The parameters include a message identifier that, for IMAP-
accessible message stores, MUST include UIDVALIDITY and a UID.
The parameters MAY also include an SMTP envelope and other
arbitrary message and mailbox metadata. In some cases, the entire
new message itself may be included. The set of parameters SHOULD
be adjustable to the client's preference, with limits set by
server policy. An interesting policy, for example, would be to
include messages up to 2K in size with the notification, but to
include a URLAUTH [RFC4467] reference for larger messages.
QuotaExceed
An operation failed (typically MessageNew) because the user's
mailbox exceeded one of the quotas (e.g., disk quota, message
quota, quota by message context, etc.). The parameters SHOULD
include at least the relevant user and quota and, optionally, the
mailbox. Quota usage SHOULD be included if possible. Parameters
needed to extend this to support quota by context are not
presently described in this document but could be added in the
future.
QuotaWithin
An operation occurred (typically MessageExpunge or MessageExpire)
that reduced the user's quota usage under the limit.
QuotaChange
The user's quota was changed.
Gellens & Newman Standards Track [Page 6]
RFC 5423 Internet Message Store Events March 2009
4.2. Message Flags
This section includes events related to changes in message flags.
MessageRead
One or more messages in the mailbox were marked as read or seen by
a user. Note that POP has no concept of read or seen messages, so
these events are only generated by IMAP or HTTP clients (or
equivalent).
The parameters include a mailbox identifier and a set of message
UIDs.
MessageTrash
One or more messages were marked for future deletion by the user
but are still accessible over the protocol (the user's client may
or may not make these messages accessible through its user
interface).
The parameters include a mailbox identifier and a set of message
UIDs.
FlagsSet
One or more messages in the mailbox had one or more IMAP flags or
keywords set.
The parameters include a list of IMAP flag or keyword names that
were set, a mailbox identifier, and the set of UIDs of affected
messages. The flagNames MUST NOT include \Recent. For
compatibility with simpler clients, it SHOULD be configurable
whether setting the \Seen or \Deleted flags results in this event
or the simpler MessageRead/MessageTrash events. By default, the
simpler message forms SHOULD be used for MessageRead and
MessageTrash.
FlagsClear
One or more messages in the mailbox had one or more IMAP flags or
keywords cleared.
The parameters include a list of IMAP flag or keyword names that
were cleared, a mailbox identifier, and the set of UIDs of
affected messages. The flagNames parameter MUST NOT include
\Recent.
Gellens & Newman Standards Track [Page 7]
RFC 5423 Internet Message Store Events March 2009
4.3. Access Accounting
This section lists events related to message store access accounting.
Login
A user has logged into the system via IMAP, HTTP, POP, or some
other mechanism.
The parameters include the domain name and port used to access the
server and the user's authorization identity. Additional possible
parameters include the client's IP address and port, the
authentication identity (if different from the authorization
identity), the service name, the authentication mechanism,
information about any negotiated security layers, a timestamp, and
other information.
Logout
A user has logged out or otherwise been disconnected from the
message store via IMAP, HTTP, POP, or some other mechanism.
The parameters include the server domain name and the user's
authorization identity. Additional parameters MAY include any of
the information from the "Login" event as well as information
about the type of disconnect (suggested values include graceful,
abort, timeout, and security layer error), the duration of the
connection or session, and other information.
4.4. Mailbox Management
This section lists events related to the management of mailboxes.
MailboxCreate
A mailbox has been created, or an access control changed on an
existing mailbox so that it is now accessible by the user. If the
mailbox creation caused the creation of new mailboxes earlier in
the hierarchy, separate MailboxCreate events are not generated, as
their creation is implied.
The parameters include the created mailbox identifier, its
UIDVALIDITY for IMAP-accessible message stores, and MAY also
indicate which access protocol triggered the event. Access and
permissions information (such as Access Control List (ACL)
[RFC4314] settings) require a standardized format to be included,
and so are left for future extension.
Gellens & Newman Standards Track [Page 8]
RFC 5423 Internet Message Store Events March 2009
MailboxDelete
A mailbox has been deleted, or an access control changed on an
existing mailbox so that it is no longer accessible by the user.
Note that if the mailbox has child mailboxes, only the specified
mailbox has been deleted, not the children. The mailbox becomes
\NOSELECT, and the hierarchy remains unchanged, as per the
description of the DELETE command in IMAP4rev1 [RFC3501].
The parameters include the deleted mailbox identifier and MAY also
indicate which access protocol triggered the event.
MailboxRename
A mailbox has been renamed. Note that, per the description of the
RENAME command in IMAP4rev1 [RFC3501], special semantics regarding
the mailbox hierarchy apply when INBOX is renamed (child mailboxes
are usually included in the rename, but are excluded when INBOX is
renamed). When a mailbox other than INBOX is renamed and its
child mailboxes are also renamed as a result, separate
MailboxRename events are not generated for the child mailboxes, as
their renaming is implied. If the rename caused the creation of
new mailboxes earlier in the hierarchy, separate MailboxCreate
events are not generated for those, as their creation is implied.
When INBOX is renamed, a new INBOX is created. A MailboxCreate
event is not generated for the new INBOX, since it is implied.
The parameters include the old mailbox identifier, the new mailbox
identifier, and MAY also indicate which access protocol triggered
the event.
MailboxSubscribe
A mailbox has been added to the server-stored subscription list,
such as the one managed by the IMAP SUBSCRIBE and UNSUBSCRIBE
commands.
The parameters include the user whose subscription list has been
affected, the mailbox identifier, and MAY also indicate which
access protocol triggered the event.
MailboxUnSubscribe
A mailbox has been removed from the subscription list.
The parameters include the user whose subscription list has been
affected, the mailbox identifier, and MAY also indicate which
access protocol triggered the event.
Gellens & Newman Standards Track [Page 9]
RFC 5423 Internet Message Store Events March 2009
5. Event Parameters
This section lists parameters included with these events.
admin
Included with all events generated by message access protocols.
The authentication identity associated with this event, as
distinct from the authorization identity (see "user"). This is
not included when it is the same as the value of the user
parameter.
bodyStructure
May be included with MessageAppend and MessageNew.
The IMAP BODYSTRUCTURE of the message.
clientIP
Included with all events generated by message access protocols.
The IPv4 or IPv6 address of the message store access client that
performed the action that triggered the notification.
clientPort
Included with all events generated by message access protocols.
The port number of the message store access client that performed
an action that triggered the notification (the port from which the
connection occurred).
diskQuota
Included with QuotaExceed, QuotaWithin, and QuotaChange
notifications relating to a user or mailbox disk quota. May be
included with other notifications.
Disk quota limit in kilobytes (1024 octets).
diskUsed
Included with QuotaExceed and QuotaWithin notifications relating
to a user or mailbox disk quota. May be included with other
notifications.
Disk space used in kilobytes (1024 octets). Only disk space that
counts against the quota is included.
Gellens & Newman Standards Track [Page 10]
RFC 5423 Internet Message Store Events March 2009
envelope
May be included with the MessageNew notification.
The message transfer envelope associated with final delivery of
the message for the MessageNew notification. This includes the
MAIL FROM and relevant RCPT TO line(s) used for final delivery
with CRLF delimiters and any ESMTP parameters.
flagNames
Included with FlagsSet and FlagsClear events. May be included
with MessageAppend and MessageNew to indicate flags that were set
initially by the APPEND command or delivery agent, respectively.
A list (likely to be space-separated) of IMAP flag or keyword
names that were set or cleared. Flag names begin with a backslash
while keyword names do not. The \Recent flag is explicitly not
permitted in the list.
mailboxID
Included in events that affect mailboxes. A URI describing the
mailbox. In the case of MailboxRename, this refers to the new
name.
maxMessages
Included with QuotaExceed and QuotaWithin notifications relating
to a user or mailbox message count quota. May be included with
other notifications.
Quota limit on the number of messages in the mailbox, for events
referring to a mailbox.
messageContent
May be included with MessageAppend and MessageNew.
The entire message itself. Size-based suppression of this SHOULD
be available.
messageSize
May be included with MessageAppend and MessageNew.
Size of the RFC 5322 message itself in octets. This value matches
the length of the IMAP literal returned in response to an IMAP
FETCH of BODY[] for the referenced message.
Gellens & Newman Standards Track [Page 11]
RFC 5423 Internet Message Store Events March 2009
messages
Included with QuotaExceed and QuotaWithin notifications relating
to a user or mailbox message count quota. May be included with
other notifications.
Number of messages in the mailbox. This is typically included
with message addition and deletion events.
modseq
May be included with any notification referring to one message.
This is the 64-bit integer MODSEQ as defined in [RFC4551]. No
assumptions about MODSEQ can be made if this is omitted.
oldMailboxID
A URI describing the old name of a renamed or moved mailbox.
pid
May be included with any notification.
The process ID of the process that generated the notification.
process
May be included with any notification.
The name of the process that generated the notification.
serverDomain
Included in Login and optionally in Logout or other events. The
domain name or IP address (v4 or v6) used to access the server or
mailbox.
serverPort
Included in Login and optionally in Logout or other events. The
port number used to access the server. This is often a well-known
port.
serverFQDN
May be included with any notification.
The fully qualified domain name of the server that generated the
event. Note that this may be different from the server name used
to access the mailbox included in the mailbox identifier.
Gellens & Newman Standards Track [Page 12]
RFC 5423 Internet Message Store Events March 2009
service
May be included with any notification.
The name of the service that triggered the event. Suggested
values include "imap", "pop", "http", and "admincli" (for an
administrative client).
tags
May be included with any notification.
A list of UTF-8 tags (likely to be comma-separated). One or more
tags can be set at the time a notification criteria or
notification subscription is created. Subscribers can use tags
for additional client-side filtering or dispatch of events.
timestamp
May be included with any notification.
The time at which the event occurred that triggered the
notification (the underlying protocol carrying the notification
may contain a timestamp for when the notification was generated).
This MAY be an approximate time.
Timestamps are expressed in local time and contain the offset from
UTC (this information is used in several places in Internet mail)
and are normally in [RFC3339] format.
uidnext
May be included with any notification referring to a mailbox.
The UID that is projected to be assigned next in the mailbox.
This is typically included with message addition and deletion
events. This is equivalent to the UIDNEXT status item in the IMAP
STATUS command.
uidset
Included with MessageExpires, MessageExpunges, MessageRead,
MessageTrash, FlagsSet, and FlagsClear.
This includes the set of IMAP UIDs referenced.
uri
Included with all notifications. A reference to the IMAP server,
a mailbox, or a message.
Typically an IMAP URL. This can include the name of the server
used to access the mailbox/message, the mailbox name, the
UIDVALIDITY of the mailbox, and the UID of a specific message.
Gellens & Newman Standards Track [Page 13]
RFC 5423 Internet Message Store Events March 2009
user
Included with all events generated by message access protocols.
This is the authorization identifier used when the client
connected to the access protocol that triggered the event. Some
protocols (for example, many SASL mechanisms) distinguish between
authorization and authentication identifiers. For events
associated with a mailbox, this may be different from the owner of
the mailbox specified in the IMAP URL.
6. IANA Considerations
The IANA has created a new registry for "Internet Message Store
Events" that contains two sub-registries: event names and event
parameters. For both event names and event parameters, entries that
do not start with "vnd." are added by the IETF and are intended for
interoperable use. Entries that start with "vnd." are intended for
private use by one or more parties and are allocated to avoid
collisions.
The initial values are contained in this document.
Using IANA Considerations [RFC5226] terminology, entries that do not
start with "vnd." are allocated by IETF Consensus, while those
starting with "vnd." are allocated First Come First Served.
7. Security Considerations
Notifications can produce a large amount of traffic and expose
sensitive information. When notification mechanisms are used to
maintain state between different entities, the ability to corrupt or
manipulate notification messages could enable an attacker to modulate
the state of these entities. For example, if an attacker were able
to modify notifications sent from a message store to an auditing
server, he could modify the "user" and "messageContent" parameters in
MessageNew notifications to create false audit log entries.
A competent transfer protocol for notifications must consider
authentication, authorization, privacy, and message integrity, as
well as denial-of-service issues. While the IETF has adequate tools
and experience to address these issues for mechanisms that involve
only one TCP connection, notification or publish/subscribe protocols
that are more sophisticated than a single end-to-end TCP connection
will need to pay extra attention to these issues and carefully
balance requirements to successfully deploy a system with security
and privacy considerations.
Gellens & Newman Standards Track [Page 14]
RFC 5423 Internet Message Store Events March 2009
8. Acknowledgments
Alexey Melnikov, Arnt Gulbrandsen, and Zoltan Ordogh have reviewed
and offered improvements to this document. Richard Barnes did a nice
review during Last Call.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092,
November 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
9.2. Informative References
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar
Message-Based Interoperability Protocol (iMIP)", RFC 2447,
November 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458, January 2003.
[RFC4146] Gellens, R., "Simple New Mail Notification", RFC 4146,
August 2005.
Gellens & Newman Standards Track [Page 15]
RFC 5423 Internet Message Store Events March 2009
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) -
URLAUTH Extension", RFC 4467, May 2006.
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE Operation or Quick Flag Changes Resynchronization",
RFC 4551, June 2006.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
Gellens & Newman Standards Track [Page 16]
RFC 5423 Internet Message Store Events March 2009
Appendix A. Future Extensions
This document specifies core functionality based on events that are
believed to be well understood, have known use cases, and are
implemented by at least one deployed real-world Internet message
store. (A few events are exceptions to the last test only: FlagsSet,
FlagsClear, MailboxCreate, MailboxDelete, MailboxRename,
MailboxSubscribe, and MailboxUnSubscribe.)
Some events have been suggested but are postponed to future
extensions because they do not meet this criteria. These events
include messages that have been moved to archive storage and may
require extra time to access, quota by message context,
authentication failure, user mail account disabled, annotations, and
mailbox ACL or metadata change. The descriptions of several events
note additional parameters that are likely candidates for future
inclusion. See Section 6 for how the list of events and parameters
can be extended.
In order to narrow the scope of this document to something that can
be completed, only events generated from the message store (by a
message access module, administrative module, or message delivery
agent) are considered. A complete mail system is normally linked
with an identity system that would also publish events of interest to
a message store event subscriber. Events of interest include account
created/deleted/disabled and password changed/expired.
Authors' Addresses
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92651
USA
Phone:
EMail: rg+ietf@qualcomm.com
Chris Newman
Sun Microsystems
800 Royal Oaks
Monrovia, CA 91016-6347
USA
Phone:
EMail: chris.newman@sun.com
Gellens & Newman Standards Track [Page 17]

1177
docs/rfcs/rfc5464.IMAP_METADATA_extension.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1235
docs/rfcs/rfc5465.IMAP_NOTIFY_extension.txt Normal file
View File

File diff suppressed because it is too large Load Diff

507
docs/rfcs/rfc5530.IMAP_Response_codes.txt Normal file
View File

@ -0,0 +1,507 @@
Network Working Group A. Gulbrandsen
Request for Comments: 5530 Oryx Mail Systems GmbH
Category: Standards Track May 2009
IMAP Response Codes
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
IMAP responses consist of a response type (OK, NO, BAD), an optional
machine-readable response code, and a human-readable text.
This document collects and documents a variety of machine-readable
response codes, for better interoperation and error reporting.
Gulbrandsen Standards Track [Page 1]
RFC 5530 IMAP Response Codes May 2009
1. Introduction
Section 7.1 of [RFC3501] defines a number of response codes that can
help tell an IMAP client why a command failed. However, experience
has shown that more codes are useful. For example, it is useful for
a client to know that an authentication attempt failed because of a
server problem as opposed to a password problem.
Currently, many IMAP servers use English-language, human-readable
text to describe these errors, and a few IMAP clients attempt to
translate this text into the user's language.
This document names a variety of errors as response codes. It is
based on errors that have been checked and reported on in some IMAP
server implementations, and on the needs of some IMAP clients.
This document doesn't require any servers to test for these errors or
any clients to test for these names. It only names errors for better
reporting and handling.
2. Conventions Used in This Document
Formal syntax is defined by [RFC5234] as modified by [RFC3501].
Example lines prefaced by "C:" are sent by the client and ones
prefaced by "S:" by the server. "[...]" means elision.
3. Response Codes
This section defines all the new response codes. Each definition is
followed by one or more examples.
UNAVAILABLE
Temporary failure because a subsystem is down. For example, an
IMAP server that uses a Lightweight Directory Access Protocol
(LDAP) or Radius server for authentication might use this
response code when the LDAP/Radius server is down.
C: a LOGIN "fred" "foo"
S: a NO [UNAVAILABLE] User's backend down for maintenance
AUTHENTICATIONFAILED
Authentication failed for some reason on which the server is
unwilling to elaborate. Typically, this includes "unknown
user" and "bad password".
Gulbrandsen Standards Track [Page 2]
RFC 5530 IMAP Response Codes May 2009
This is the same as not sending any response code, except that
when a client sees AUTHENTICATIONFAILED, it knows that the
problem wasn't, e.g., UNAVAILABLE, so there's no point in
trying the same login/password again later.
C: b LOGIN "fred" "foo"
S: b NO [AUTHENTICATIONFAILED] Authentication failed
AUTHORIZATIONFAILED
Authentication succeeded in using the authentication identity,
but the server cannot or will not allow the authentication
identity to act as the requested authorization identity. This
is only applicable when the authentication and authorization
identities are different.
C: c1 AUTHENTICATE PLAIN
[...]
S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID
C: c2 AUTHENTICATE PLAIN
[...]
S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin
EXPIRED
Either authentication succeeded or the server no longer had the
necessary data; either way, access is no longer permitted using
that passphrase. The client or user should get a new
passphrase.
C: d login "fred" "foo"
S: d NO [EXPIRED] That password isn't valid any more
PRIVACYREQUIRED
The operation is not permitted due to a lack of privacy. If
Transport Layer Security (TLS) is not in use, the client could
try STARTTLS (see Section 6.2.1 of [RFC3501]) and then repeat
the operation.
C: d login "fred" "foo"
S: d NO [PRIVACYREQUIRED] Connection offers no privacy
C: d select inbox
S: d NO [PRIVACYREQUIRED] Connection offers no privacy
Gulbrandsen Standards Track [Page 3]
RFC 5530 IMAP Response Codes May 2009
CONTACTADMIN
The user should contact the system administrator or support
desk.
C: e login "fred" "foo"
S: e OK [CONTACTADMIN]
NOPERM
The access control system (e.g., Access Control List (ACL), see
[RFC4314]) does not permit this user to carry out an operation,
such as selecting or creating a mailbox.
C: f select "/archive/projects/experiment-iv"
S: f NO [NOPERM] Access denied
INUSE
An operation has not been carried out because it involves
sawing off a branch someone else is sitting on. Someone else
may be holding an exclusive lock needed for this operation, or
the operation may involve deleting a resource someone else is
using, typically a mailbox.
The operation may succeed if the client tries again later.
C: g delete "/archive/projects/experiment-iv"
S: g NO [INUSE] Mailbox in use
EXPUNGEISSUED
Someone else has issued an EXPUNGE for the same mailbox. The
client may want to issue NOOP soon. [RFC2180] discusses this
subject in depth.
C: h search from fred@example.com
S: * SEARCH 1 2 3 5 8 13 21 42
S: h OK [EXPUNGEISSUED] Search completed
CORRUPTION
The server discovered that some relevant data (e.g., the
mailbox) are corrupt. This response code does not include any
information about what's corrupt, but the server can write that
to its logfiles.
C: i select "/archive/projects/experiment-iv"
S: i NO [CORRUPTION] Cannot open mailbox
Gulbrandsen Standards Track [Page 4]
RFC 5530 IMAP Response Codes May 2009
SERVERBUG
The server encountered a bug in itself or violated one of its
own invariants.
C: j select "/archive/projects/experiment-iv"
S: j NO [SERVERBUG] This should not happen
CLIENTBUG
The server has detected a client bug. This can accompany all
of OK, NO, and BAD, depending on what the client bug is.
C: k1 select "/archive/projects/experiment-iv"
[...]
S: k1 OK [READ-ONLY] Done
C: k2 status "/archive/projects/experiment-iv" (messages)
[...]
S: k2 OK [CLIENTBUG] Done
CANNOT
The operation violates some invariant of the server and can
never succeed.
C: l create "///////"
S: l NO [CANNOT] Adjacent slashes are not supported
LIMIT
The operation ran up against an implementation limit of some
kind, such as the number of flags on a single message or the
number of flags used in a mailbox.
C: m STORE 42 FLAGS f1 f2 f3 f4 f5 ... f250
S: m NO [LIMIT] At most 32 flags in one mailbox supported
OVERQUOTA
The user would be over quota after the operation. (The user
may or may not be over quota already.)
Note that if the server sends OVERQUOTA but doesn't support the
IMAP QUOTA extension defined by [RFC2087], then there is a
quota, but the client cannot find out what the quota is.
C: n1 uid copy 1:* oldmail
S: n1 NO [OVERQUOTA] Sorry
C: n2 uid copy 1:* oldmail
S: n2 OK [OVERQUOTA] You are now over your soft quota
Gulbrandsen Standards Track [Page 5]
RFC 5530 IMAP Response Codes May 2009
ALREADYEXISTS
The operation attempts to create something that already exists,
such as when the CREATE or RENAME directories attempt to create
a mailbox and there is already one of that name.
C: o RENAME this that
S: o NO [ALREADYEXISTS] Mailbox "that" already exists
NONEXISTENT
The operation attempts to delete something that does not exist.
Similar to ALREADYEXISTS.
C: p RENAME this that
S: p NO [NONEXISTENT] No such mailbox
4. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines
the non-terminal "resp-text-code".
Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lowercase characters to define
token strings is for editorial clarity only.
resp-text-code =/ "UNAVAILABLE" / "AUTHENTICATIONFAILED" /
"AUTHORIZATIONFAILED" / "EXPIRED" /
"PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" /
"INUSE" / "EXPUNGEISSUED" / "CORRUPTION" /
"SERVERBUG" / "CLIENTBUG" / "CANNOT" /
"LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" /
"NONEXISTENT"
5. Security Considerations
Revealing information about a passphrase to unauthenticated IMAP
clients causes bad karma.
Response codes are easier to parse than human-readable text. This
can amplify the consequences of an information leak. For example,
selecting a mailbox can fail because the mailbox doesn't exist,
because the user doesn't have the "l" right (right to know the
mailbox exists) or "r" right (right to read the mailbox). If the
server sent different responses in the first two cases in the past,
only malevolent clients would discover it. With response codes it's
possible, perhaps probable, that benevolent clients will forward the
Gulbrandsen Standards Track [Page 6]
RFC 5530 IMAP Response Codes May 2009
leaked information to the user. Server authors are encouraged to be
particularly careful with the NOPERM and authentication-related
responses.
6. IANA Considerations
The IANA has created the IMAP Response Codes registry. The registry
has been populated with the following codes:
NEWNAME RFC 2060 (obsolete)
REFERRAL RFC 2221
ALERT RFC 3501
BADCHARSET RFC 3501
PARSE RFC 3501
PERMANENTFLAGS RFC 3501
READ-ONLY RFC 3501
READ-WRITE RFC 3501
TRYCREATE RFC 3501
UIDNEXT RFC 3501
UIDVALIDITY RFC 3501
UNSEEN RFC 3501
UNKNOWN-CTE RFC 3516
UIDNOTSTICKY RFC 4315
APPENDUID RFC 4315
COPYUID RFC 4315
URLMECH RFC 4467
TOOBIG RFC 4469
BADURL RFC 4469
HIGHESTMODSEQ RFC 4551
NOMODSEQ RFC 4551
MODIFIED RFC 4551
COMPRESSIONACTIVE RFC 4978
CLOSED RFC 5162
NOTSAVED RFC 5182
BADCOMPARATOR RFC 5255
ANNOTATE RFC 5257
ANNOTATIONS RFC 5257
TEMPFAIL RFC 5259
MAXCONVERTMESSAGES RFC 5259
MAXCONVERTPARTS RFC 5259
NOUPDATE RFC 5267
METADATA RFC 5464
NOTIFICATIONOVERFLOW RFC 5465
BADEVENT RFC 5465
UNDEFINED-FILTER RFC 5466
UNAVAILABLE RFC 5530
AUTHENTICATIONFAILED RFC 5530
AUTHORIZATIONFAILED RFC 5530
Gulbrandsen Standards Track [Page 7]
RFC 5530 IMAP Response Codes May 2009
EXPIRED RFC 5530
PRIVACYREQUIRED RFC 5530
CONTACTADMIN RFC 5530
NOPERM RFC 5530
INUSE RFC 5530
EXPUNGEISSUED RFC 5530
CORRUPTION RFC 5530
SERVERBUG RFC 5530
CLIENTBUG RFC 5530
CANNOT RFC 5530
LIMIT RFC 5530
OVERQUOTA RFC 5530
ALREADYEXISTS RFC 5530
NONEXISTENT RFC 5530
The new registry can be extended by sending a registration request to
IANA. IANA will forward this request to a Designated Expert,
appointed by the responsible IESG Area Director, CCing it to the IMAP
Extensions mailing list at <ietf-imapext@imc.org> (or a successor
designated by the Area Director). After either allowing 30 days for
community input on the IMAP Extensions mailing list or a successful
IETF Last Call, the expert will determine the appropriateness of the
registration request and either approve or disapprove the request by
sending a notice of the decision to the requestor, CCing the IMAP
Extensions mailing list and IANA. A denial notice must be justified
by an explanation, and, in cases where it is possible, concrete
suggestions on how the request can be modified so as to become
acceptable should be provided.
For each response code, the registry contains a list of relevant RFCs
that describe (or extend) the response code and an optional response
code status description, such as "obsolete" or "reserved to prevent
collision with deployed software". (Note that in the latter case,
the RFC number can be missing.) Presence of the response code status
description means that the corresponding response code is NOT
RECOMMENDED for widespread use.
The intention is that any future allocation will be accompanied by a
published RFC (including direct submissions to the RFC Editor). But
in order to allow for the allocation of values prior to the RFC being
approved for publication, the Designated Expert can approve
allocations once it seems clear that an RFC will be published, for
example, before requesting IETF LC for the document.
The Designated Expert can also approve registrations for response
codes used in deployed software when no RFC exists. Such
registrations must be marked as "reserved to prevent collision with
deployed software".
Gulbrandsen Standards Track [Page 8]
RFC 5530 IMAP Response Codes May 2009
Response code registrations may not be deleted; response codes that
are no longer believed appropriate for use (for example, if there is
a problem with the syntax of said response code or if the
specification describing it was moved to Historic) should be marked
"obsolete" in the registry, clearly marking the lists published by
IANA.
7. Acknowledgements
Peter Coates, Mark Crispin, Philip Guenther, Alexey Melnikov, Ken
Murchison, Chris Newman, Timo Sirainen, Philip Van Hoof, Dale
Wiggins, and Sarah Wilkin helped with this document.
8. References
8.1. Normative References
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
9. Informative References
[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January
1997.
[RFC2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
2180, July 1997.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005.
Author's Address
Arnt Gulbrandsen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germany
Fax: +49 89 4502 9758
EMail: arnt@oryx.com
Gulbrandsen Standards Track [Page 9]

843
docs/rfcs/rfc5738.IMAP_UTF8.txt Normal file
View File

@ -0,0 +1,843 @@
Network Working Group P. Resnick
Request for Comments: 5738 Qualcomm Incorporated
Updates: 3501 C. Newman
Category: Experimental Sun Microsystems
March 2010
IMAP Support for UTF-8
Abstract
This specification extends the Internet Message Access Protocol
version 4rev1 (IMAP4rev1) to support UTF-8 encoded international
characters in user names, mail addresses, and message headers.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5738.
Copyright Notice
Copyright (c) 2010 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
(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.
Resnick & Newman Experimental [Page 1]
RFC 5738 IMAP Support for UTF-8 March 2010
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. UTF8=ACCEPT IMAP Capability . . . . . . . . . . . . . . . . . 3
3.1. IMAP UTF-8 Quoted Strings . . . . . . . . . . . . . . . . 3
3.2. UTF8 Parameter to SELECT and EXAMINE . . . . . . . . . . . 5
3.3. UTF-8 LIST and LSUB Responses . . . . . . . . . . . . . . 5
3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions . . . 6
3.4.1. UTF8 and UTF8ONLY LIST Selection Options . . . . . . . 6
3.4.2. UTF8 LIST Return Option . . . . . . . . . . . . . . . 6
4. UTF8=APPEND Capability . . . . . . . . . . . . . . . . . . . . 7
5. UTF8=USER Capability . . . . . . . . . . . . . . . . . . . . . 7
6. UTF8=ALL Capability . . . . . . . . . . . . . . . . . . . . . 7
7. UTF8=ONLY Capability . . . . . . . . . . . . . . . . . . . . . 8
8. Up-Conversion Server Requirements . . . . . . . . . . . . . . 8
9. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 14
Appendix B. Examples Demonstrating Relationships between
UTF8= Capabilities . . . . . . . . . . . . . . . . . 15
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
Resnick & Newman Experimental [Page 2]
RFC 5738 IMAP Support for UTF-8 March 2010
1. Introduction
This specification extends IMAP4rev1 [RFC3501] to permit UTF-8
[RFC3629] in headers as described in "Internationalized Email
Headers" [RFC5335]. It also adds a mechanism to support mailbox
names, login names, and passwords using the UTF-8 charset. This
specification creates five new IMAP capabilities to allow servers to
advertise these new extensions, along with two new IMAP LIST
selection options and a new IMAP LIST return option.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in "Key words for
use in RFCs to Indicate Requirement Levels" [RFC2119].
The formal syntax uses the Augmented Backus-Naur Form (ABNF)
[RFC5234] notation including the core rules defined in Appendix B of
[RFC5234]. In addition, rules from IMAP4rev1 [RFC3501], UTF-8
[RFC3629], "Collected Extensions to IMAP4 ABNF" [RFC4466], and IMAP4
LIST Command Extensions [RFC5258] are also referenced.
In examples, "C:" and "S:" indicate lines sent by the client and
server, respectively. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol
exchange.
3. UTF8=ACCEPT IMAP Capability
The "UTF8=ACCEPT" capability indicates that the server supports UTF-8
quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8
responses from the LIST and LSUB commands.
A client MUST use the "ENABLE UTF8=ACCEPT" command (defined in
[RFC5161]) to indicate to the server that the client accepts UTF-8
quoted-strings. The "ENABLE UTF8=ACCEPT" command MUST only be used
in the authenticated state. (Note that the "UTF8=ONLY" capability
described in Section 7 and the "UTF8=ALL" capability described in
Section 6 imply the "UTF8=ACCEPT" capability. See additional
information in these sections.)
3.1. IMAP UTF-8 Quoted Strings
The IMAP4rev1 [RFC3501] base specification forbids the use of 8-bit
characters in atoms or quoted strings. Thus, a UTF-8 string can only
be sent as a literal. This can be inconvenient from a coding
standpoint, and unless the server offers IMAP4 non-synchronizing
Resnick & Newman Experimental [Page 3]
RFC 5738 IMAP Support for UTF-8 March 2010
literals [RFC2088], this requires an extra round trip for each UTF-8
string sent by the client. When the IMAP server advertises the
"UTF8=ACCEPT" capability, it informs the client that it supports
native UTF-8 quoted-strings with the following syntax:
string =/ utf8-quoted
utf8-quoted = "*" DQUOTE *UQUOTED-CHAR DQUOTE
UQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4
; UTF8-2, UTF8-3, and UTF8-4 are as defined in RFC 3629
When this quoting mechanism is used by the client (specifically an
octet sequence beginning with *" and ending with "), then the server
MUST reject octet sequences with the high bit set that fail to comply
with the formal syntax in [RFC3629] with a BAD response.
The IMAP server MUST NOT send utf8-quoted syntax to the client unless
the client has indicated support for that syntax by using the "ENABLE
UTF8=ACCEPT" command.
If the server advertises the "UTF8=ACCEPT" capability, the client MAY
use utf8-quoted syntax with any IMAP argument that permits a string
(including astring and nstring). However, if characters outside the
US-ASCII repertoire are used in an inappropriate place, the results
would be the same as if other syntactically valid but semantically
invalid characters were used. For example, if the client includes
UTF-8 characters in the user or password arguments (and the server
has not advertised "UTF8=USER"), the LOGIN command will fail as it
would with any other invalid user name or password. Specific cases
where UTF-8 characters are permitted or not permitted are described
in the following paragraphs.
All IMAP servers that advertise the "UTF8=ACCEPT" capability SHOULD
accept UTF-8 in mailbox names, and those that also support the
"Mailbox International Naming Convention" described in RFC 3501,
Section 5.1.3 MUST accept utf8-quoted mailbox names and convert them
to the appropriate internal format. Mailbox names MUST comply with
the Net-Unicode Definition (Section 2 of [RFC5198]) with the specific
exception that they MUST NOT contain control characters (0000-001F,
0080-009F), delete (007F), line separator (2028), or paragraph
separator (2029).
An IMAP client MUST NOT issue a SEARCH command that uses a mixture of
utf8-quoted syntax and a SEARCH CHARSET other than UTF-8. If an IMAP
server receives such a SEARCH command, it SHOULD reject the command
with a BAD response (due to the conflicting charset labels).
Resnick & Newman Experimental [Page 4]
RFC 5738 IMAP Support for UTF-8 March 2010
3.2. UTF8 Parameter to SELECT and EXAMINE
The "UTF8=ACCEPT" capability also indicates that the server supports
the "UTF8" parameter to SELECT and EXAMINE. When a mailbox is
selected with the "UTF8" parameter, it alters the behavior of all
IMAP commands related to message sizes, message headers, and MIME
body headers so they refer to the message with UTF-8 headers. If the
mailstore is not UTF-8 header native and the SELECT or EXAMINE
command with UTF-8 header modifier succeeds, then the server MUST
return results as if the mailstore were UTF-8 header native with
upconversion requirements as described in Section 8. The server MAY
reject the SELECT or EXAMINE command with the [NOT-UTF-8] response
code, unless the "UTF8=ALL" or "UTF8=ONLY" capability is advertised.
Servers MAY include mailboxes that can only be selected or examined
if the "UTF8" parameter is provided. However, such mailboxes MUST
NOT be included in the output of an unextended LIST, LSUB, or
equivalent command. If a client attempts to SELECT or EXAMINE such
mailboxes without the "UTF8" parameter, the server MUST reject the
command with a [UTF-8-ONLY] response code. As a result, such
mailboxes will not be accessible by IMAP clients written prior to
this specification and are discouraged unless the server advertises
"UTF8=ONLY" or the server implements IMAP4 LIST Command Extensions
[RFC5258].
utf8-select-param = "UTF8"
;; Conforms to <select-param> from RFC 4466
C: a SELECT newmailbox (UTF8)
S: ...
S: a OK SELECT completed
C: b FETCH 1 (SIZE ENVELOPE BODY)
S: ... < UTF-8 header native results >
S: b OK FETCH completed
C: c EXAMINE legacymailbox (UTF8)
S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access
C: d SELECT funky-new-mailbox
S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client
3.3. UTF-8 LIST and LSUB Responses
After an IMAP client successfully issues an "ENABLE UTF8=ACCEPT"
command, the server MUST NOT return in LIST results any mailbox names
to the client following the IMAP4 Mailbox International Naming
Convention. Instead, the server MUST return any mailbox names with
characters outside the US-ASCII repertoire using utf8-quoted syntax.
Resnick & Newman Experimental [Page 5]
RFC 5738 IMAP Support for UTF-8 March 2010
(The IMAP4 Mailbox International Naming Convention has proved
problematic in the past, so the desire is to make this syntax
obsolete as quickly as possible.)
3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions
When an IMAP server advertises both the "UTF8=ACCEPT" capability and
the "LIST-EXTENDED" [RFC5258] capability, the server MUST support the
LIST extensions described in this section.
3.4.1. UTF8 and UTF8ONLY LIST Selection Options
The "UTF8" LIST selection option tells the server to include
mailboxes that only support UTF-8 headers in the output of the list
command. The "UTF8ONLY" LIST selection option tells the server to
include all mailboxes that support UTF-8 headers and to exclude
mailboxes that don't support UTF-8 headers. Note that "UTF8ONLY"
implies "UTF8", so it is not necessary for the client to request
both. Use of either selection option will also result in UTF-8
mailbox names in the result as described in Section 3.3 and implies
the "UTF8" List return option described in Section 3.4.2.
3.4.2. UTF8 LIST Return Option
If the client supplies the "UTF8" LIST return option, then the server
MUST include either the "\NoUTF8" or the "\UTF8Only" mailbox
attribute as appropriate. The "\NoUTF8" mailbox attribute indicates
that an attempt to SELECT or EXAMINE that mailbox with the "UTF8"
parameter will fail with a [NOT-UTF-8] response code. The
"\UTF8Only" mailbox attribute indicates that an attempt to SELECT or
EXAMINE that mailbox without the "UTF8" parameter will fail with a
[UTF-8-ONLY] response code. Note that computing this information may
be expensive on some server implementations, so this return option
should not be used unless necessary.
The ABNF [RFC5234] for these LIST extensions follows:
list-select-independent-opt =/ "UTF8"
list-select-base-opt =/ "UTF8ONLY"
mbx-list-oflag =/ "\NoUTF8" / "\UTF8Only"
return-option =/ "UTF8"
resp-text-code =/ "NOT-UTF-8" / "UTF-8-ONLY"
Resnick & Newman Experimental [Page 6]
RFC 5738 IMAP Support for UTF-8 March 2010
4. UTF8=APPEND Capability
If the "UTF8=APPEND" capability is advertised, then the server
accepts UTF-8 headers in the APPEND command message argument. A
client that sends a message with UTF-8 headers to the server MUST
send them using the "UTF8" APPEND data extension. If the server also
advertises the CATENATE capability (as specified in [RFC4469]), the
client can use the same data extension to include such a message in a
CATENATE message part. The ABNF for the APPEND data extension and
CATENATE extension follows:
utf8-literal = "UTF8" SP "(" literal8 ")"
append-data =/ utf8-literal
cat-part =/ utf8-literal
A server that advertises "UTF8=APPEND" has to comply with the
requirements of the IMAP base specification and [RFC5322] for message
fetching. Mechanisms for 7-bit downgrading to help comply with the
standards are discussed in Downgrading mechanism for
Internationalized eMail Address (IMA) [RFC5504].
IMAP servers that do not advertise the "UTF8=APPEND" or "UTF8=ONLY"
capability SHOULD reject an APPEND command that includes any 8-bit in
the message headers with a "NO" response.
Note that the "UTF8=ONLY" capability described in Section 7 implies
the "UTF8=APPEND" capability. See additional information in that
section.
5. UTF8=USER Capability
If the "UTF8=USER" capability is advertised, that indicates the
server accepts UTF-8 user names and passwords and applies SASLprep
[RFC4013] to both arguments of the LOGIN command. The server MUST
reject UTF-8 that fails to comply with the formal syntax in RFC 3629
[RFC3629] or if it encounters Unicode characters listed in Section
2.3 of SASLprep RFC 4013 [RFC4013].
6. UTF8=ALL Capability
The "UTF8=ALL" capability indicates all server mailboxes support
UTF-8 headers. Specifically, SELECT and EXAMINE with the "UTF8"
parameter will never fail with a [NOT-UTF-8] response code.
Resnick & Newman Experimental [Page 7]
RFC 5738 IMAP Support for UTF-8 March 2010
Note that the "UTF8=ONLY" capability described in Section 7 implies
the "UTF8=ALL" capability. See additional information in that
section.
Note that the "UTF8=ALL" capability implies the "UTF8=ACCEPT"
capability.
7. UTF8=ONLY Capability
The "UTF8=ONLY" capability permits an IMAP server to advertise that
it does not support the international mailbox name convention
(modified UTF-7), and does not permit selection or examination of any
mailbox unless the "UTF8" parameter is provided. As this is an
incompatible change to IMAP, a clear warning is necessary. IMAP
clients that find implementation of the "UTF8=ONLY" capability
problematic are encouraged to at least detect the "UTF8=ONLY"
capability and provide an informative error message to the end-user.
When an IMAP mailbox internally uses UTF-8 header native storage, the
down-conversion step is necessary to permit selection or examination
of the mailbox in a backwards compatible fashion will become more
difficult to support. Although it is hoped that deployed IMAP
servers will not advertise "UTF8=ONLY" for some years, this
capability is intended to minimize the disruption when legacy support
finally goes away.
The "UTF8=ONLY" capability implies the "UTF8=ACCEPT" capability, the
"UTF8=ALL" capability, and the "UTF8=APPEND" capability. A server
that advertises "UTF8=ONLY" need not advertise the three implicit
capabilities.
8. Up-Conversion Server Requirements
When an IMAP4 server uses a traditional mailbox format that includes
7-bit headers and it chooses to permit access to that mailbox with
the "UTF8" parameter, it MUST support minimal up-conversion as
described in this section.
The server MUST support up-conversion of the following address
header-fields in the message header: From, Sender, To, CC, Bcc,
Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and
Reply-To. This up-conversion MUST include address local-parts in
fields downgraded according to [RFC5504], address domains encoded
according to Internationalizing Domain Names in Applications (IDNA)
[RFC3490], and MIME header encoding [RFC2047] of display-names and
any [RFC5322] comments.
Resnick & Newman Experimental [Page 8]
RFC 5738 IMAP Support for UTF-8 March 2010
The following charsets MUST be supported for up-conversion of MIME
header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2,
ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7,
ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15.
If the server supports other charsets in IMAP SEARCH or IMAP CONVERT
[RFC5259], it SHOULD also support those charsets in this conversion.
Up-conversion of MIME header encoding of the following headers MUST
also be implemented: Subject, Date ([RFC5322] comments only),
Comments, Keywords, and Content-Description.
Server implementations also SHOULD up-convert all MIME body headers
[RFC2045], SHOULD up-convert or remove the deprecated (and misused)
"name" parameter [RFC1341] on Content-Type, and MUST up-convert the
Content-Disposition [RFC2183] "filename" parameter, except when any
of these are contained within a multipart/signed MIME body part (see
below). These parameters can be encoded using the standard MIME
parameter encoding [RFC2231] mechanism, or via non-standard use of
MIME header encoding [RFC2047] in quoted strings.
The IMAP server MUST NOT perform up-conversion of headers and content
of multipart/signed, as well as Original-Recipient and Return-Path.
9. Issues with UTF-8 Header Mailstore
When an IMAP server uses a mailbox format that supports UTF-8 headers
and it permits selection or examination of that mailbox without the
"UTF8" parameter, it is the responsibility of the server to comply
with the IMAP4rev1 base specification [RFC3501] and [RFC5322] with
respect to all header information transmitted over the wire.
Mechanisms for 7-bit downgrading to help comply with the standards
are discussed in "Downgrading Mechanism for Email Address
Internationalization" [RFC5504].
An IMAP server with a mailbox that supports UTF-8 headers MUST comply
with the protocol requirements implicit from Section 8. However, the
code necessary for such compliance need not be part of the IMAP
server itself in this case. For example, the minimal required up-
conversion could be performed when a message is inserted into the
IMAP-accessible mailbox.
10. IANA Considerations
This adds five new capabilities ("UTF8=ACCEPT", "UTF8=USER",
"UTF8=APPEND", "UTF8=ALL", and "UTF8=ONLY") to the IMAP4rev1
Capabilities registry [RFC3501].
Resnick & Newman Experimental [Page 9]
RFC 5738 IMAP Support for UTF-8 March 2010
This adds two new IMAP4 list selection options and one new IMAP4 list
return option.
1. LIST-EXTENDED option name: UTF8
LIST-EXTENDED option type: SELECTION
Implied return options(s): UTF8
LIST-EXTENDED option description: Causes the LIST response to
include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter.
Published specification: RFC 5738, Section 3.4.1
Security considerations: RFC 5738, Section 11
Intended usage: COMMON
Person and email address to contact for further information: see
the Authors' Addresses at the end of this specification
Owner/Change controller: iesg@ietf.org
2. LIST-EXTENDED option name: UTF8ONLY
LIST-EXTENDED option type: SELECTION
Implied return options(s): UTF8
LIST-EXTENDED option description: Causes the LIST response to
include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter
and exclude mailboxes that do not support the UTF8 SELECT/EXAMINE
parameter.
Published specification: RFC 5738, Section 3.4.1
Security considerations: RFC 5738, Section 11
Intended usage: COMMON
Person and email address to contact for further information: see
the Authors' Addresses at the end of this specification
Owner/Change controller: iesg@ietf.org
Resnick & Newman Experimental [Page 10]
RFC 5738 IMAP Support for UTF-8 March 2010
3. LIST-EXTENDED option name: UTF8
LIST-EXTENDED option type: RETURN
Implied return options(s): none
LIST-EXTENDED option description: Causes the LIST response to
include \NoUTF8 and \UTF8Only mailbox attributes.
Published specification: RFC 5738, Section 3.4.1
Security considerations: RFC 5738, Section 11
Intended usage: COMMON
Person and email address to contact for further information: see
the Authors' Addresses at the end of this specification
Owner/Change controller: iesg@ietf.org
11. Security Considerations
The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013]
apply to this specification, particularly with respect to use of
UTF-8 in user names and passwords. Otherwise, this is not believed
to alter the security considerations of IMAP4rev1.
12. References
12.1. Normative References
[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
Mail Extensions): Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1341,
June 1992.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Resnick & Newman Experimental [Page 11]
RFC 5738 IMAP Support for UTF-8 March 2010
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions:
Character Sets, Languages, and Continuations", RFC 2231,
November 1997.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006.
[RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP)
CATENATE Extension", RFC 4469, April 2006.
[RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE
Extension", RFC 5161, March 2008.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
Protocol version 4 - LIST Command Extensions", RFC 5258,
June 2008.
[RFC5259] Melnikov, A. and P. Coates, "Internet Message Access
Protocol - CONVERT Extension", RFC 5259, July 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
Resnick & Newman Experimental [Page 12]
RFC 5738 IMAP Support for UTF-8 March 2010
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335,
September 2008.
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for
Email Address Internationalization", RFC 5504, March 2009.
12.2. Informative References
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996.
[RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
January 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8",
RFC 5721, February 2010.
Resnick & Newman Experimental [Page 13]
RFC 5738 IMAP Support for UTF-8 March 2010
Appendix A. Design Rationale
This non-normative section discusses the reasons behind some of the
design choices in the above specification.
The basic approach of advertising the ability to access a mailbox in
UTF-8 mode is intended to permit graceful upgrade, including servers
that support multiple mailbox formats. In particular, it would be
undesirable to force conversion of an entire server mailstore to
UTF-8 headers, so being able to phase-in support for new mailboxes
and gradually migrate old mailboxes is permitted by this design.
"UTF8=USER" is optional because many identity systems are US-ASCII
only, so it's helpful to inform the client up front that UTF-8 won't
work.
"UTF8=APPEND" is optional because it effectively requires IMAP server
support for down-conversion, which is a much more complex operation
than up-conversion.
The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability
problems when legacy support goes away. In the situation where
backwards compatibility is broken anyway, just-send-UTF-8 IMAP has
the advantage that it might work with some legacy clients. However,
the difficulty of diagnosing interoperability problems caused by a
just-send-UTF-8 IMAP mechanism is the reason the "UTF8=ONLY"
capability mechanism was chosen.
The up-conversion requirements are designed to balance the desire to
deprecate and eventually eliminate complicated encodings (like MIME
header encodings) without creating a significant deployment burden
for servers. As IMAP4 servers already require a MIME parser, this
includes additional server up-conversion requirements not present in
POP3 Support for UTF-8 [RFC5721].
The set of mandatory charsets comes from two sources: MIME
requirements [RFC2049] and IETF Policy on Character Sets [RFC2277].
Including a requirement to up-convert widely deployed encoded
ideographic charsets to UTF-8 would be reasonable for most scenarios,
but may require unacceptable table sizes for some embedded devices.
The open-ended recommendation to support widely deployed charsets
avoids the political ramifications of attempting to list such
charsets. The authors believe market forces, existing open-source
software, and public conversion tables are sufficient to deploy the
appropriate charsets.
Resnick & Newman Experimental [Page 14]
RFC 5738 IMAP Support for UTF-8 March 2010
Appendix B. Examples Demonstrating Relationships between UTF8=
Capabilities
UTF8=ACCEPT UTF8=USER UTF8=APPEND
UTF8=ACCEPT UTF8=ALL
UTF8=ALL ; Note, same as above
UTF8=ACCEPT UTF8=USER UTF8=APPEND UTF8=ALL UTF8=ONLY
UTF8=USER UTF8=ONLY ; Note, same as above
Appendix C. Acknowledgments
The authors wish to thank the participants of the EAI working group
for their contributions to this document with particular thanks to
Harald Alvestrand, David Black, Randall Gellens, Arnt Gulbrandsen,
Kari Hurtta, John Klensin, Xiaodong Lee, Charles Lindsey, Alexey
Melnikov, Subramanian Moonesamy, Shawn Steele, Daniel Taharlev, and
Joseph Yee for their specific contributions to the discussion.
Authors' Addresses
Pete Resnick
Qualcomm Incorporated
5775 Morehouse Drive
San Diego, CA 92121-1714
US
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: http://www.qualcomm.com/~presnick/
Chris Newman
Sun Microsystems
800 Royal Oaks
Monrovia, CA 91016
US
EMail: chris.newman@sun.com
Resnick & Newman Experimental [Page 15]

619
docs/rfcs/rfc5788.IMAP4_Keyword_registry.txt Normal file
View File

@ -0,0 +1,619 @@
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 5788 D. Cridland
Category: Standards Track Isode Limited
ISSN: 2070-1721 March 2010
IMAP4 Keyword Registry
Abstract
The aim of this document is to establish a new IANA registry for IMAP
keywords and to define a procedure for keyword registration, in order
to improve interoperability between different IMAP clients.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5788.
Copyright Notice
Copyright (c) 2010 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
(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.
Melnikov & Cridland Standards Track [Page 1]
RFC 5788 IMAP4 Keyword Registry March 2010
Table of Contents
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. IANA Considerations .............................................3
3.1. Review Guidelines for the Designated Expert Reviewer .......4
3.2. Comments on IMAP Keywords' Registrations ...................5
3.3. Change Control .............................................5
3.4. Initial Registrations ......................................6
3.4.1. $MDNSent IMAP Keyword Registration ..................6
3.4.2. $Forwarded IMAP Keyword Registration ................7
3.4.3. $SubmitPending IMAP Keyword Registration ............8
3.4.4. $Submitted IMAP Keyword Registration ................9
4. Security Considerations ........................................10
5. Acknowledgements ...............................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
1. Introduction
IMAP keywords [RFC3501] are boolean named flags that can be used by
clients to annotate messages in an IMAP mailbox. Although IMAP
keywords are an optional feature of IMAP, the majority of IMAP
servers can store arbitrary keywords. Many mainstream IMAP clients
use a limited set of specific keywords, and some can manage (create,
edit, display) arbitrary IMAP keywords.
Over the years, some IMAP keywords have become de-facto standards,
with some specific semantics associated with them. In some cases,
different client implementors decided to define and use keywords with
different names, but the same semantics. Some server implementors
decided to map such keywords automatically in order to improve cross-
client interoperability.
In other cases, the same keywords have been used with different
semantics, thus causing interoperability problems.
This document attempts to prevent further incompatible uses of IMAP
keywords by establishing an "IMAP Keywords" registry and allocating a
special prefix for standardized keywords.
2. Conventions Used in This Document
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 [Kwds].
Melnikov & Cridland Standards Track [Page 2]
RFC 5788 IMAP4 Keyword Registry March 2010
3. IANA Considerations
IANA has established a new registry for IMAP keywords.
Registration of an IMAP keyword is requested by filling in the
following template and following the instructions on the IANA pages
for the registry to submit it to IANA:
Subject: Registration of IMAP keyword X
IMAP keyword name:
Purpose (description):
Private or Shared on a server: (One of PRIVATE, SHARED, or BOTH.
PRIVATE means that each different
user has a distinct copy of the
keyword. SHARED means that all
different users see the same value of
the keyword. BOTH means that an IMAP
server can have the keyword as either
private or shared.)
Is it an advisory keyword or may it cause an automatic action:
When/by whom the keyword is set/cleared:
Related keywords: (for example, "mutually exclusive with keywords Y
and Z")
Related IMAP capabilities:
Security considerations:
Published specification (recommended):
Person & email address to contact for further information:
Intended usage: (One of COMMON, LIMITED USE, or DEPRECATED (i.e.,
not recommended for use))
Owner/Change controller: (MUST be "IESG" for any "common use"
keyword registration specified in an IETF
Review document. See definition of "common
use" below in this section. When the
Owner/Change controller is not a
Standardization Organization, the
registration request MUST make it clear if
Melnikov & Cridland Standards Track [Page 3]
RFC 5788 IMAP4 Keyword Registry March 2010
the registration is controlled by a
company, or the individual performing the
registration.)
Note: (Any other information that the author deems interesting
may be added here, for example, if the keyword(s) is
supported by existing clients.)
Registration of an IMAP keyword requires Expert Review [RFC5226].
Registration of any IMAP keyword is initiated by posting a
registration request to the Message Organization WG mailing list
<morg@ietf.org> (or its replacement as chosen by the responsible
Application Area Director) and CCing IANA (<iana@iana.org>). After
allowing for at least two weeks for community input on the designated
mailing list, the expert will determine the appropriateness of the
registration request and either approve or disapprove the request
with notice to the requestor, the mailing list, and IANA. Any
refusal must come with a clear explanation.
The IESG appoints one or more Expert Reviewers for the IMAP keyword
registry established by this document.
The Expert Reviewer should strive for timely reviews. The Expert
Reviewer should take no longer than six weeks to make and announce
the decision, or notify the mailing list that more time is required.
Decisions (or lack of) made by an Expert Reviewer can be first
appealed to Application Area Directors and, if the appellant is not
satisfied with the response, to the full IESG.
There are two types of IMAP keywords in the "IMAP Keywords" registry:
intended for "common use" and vendor-/organization-specific use (also
known as "limited use"). An IMAP keyword is said to be for "common
use" if it is reasonably expected to be implemented in at least two
independent client implementations. The two types of IMAP keywords
have different levels of requirements for registration (see below).
3.1. Review Guidelines for the Designated Expert Reviewer
Expert Reviewers should focus on the following requirements.
Registration of a vendor-/organization-specific ("limited use") IMAP
keyword is easier. The Expert Reviewer only needs to check that the
requested name doesn't conflict with an already registered name, and
that the name is not too generic, misleading, etc. The Expert
Reviewer MAY request the IMAP keyword name change before approving
Melnikov & Cridland Standards Track [Page 4]
RFC 5788 IMAP4 Keyword Registry March 2010
the registration. The Expert Reviewer SHOULD refuse a registration
if there is an already registered IMAP keyword that serves the same
purpose, but has a different name.
When registering an IMAP keyword for "common use", the Expert
Reviewer performs the checks described for vendor-/
organization-specific IMAP keywords, plus additional checks as
detailed below.
Keywords intended for "common use" SHOULD start with the "$" prefix.
(Note that this is a SHOULD because some of the commonly used IMAP
keywords in widespread use don't follow this convention.)
IMAP keywords intended for "common use" SHOULD be standardized in
IETF Review [RFC5226] documents. (Note that IETF Review documents
still require Expert Review.)
Values in the "IMAP Keywords" IANA registry intended for "common use"
must be clearly documented and likely to ensure interoperability.
They must be useful, not harmful to the Internet. In cases when an
IMAP keyword being registered is already deployed, Expert Reviewers
should favor registering it over requiring perfect documentation
and/or requesting a change to the name of the IMAP keyword.
The Expert Reviewer MAY automatically "upgrade" registration requests
for a "limited use" IMAP keyword to "common use" level. The Expert
Reviewer MAY also request that a registration targeted for "common
use" be registered as "limited use" instead.
3.2. Comments on IMAP Keywords' Registrations
Comments on registered IMAP keywords should be sent to both the
"owner" of the mechanism and to the mailing list designated to IMAP
keyword review (see Section 3). This improves the chances of getting
a timely response.
Submitters of comments may, after a reasonable attempt to contact the
owner and after soliciting comments on the IMAP mailing list, request
the designated Expert Reviewer to attach their comment to the IMAP
keyword registration itself. The procedure is similar to requesting
an Expert Review for the affected keyword.
3.3. Change Control
Once an IMAP keyword registration has been published by IANA, the
owner may request a change to its definition. The change request
(including a change to the "intended usage" field) follows the same
procedure as the initial registration request, with the exception of
Melnikov & Cridland Standards Track [Page 5]
RFC 5788 IMAP4 Keyword Registry March 2010
changes to the "Person & email address to contact for further
information" and "Owner/Change controller" fields. The latter can be
changed by the owner by informing IANA; this can be done without
discussion or review.
The IESG may reassign responsibility for an IMAP keyword. The most
common case of this will be to enable clarifications to be made to
keywords where the owner of the registration has died, moved out of
contact, or is otherwise unable to make changes that are important to
the community.
IMAP keyword registrations MUST NOT be deleted; keywords that are no
longer believed appropriate for use can be declared DEPRECATED by a
change to their "intended usage" field.
The IESG is considered the owner of all "common use" IMAP keywords
that are published in an IETF Review document.
3.4. Initial Registrations
IANA has registered the IMAP keywords specified in following
subsections in the registry established by this document.
3.4.1. $MDNSent IMAP Keyword Registration
Subject: Registration of IMAP keyword $MDNSent
IMAP keyword name: $MDNSent
Purpose (description): Specifies that a Message Disposition
Notification (MDN) must not be sent for any
message annotated with the $MDNSent IMAP
keyword.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action:
This keyword can cause automatic action by
the client. See [RFC3503] for more details.
When/by whom the keyword is set/cleared:
This keyword is set by an IMAP client when it
decides to act on an MDN request, or when
uploading a sent or draft message. It can
also be set by a delivery agent. Once set,
the flag SHOULD NOT be cleared.
Melnikov & Cridland Standards Track [Page 6]
RFC 5788 IMAP4 Keyword Registry March 2010
Related keywords: None
Related IMAP capabilities: None
Security considerations: See Section 6 of [RFC3503]
Published specification (recommended): [RFC3503]
Person & email address to contact for further information:
Alexey Melnikov <alexey.melnikov@isode.com>
Intended usage: COMMON
Owner/Change controller: IESG
Note:
3.4.2. $Forwarded IMAP Keyword Registration
Subject: Registration of the IMAP keyword $Forwarded
IMAP keyword name: $Forwarded
Purpose (description): $Forwarded is used by several IMAP clients to
specify that the message was resent to
another email address, embedded within or
attached to a new message. This keyword is
set by the mail client when it successfully
forwards the message to another email
address. Typical usage of this keyword is to
show a different (or additional) icon for a
message that has been forwarded.
Private or Shared on a server: BOTH
Is it an advisory keyword or may it cause an automatic action:
advisory
When/by whom the keyword is set/cleared:
This keyword can be set by either a delivery
agent or a mail client. Once set, the flag
SHOULD NOT be cleared. Notes: There is no
way to tell if a message with $Forwarded
keyword set was forwarded more than once.
Related keywords: None
Related IMAP capabilities: None
Melnikov & Cridland Standards Track [Page 7]
RFC 5788 IMAP4 Keyword Registry March 2010
Security considerations: A server implementing this keyword as a
shared keyword may disclose that a
confidential message was forwarded.
Published specification (recommended): [RFC5550]
Person & email address to contact for further information:
Alexey Melnikov <alexey.melnikov@isode.com>
Intended usage: COMMON
Owner/Change controller: IESG
Note:
3.4.3. $SubmitPending IMAP Keyword Registration
Subject: Registration of IMAP keyword $SubmitPending
IMAP keyword name: $SubmitPending
Purpose (description): The $SubmitPending IMAP keyword designates
the message as awaiting to be submitted.
This keyword allows storing messages waiting
to be submitted in the same mailbox where
messages that were already submitted and/or
are being edited are stored.
A message that has both $Submitted and
$SubmitPending IMAP keywords set is a message
being actively submitted.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action:
This keyword can cause automatic action by
the client. See Section 5.10 of [RFC5550]
for more details.
When/by whom the keyword is set/cleared:
This keyword is set by a mail client when it
decides that the message needs to be sent
out.
Related keywords: $Submitted
Related IMAP capabilities: None
Melnikov & Cridland Standards Track [Page 8]
RFC 5788 IMAP4 Keyword Registry March 2010
Security considerations: A server implementing this keyword as a
shared keyword may disclose that a
confidential message is scheduled to be
sent out or is being actively sent out.
Published specification (recommended): [RFC5550]
Person & email address to contact for further information:
Alexey Melnikov <alexey.melnikov@isode.com>
Intended usage: COMMON
Owner/Change controller: IESG
Note:
3.4.4. $Submitted IMAP Keyword Registration
Subject: Registration of IMAP keyword $Submitted
IMAP keyword name: $Submitted
Purpose (description): The $Submitted IMAP keyword designates the
message as being sent out.
A message that has both $Submitted and
$SubmitPending IMAP keywords set is a message
being actively submitted.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action:
This keyword can cause automatic action by
the client. See Section 5.10 of [RFC5550]
for more details.
When/by whom the keyword is set/cleared:
This keyword is set by a mail client when it
decides to start sending it.
Related keywords: $SubmitPending
Related IMAP capabilities: None
Security considerations: A server implementing this keyword as a
shared keyword may disclose that a
confidential message was sent or is being
actively sent out.
Melnikov & Cridland Standards Track [Page 9]
RFC 5788 IMAP4 Keyword Registry March 2010
Published specification (recommended): [RFC5550]
Person & email address to contact for further information:
Alexey Melnikov <alexey.melnikov@isode.com>
Intended usage: COMMON
Owner/Change controller: IESG
Note:
4. Security Considerations
IMAP keywords are one of the base IMAP features [RFC3501]. This
document doesn't change their behavior, so it does not add new
security issues.
A particular IMAP keyword might have specific security
considerations, which are documented in the IMAP keyword
registration template standardized by this document.
5. Acknowledgements
The creation of this document was prompted by one of many discussions
on the IMAP mailing list.
John Neystadt co-authored the first version of this document.
Special thanks to Chris Newman, David Harris, Lyndon Nerenberg, Mark
Crispin, Samuel Weiler, Alfred Hoenes, Lars Eggert, and Cullen
Jennings for reviewing different versions of this document. However,
all errors or omissions must be attributed to the authors of this
document.
The authors would also like to thank the developers of Mozilla mail
clients for providing food for thought.
6. References
6.1. Normative References
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
Melnikov & Cridland Standards Track [Page 10]
RFC 5788 IMAP4 Keyword Registry March 2010
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
6.2. Informative References
[RFC3503] Melnikov, A., "Message Disposition Notification (MDN)
profile for Internet Message Access Protocol (IMAP)",
RFC 3503, March 2003.
[RFC5550] Cridland, D., Melnikov, A., and S. Maes, "The Internet
Email to Support Diverse Service Environments (Lemonade)
Profile", RFC 5550, August 2009.
Authors' Addresses
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/
Dave Cridland
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
EMail: dave.cridland@isode.com
Melnikov & Cridland Standards Track [Page 11]

339
docs/rfcs/rfc5819.IMAP4_extension_Returning_STATUS_info_in_LIST.txt Normal file
View File

@ -0,0 +1,339 @@
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 5819 Isode Limited
Category: Standards Track T. Sirainen
ISSN: 2070-1721 Unaffiliated
March 2010
IMAP4 Extension for Returning STATUS Information in Extended LIST
Abstract
Many IMAP clients display information about total number of
messages / total number of unseen messages in IMAP mailboxes. In
order to do that, they are forced to issue a LIST or LSUB command and
to list all available mailboxes, followed by a STATUS command for
each mailbox found. This document provides an extension to LIST
command that allows the client to request STATUS information for
mailboxes together with other information typically returned by the
LIST command.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5819.
Copyright Notice
Copyright (c) 2010 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
(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.
Melnikov & Sirainen Standards Track [Page 1]
RFC 5819 TITLE* March 2010
Table of Contents
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. STATUS Return Option to LIST Command ............................2
3. Examples ........................................................3
4. Formal Syntax ...................................................4
5. Security Considerations .........................................4
6. IANA Considerations .............................................4
7. Acknowledgements ................................................5
8. Normative References ............................................5
1. Introduction
Many IMAP clients display information about the total number of
messages / total number of unseen messages in IMAP mailboxes. In
order to do that, they are forced to issue a LIST or LSUB command and
to list all available mailboxes, followed by a STATUS command for
each mailbox found. This document provides an extension to LIST
command that allows the client to request STATUS information for
mailboxes together with other information typically returned by the
LIST command.
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 [Kwds].
2. STATUS Return Option to LIST Command
[RFC3501] explicitly disallows mailbox patterns in the STATUS
command. The main reason was to discourage frequent use of the
STATUS command by clients, as it might be quite expensive for an IMAP
server to perform. However, this prohibition had resulted in an
opposite effect: a new generation of IMAP clients appeared, that
issues a STATUS command for each mailbox returned by the LIST
command. This behavior is suboptimal to say at least. It wastes
extra bandwidth and, in the case of a client that doesn't support
IMAP pipelining, also degrades performance by using too many round
trips. This document tries to remedy the situation by specifying a
single command that can be used by the client to request all the
necessary information. In order to achieve this goal, this document
is extending the LIST command with a new return option, STATUS. This
option takes STATUS data items as parameters. For each selectable
Melnikov & Sirainen Standards Track [Page 2]
RFC 5819 TITLE* March 2010
mailbox matching the list pattern and selection options, the server
MUST return an untagged LIST response followed by an untagged STATUS
response containing the information requested in the STATUS return
option.
If an attempted STATUS for a listed mailbox fails because the mailbox
can't be selected (e.g., if the "l" ACL right [ACL] is granted to the
mailbox and the "r" right is not granted, or due to a race condition
between LIST and STATUS changing the mailbox to \NoSelect), the
STATUS response MUST NOT be returned and the LIST response MUST
include the \NoSelect attribute. This means the server may have to
buffer the LIST reply until it has successfully looked up the
necessary STATUS information.
If the server runs into unexpected problems while trying to look up
the STATUS information, it MAY drop the corresponding STATUS reply.
In such a situation, the LIST command would still return a tagged OK
reply.
3. Examples
C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN))
S: * LIST () "." "INBOX"
S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16)
S: * LIST () "." "foo"
S: * STATUS "foo" (MESSAGES 30 UNSEEN 29)
S: * LIST (\NoSelect) "." "bar"
S: A01 OK List completed.
The "bar" mailbox isn't selectable, so it has no STATUS reply.
C: A02 LIST (SUBSCRIBED RECURSIVEMATCH)"" % RETURN (STATUS
(MESSAGES))
S: * LIST (\Subscribed) "." "INBOX"
S: * STATUS "INBOX" (MESSAGES 17)
S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
S: A02 OK List completed.
The LIST reply for "foo" is returned because it has matching
children, but no STATUS reply is returned because "foo" itself
doesn't match the selection criteria.
Melnikov & Sirainen Standards Track [Page 3]
RFC 5819 TITLE* March 2010
4. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [ABNF]. Terms not defined here are taken
from [RFC3501] and [LISTEXT].
return-option =/ status-option
status-option = "STATUS" SP "(" status-att *(SP status-att) ")"
;; This ABNF production complies with
;; <option-extension> syntax.
5. Security Considerations
This extension makes it a bit easier for clients to overload the
server by requesting STATUS information for a large number of
mailboxes. However, as already noted in the introduction, existing
clients already try to do that by generating a large number of STATUS
commands for each mailbox in which they are interested. While
performing STATUS information retrieval for big lists of mailboxes, a
server implementation needs to make sure that it can still serve
other IMAP connections and yield execution to other connections, when
necessary.
6. IANA Considerations
IMAP4 capabilities are registered by publishing a Standards Track or
IESG-approved Experimental RFC. The "IMAP 4 Capabilities" registry
is available from the IANA webiste:
http://www.iana.org
This document defines the LIST-STATUS IMAP capability. IANA has
added it to the registry.
IANA has also added the following new LIST-EXTENDED option to the
IANA registry established by [LISTEXT]:
To: iana@iana.org
Subject: Registration of LIST-EXTENDED option STATUS
LIST-EXTENDED option name: STATUS
LIST-EXTENDED option type: RETURN
LIST-EXTENDED option description: Causes the LIST command to return
STATUS responses in addition to LIST responses.
Melnikov & Sirainen Standards Track [Page 4]
RFC 5819 TITLE* March 2010
Published specification: RFC 5819
Security considerations: RFC 5819
Intended usage: COMMON
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org
7. Acknowledgements
Thanks to Philip Van Hoof who pointed out that STATUS and LIST
commands should be combined in order to optimize traffic and number
of round trips.
8. Normative References
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
[ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005.
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LISTEXT] Leiba, B. and A. Melnikov, "Internet Message Access
Protocol version 4 - LIST Command Extensions", RFC 5258,
June 2008.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
Melnikov & Sirainen Standards Track [Page 5]
RFC 5819 TITLE* March 2010
Authors' Addresses
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/
Timo Sirainen
EMail: tss@iki.fi
Melnikov & Sirainen Standards Track [Page 6]

283
docs/rfcs/rfc5957.IMAP4_SORT_extension.txt Normal file
View File

@ -0,0 +1,283 @@
Internet Engineering Task Force (IETF) D. Karp
Request for Comments: 5957 Zimbra
Updates: 5256 July 2010
Category: Standards Track
ISSN: 2070-1721
Display-Based Address Sorting for the IMAP4 SORT Extension
Abstract
This document describes an IMAP protocol extension enabling server-
side message sorting on the commonly displayed portion of the From
and To header fields.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5957.
Copyright Notice
Copyright (c) 2010 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
(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.
Karp IMAP4 Display-Based Address Sorting [Page 1]
RFC 5957 July 2010
Table of Contents
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. DISPLAY Sort Value for an Address ...............................2
4. The DISPLAYFROM and DISPLAYTO Sort Criteria .....................3
5. Formal Syntax ...................................................3
6. Security Considerations .........................................3
7. Internationalization Considerations .............................4
8. IANA Considerations .............................................4
9. Normative References ............................................4
1. Introduction
The [SORT] extension to the [IMAP] protocol provides a means for the
server-based sorting of messages. It defines a set of sort criteria
and the mechanism for determining the sort value of a message for
each such ordering.
The [SORT] FROM and TO orderings sort messages lexically on the
[IMAP] addr-mailbox of the first address in the message's From and To
headers, respectively. This document provides two alternative
orderings, DISPLAYFROM and DISPLAYTO, which sort messages based on
the first From or To address's [IMAP] addr-name (generally the same
as its [RFC5322] display-name), when present.
A server that supports the full [SORT] extension as well as both the
DISPLAYFROM and DISPLAYTO sort criteria indicates this by returning
"SORT=DISPLAY" in its CAPABILITY response.
2. Conventions Used in This Document
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 [RFC2119].
3. DISPLAY Sort Value for an Address
For the purposes of the sort criteria defined in this document, the
sort value for an [IMAP] address structure is defined as follows:
o If the address structure's [IMAP] addr-name is non-NIL, apply the
procedure from [RFC5255], Section 4.6. (That is, decode any
[RFC2047] encoded-words and convert the resulting character string
into a charset valid for the currently active [RFC4790] collation,
with a default of UTF-8.) If the resulting octet string is not
the empty string, use it as the sort value for the address.
Karp IMAP4 Display-Based Address Sorting [Page 2]
RFC 5957 July 2010
o Otherwise, if the address structure's [IMAP] addr-mailbox and
[IMAP] addr-host are both non-NIL, the sort value for the address
is addr-mailbox@addr-host.
o Otherwise, if the address structure's [IMAP] addr-mailbox is non-
NIL, the sort value for the address is its addr-mailbox.
o If none of the above conditions are met, the sort value for the
address is the empty string.
4. The DISPLAYFROM and DISPLAYTO Sort Criteria
This document introduces two new [SORT] sort criteria, DISPLAYFROM
and DISPLAYTO. A message's sort value under these orderings MUST be
derived as follows:
A "derived-addr" value is created from the [IMAP] envelope structure
resulting from a FETCH ENVELOPE on the message. For DISPLAYFROM, the
derived-addr value is the [IMAP] env-from value. For DISPLAYTO, the
derived-addr value is the [IMAP] env-to value.
o If the derived-addr value is NIL, the message's sort value is the
empty string.
o Otherwise, the message's sort value is the DISPLAY sort value of
the first [IMAP] address in the derived-addr value.
5. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234]. [IMAP] defines the
non-terminal "capability", and [SORT] defines "sort-key".
capability =/ "SORT=DISPLAY"
sort-key =/ "DISPLAYFROM" / "DISPLAYTO"
6. Security Considerations
This document defines an additional IMAP4 capability. As such, it
does not change the underlying security considerations of [IMAP].
The author believes that no new security issues are introduced with
this additional IMAP4 capability.
Karp IMAP4 Display-Based Address Sorting [Page 3]
RFC 5957 July 2010
7. Internationalization Considerations
DISPLAYFROM and DISPLAYTO are string-based sort criteria. As stated
in [SORT], the active [RFC4790] collation as per [RFC5255] MUST be
used when sorting such strings.
The DISPLAYFROM and DISPLAYTO orderings sort on the full decoded
[IMAP] addr-name, when present. They do not attempt to parse this
string in a locale- or language-dependent manner in order to
determine and sort on some semantically meaningful substring such as
the surname.
8. IANA Considerations
[IMAP] capabilities are registered by publishing a Standards Track or
IESG-approved Experimental RFC. This document constitutes
registration of the SORT=DISPLAY capability in the [IMAP]
capabilities registry.
9. Normative References
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, March
2007.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
[RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
Message Access Protocol Internationalization", RFC 5255,
June 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
Karp IMAP4 Display-Based Address Sorting [Page 4]
RFC 5957 July 2010
[SORT] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256, June
2008.
Author's Address
Dan Karp
Zimbra
3401 Hillview Avenue
Palo Alto, CA 94304
USA
EMail: dkarp@zimbra.com
URI: http://www.zimbra.com
Karp IMAP4 Display-Based Address Sorting [Page 5]

675
docs/rfcs/rfc6154.IMAP_LIST_Special-use_Mailboxes.txt Normal file
View File

@ -0,0 +1,675 @@
Internet Engineering Task Force (IETF) B. Leiba
Request for Comments: 6154 Huawei Technologies
Category: Standards Track J. Nicolson
ISSN: 2070-1721 Google
March 2011
IMAP LIST Extension for Special-Use Mailboxes
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
optional mailbox attributes that a server may include in IMAP LIST
command responses to identify special-use mailboxes to the client,
easing configuration.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6154.
Copyright Notice
Copyright (c) 2011 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
(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.
Leiba & Nicolson Standards Track [Page 1]
RFC 6154 IMAP LIST: Special-Use Mailboxes March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. New Mailbox Attributes Identifying Special-Use Mailboxes . . . 3
3. Extension to IMAP CREATE Command to Set Special-Use
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IMAP METADATA Entry for Special-Use Attributes . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Example of an IMAP LIST Command . . . . . . . . . . . . . 7
5.2. Example of an Extended IMAP LIST Command . . . . . . . . . 7
5.3. Example of an IMAP CREATE Command . . . . . . . . . . . . 8
5.4. Example of Using IMAP METADATA to Manipulate
Special-Use Attributes . . . . . . . . . . . . . . . . . . 8
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. Registration of USEATTR IMAP Response Code . . . . . . . . 10
8.2. Registration of CREATE-SPECIAL-USE IMAP Capability . . . . 10
8.3. Registration of SPECIAL-USE IMAP Capability . . . . . . . 10
8.4. Registration of SPECIAL-USE Selection Option . . . . . . . 10
8.5. Registration of SPECIAL-USE Return Option . . . . . . . . 11
8.6. Registration of SPECIAL-USE Metadata . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Leiba & Nicolson Standards Track [Page 2]
RFC 6154 IMAP LIST: Special-Use Mailboxes March 2011
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
optional mailbox attributes 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].
2. New Mailbox Attributes Identifying Special-Use Mailboxes
An IMAP server that supports this extension MAY include any or all of
the following attributes in responses to the non-extended IMAP LIST
command. The new attributes are included along with existing
attributes, such as "\Marked" and "\Noselect". A given mailbox may
have none, one, or more than one of these attributes. 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. There is no capability string related to the
support of special-use attributes on the non-extended LIST command.
For the extended list command [RFC5258], this extension adds a new
capability string, a new selection option, and a new return option,
all called "SPECIAL-USE". Supporting implementations MUST include
the "SPECIAL-USE" capability string in response to an IMAP CAPABILITY
command. If the client specifies the "SPECIAL-USE" selection option,
the LIST command MUST return only those mailboxes that have a
special-use attribute set. If the client specifies the "SPECIAL-USE"
return option, the LIST command MUST return the new special-use
attributes on those mailboxes that have them set. The "SPECIAL-USE"
Leiba & Nicolson Standards Track [Page 3]
RFC 6154 IMAP LIST: Special-Use Mailboxes March 2011
return option is implied by the "SPECIAL-USE" selection option. The
extended LIST command MAY return SPECIAL-USE attributes even if the
client does not specify the return option.
The new attributes defined here are as follows:
\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.
\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
Leiba & Nicolson Standards Track [Page 4]
RFC 6154 IMAP LIST: Special-Use Mailboxes March 2011
that are marked with the "\Deleted" message flag.
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 of the above attributes are OPTIONAL, and any given server or
message store may support any combination of the attributes, or none
at all. In most cases, there will likely be at most one mailbox with
a given attribute for a given user, but in some server or message
store implementations it might be possible for multiple mailboxes to
have the same special-use attribute.
Special-use attributes are likely to be user-specific. User Adam
might share his \Sent mailbox with user Barb, but that mailbox is
unlikely to also serve as Barb's \Sent mailbox. It's certainly
possible for Adam and Barb to each set the \Sent use on the same
mailbox, but that would be done by specific action (see the sections
below).
3. Extension to IMAP CREATE Command to Set Special-Use Attributes
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 attributes, 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. This might have the effect of moving
the special use from the old mailbox to the new one, or might create
multiple mailboxes with the same special use. Alternatively, servers
MAY refuse the creation, considering the designation to be a
conflict.
Leiba & Nicolson Standards Track [Page 5]
RFC 6154 IMAP LIST: Special-Use Mailboxes March 2011
If the server cannot 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. If the
reason for the failure is related to the special-use attribute (the
specified special use is not supported or cannot be assigned to the
specified mailbox), the server SHOULD include the new "USEATTR"
response code in the tagged response (see Section 5.3 for an
example).
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. Note
that this capability string is different from the "SPECIAL-USE"
string defined above, and a server that supports both functions MUST
advertise both capability strings.
4. IMAP METADATA Entry for Special-Use Attributes
If a server supports this extension and the METADATA extension
[RFC5464], it SHOULD tie the special-use attributes for a mailbox to
its metadata entry "/private/specialuse". The value of /private/
specialuse is either NIL (if there are no special-use attributes for
that mailbox) or a space-separated list of special-use attributes,
presented the same way they would be presented in the LIST command
response.
Such a server MAY allow the setting of special-use attributes through
the METADATA mechanisms, thereby allowing clients to change the
special uses of existing mailboxes. These changes might have side
effects, as the server automatically adjusts the special uses
accordingly, just as it might do with CREATE USE, above. See
Section 5.4 for an example.
A server that supports this MUST check the validity of changes to the
special-use attributes that are done through the metadata in the same
way that it checks validity for the CREATE command and for any
internal mechanisms for setting special uses on mailboxes. It MUST
NOT just blindly accept setting of these metadata by clients, which
might result in the setting of special uses that the implementation
does not support, multiple mailboxes with the same special use, or
other situations that the implementation considers invalid.
Leiba & Nicolson Standards Track [Page 6]
RFC 6154 IMAP LIST: Special-Use Mailboxes March 2011
5. Examples
5.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 attributes 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
5.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 CAPABILITY
S: * CAPABILITY IMAP4rev1 SPECIAL-USE
S: t1 OK done
C: t2 LIST "" "%" RETURN (SPECIAL-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: t2 OK done
Here, the client also includes the "SPECIAL-USE" selection option for
the same list. The "SPECIAL-USE" return option could also have been
specified, but it is unnecessary, as it is implied by the selection
option. Note that in this case, mailboxes that do not have a
special-use attribute are not listed. Also note that we've used the
wildcard "*", rather than "%", to make sure we see all special-use
mailboxes, even ones that might not be at the namespace's root.
C: t3 LIST (SPECIAL-USE) "" "*"
S: * LIST (\Sent) "/" SentMail
S: * LIST (\Marked \Drafts) "/" MyDrafts
S: * LIST (\Trash) "/" Trash
S: t3 OK done
Leiba & Nicolson Standards Track [Page 7]
RFC 6154 IMAP LIST: Special-Use Mailboxes March 2011
5.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
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 [USEATTR] \All not supported
5.4. Example of Using IMAP METADATA to Manipulate Special-Use
Attributes
This example shows how IMAP METADATA can be used to manipulate
special-use attributes, if the operation is supported on the server.
==> Starting point:
C: t1 LIST "" "%" RETURN (SPECIAL-USE)
S: * LIST (\Sent) "/" SentMail
S: * LIST (\Drafts) "/" MyDrafts
S: * LIST () "/" SavedDrafts
S: * LIST (\Trash) "/" Trash
S: t1 OK done
==> Demonstrate the connection:
C: t2 GETMETADATA "MyDrafts" /private/specialuse
S: * METADATA "MyDrafts" (/private/specialuse "\\Drafts")
S: t2 OK done
==> Set new use for SavedDrafts; MyDrafts changes automatically:
C: t3 SETMETADATA "SavedDrafts" (/private/specialuse "\\Drafts")
S: * METADATA "MyDrafts" (/private/specialuse NIL)
S: t3 OK SETMETADATA complete
==> Remove special use for SentMail:
C: t4 SETMETADATA "SentMail" (/private/specialuse NIL)
S: t4 OK SETMETADATA complete
Leiba & Nicolson Standards Track [Page 8]
RFC 6154 IMAP LIST: Special-Use Mailboxes March 2011
==> Check the results:
C: t5 LIST "" "%" RETURN (SPECIAL-USE)
S: * LIST () "/" SentMail
S: * LIST () "/" MyDrafts
S: * LIST (\Drafts) "/" SavedDrafts
S: * LIST (\Trash) "/" Trash
S: t5 OK done
6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [RFC5234].
create-param =/ "USE" SP "(" [use-attr *(SP use-attr)] ")"
; Extends "create-param" from RFC 4466 [RFC4466]
mbx-list-oflag =/ use-attr
; Extends "mbx-list-oflag" from IMAP base [RFC3501]
list-select-independent-opt =/ "SPECIAL-USE"
; Extends "list-select-independent-opt" from
; LIST-extended [RFC5258]
return-option =/ "SPECIAL-USE"
; Extends "return-option" from
; LIST-extended [RFC5258]
resp-text-code =/ "USEATTR"
; Extends "resp-text-code" from
; IMAP [RFC3501]
use-attr = "\All" / "\Archive" / "\Drafts" / "\Flagged" /
"\Junk" / "\Sent" / "\Trash" / use-attr-ext
use-attr-ext = "\" atom
; Reserved for future extensions. Clients
; MUST ignore list attributes they do not understand
; Server implementations MUST NOT generate
; extension attributes except as defined by
; future Standards-Track revisions of or
; extensions to this specification.
7. Security Considerations
LIST response:
Conveying special-use information to a client exposes a small bit of
extra information that could be of value to an attacker. Knowing,
for example, that a particular mailbox (\All) contains pointers to
Leiba & Nicolson Standards Track [Page 9]
RFC 6154 IMAP LIST: Special-Use Mailboxes March 2011
every message the user has might be of particular value. If the IMAP
channel is not protected from passive eavesdropping, this could be an
issue.
CREATE command "USE" parameter and metadata extension: 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. Implementors SHOULD consider the consequences of
allowing a user (or client program) to designate the target of such
automatic action.
Example: If a user is allowed to give the "\Junk" attribute to a
shared mailbox, legitimate mail that's misclassified as junk (false
positives) will be put into that shared mailbox, exposing the user's
private mail to others. The server might warn a user of that
possibility, or might refuse to allow the specification to be made on
a shared mailbox. (Note that this problem exists independent of this
specification, if the server allows a user to share a mailbox that's
already in use for such a function.)
8. IANA Considerations
8.1. Registration of USEATTR IMAP Response Code
This document defines a new IMAP response code, "USEATTR", which IANA
added to the IMAP Response Codes registry.
8.2. Registration of CREATE-SPECIAL-USE IMAP Capability
This document defines a new IMAP capability, "CREATE-SPECIAL-USE",
which IANA added to the IMAP 4 Capabilities registry.
8.3. Registration of SPECIAL-USE IMAP Capability
This document defines a new IMAP capability, "SPECIAL-USE", which
IANA added to the IMAP 4 Capabilities registry.
8.4. Registration of SPECIAL-USE Selection Option
This document defines a new IMAP4 List Extended selection option,
"SPECIAL-USE", which IANA added to the IMAP4 List Extended registry,
as follows:
To: iana@iana.org
Subject: Registration of LIST-EXTENDED selection option SPECIAL-USE
LIST-EXTENDED option name: SPECIAL-USE
LIST-EXTENDED option type: SELECTION
Leiba & Nicolson Standards Track [Page 10]
RFC 6154 IMAP LIST: Special-Use Mailboxes March 2011
Implied return option(s): SPECIAL-USE
LIST-EXTENDED option description: Limit the list to special-use
mailboxes only
Published specification: RFC 6154
Security considerations: none
Intended usage: COMMON
Person and email address to contact for further information: Authors'
Addresses at the end of RFC 6154
Owner/Change controller: iesg@ietf.org
8.5. Registration of SPECIAL-USE Return Option
This document defines a new IMAP4 List Extended return option,
"SPECIAL-USE", which IANA added to the IMAP4 List Extended registry,
as follows:
To: iana@iana.org
Subject: Registration of LIST-EXTENDED return 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: RFC 6154
Security considerations: none
Intended usage: COMMON
Person and email address to contact for further information: Authors'
Addresses at the end of RFC 6154
Owner/Change controller: iesg@ietf.org
8.6. Registration of SPECIAL-USE Metadata
This document defines a new IMAP METADATA entry. IANA added the
following to the IMAP METADATA Mailbox Entry registry:
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Mailbox
Name: /private/specialuse
Description: Defines any special-use features of a mailbox. See the
reference specification for details of its use.
Content-type: text/plain; charset=us-ascii
RFC Number: RFC 6154
Contact: MORG mailing list mailto:morg@ietf.org
Leiba & Nicolson Standards Track [Page 11]
RFC 6154 IMAP LIST: Special-Use Mailboxes March 2011
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
Protocol version 4 - LIST Command Extensions", RFC 5258,
June 2008.
[RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464,
February 2009.
9.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 Standards Track [Page 12]

395
docs/rfcs/rfc6203.IMAP4_Fuzzy_SEARCH_extension.txt Normal file
View File

@ -0,0 +1,395 @@
Internet Engineering Task Force (IETF) T. Sirainen
Request for Comments: 6203 March 2011
Category: Standards Track
ISSN: 2070-1721
IMAP4 Extension for Fuzzy Search
Abstract
This document describes an IMAP protocol extension enabling a server
to perform searches with inexact matching and assigning relevancy
scores for matched messages.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6203.
Copyright Notice
Copyright (c) 2011 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
(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.
Sirainen Standards Track [Page 1]
RFC 6203 IMAP4 FUZZY Search March 2011
1. Introduction
When humans perform searches in IMAP clients, they typically want to
see the most relevant search results first. IMAP servers are able to
do this in the most efficient way when they're free to internally
decide how searches should match messages. This document describes a
new SEARCH=FUZZY extension that provides such functionality.
2. 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 [KEYWORDS].
3. The FUZZY Search Key
The FUZZY search key takes another search key as its argument. The
server is allowed to perform all matching in an implementation-
defined manner for this search key, including ignoring the active
comparator as defined by [RFC5255]. Typically, this would be used to
search for strings. For example:
C: A1 SEARCH FUZZY (SUBJECT "IMAP break")
S: * SEARCH 1 5 10
S: A1 OK Search completed.
Besides matching messages with a subject of "IMAP break", the above
search may also match messages with subjects "broken IMAP", "IMAP is
broken", or anything else the server decides that might be a good
match.
This example does a fuzzy SUBJECT search, but a non-fuzzy FROM
search:
C: A2 SEARCH FUZZY SUBJECT work FROM user@example.com
S: * SEARCH 1 4
S: A2 OK Search completed.
How the server handles multiple separate FUZZY search keys is
implementation-defined.
Fuzzy search algorithms might change, or the results of the
algorithms might be different from search to search, so that fuzzy
searches with the same parameters might give different results for
1) the same user at different times, 2) different users (searches
Sirainen Standards Track [Page 2]
RFC 6203 IMAP4 FUZZY Search March 2011
executed simultaneously), or 3) different users (searches executed at
different times). For example, a fuzzy search might adapt to a
user's search habits in an attempt to give more relevant results (in
a "learning" manner). Such differences can also occur because of
operational decisions, such as load balancing. Clients asking for
"fuzzy" really are requesting search results in a not-necessarily-
deterministic way and need to give the user appropriate warning about
that.
4. Relevancy Scores for Search Results
Servers SHOULD assign a search relevancy score for each matched
message when the FUZZY search key is given. Relevancy scores are
given in the range 1-100, where 100 is the highest relevancy. The
relevancy scores SHOULD use the full 1-100 range, so that clients can
show them to users in a meaningful way, e.g., as a percentage value.
As the name already indicates, relevancy scores specify how relevant
to the search the matched message is. It's not necessarily the same
as how precisely the message matched. For example, a message whose
subject fuzzily matches the search string might get a higher
relevancy score than a message whose body had the exact string in the
middle of a sentence. When multiple search keys are matched fuzzily,
how the relevancy score is calculated is server-dependent.
If the server also advertises the ESEARCH capability as defined by
[ESEARCH], the relevancy scores can be retrieved using the new
RELEVANCY return option for SEARCH:
C: B1 SEARCH RETURN (RELEVANCY ALL) FUZZY TEXT "Helo"
S: * ESEARCH (TAG "B1") ALL 1,5,10 RELEVANCY (4 99 42)
S: B1 OK Search completed.
In the example above, the server would treat "hello", "help", and
other similar strings as fuzzily matching the misspelled "Helo".
The RELEVANCY return option MUST NOT be used unless a FUZZY search
key is also given. Note that SEARCH results aren't sorted by
relevancy; SORT is needed for that.
5. Fuzzy Matching with Non-String Search Keys
Fuzzy matching is not limited to just string matching. All search
keys SHOULD be matched fuzzily, although exactly what that means for
different search keys is left for server implementations to decide --
including deciding that fuzzy matching is meaningless for a
particular key, and falling back to exact matching. Some suggestions
are given below.
Sirainen Standards Track [Page 3]
RFC 6203 IMAP4 FUZZY Search March 2011
Dates:
A typical example could be when a user wants to find a message
"from Dave about a week ago". A client could perform this search
using SEARCH FUZZY (FROM "Dave" SINCE 21-Jan-2009 BEFORE
24-Jan-2009). The server could return messages outside the
specified date range, but the further away the message is, the
lower the relevancy score.
Sizes:
These should be handled similarly to dates. If a user wants to
search for "about 1 MB attachments", the client could do this by
sending SEARCH FUZZY (LARGER 900000 SMALLER 1100000). Again, the
further away the message size is from the specified range, the
lower the relevancy score.
Flags:
If other search criteria match, the server could return messages
that don't have the specified flags set, but with lower relevancy
scores. SEARCH SUBJECT "xyz" FUZZY ANSWERED, for example, might
be useful if the user thinks the message he is looking for has the
ANSWERED flag set, but he isn't sure.
Unique Identifiers (UIDs), sequences, modification sequences: These
are examples of keys for which exact matching probably makes sense.
Alternatively, a server might choose, for instance, to expand a UID
range by 5% on each side.
6. Extensions to SORT and SEARCH
If the server also advertises the SORT capability as defined by
[SORT], the results can be sorted by the new RELEVANCY sort criteria:
C: C1 SORT (RELEVANCY) UTF-8 FUZZY SUBJECT "Helo"
S: * SORT 5 10 1
S: C1 OK Sort completed.
The message with the highest score is returned first. As with the
RELEVANCY return option, RELEVANCY sort criteria MUST NOT be used
unless a FUZZY search key is also given.
If the server also advertises the ESORT capability as defined by
[CONTEXT], the relevancy scores can be retrieved using the new
RELEVANCY return option for SORT:
C: C2 SORT RETURN (RELEVANCY ALL) (RELEVANCY) UTF-8 FUZZY TEXT
"Helo"
S: * ESEARCH (TAG "C2") ALL 5,10,1 RELEVANCY (99 42 4)
S: C2 OK Sort completed.
Sirainen Standards Track [Page 4]
RFC 6203 IMAP4 FUZZY Search March 2011
Furthermore, if the server advertises the CONTEXT=SORT (or
CONTEXT=SEARCH) capability, then the client can limit the number of
returned messages to a SORT (or a SEARCH) by using the PARTIAL return
option. For example, this returns the 10 most relevant messages:
C: C3 SORT RETURN (PARTIAL 1:10) (RELEVANCY) UTF-8 FUZZY TEXT
"World"
S: * ESEARCH (TAG "C3") PARTIAL (1:10 42,9,34,13,15,4,2,7,23,82)
S: C3 OK Sort completed.
7. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [ABNF]. It includes definitions from
[RFC3501], [IMAP-ABNF], and [SORT].
capability =/ "SEARCH=FUZZY"
score = 1*3DIGIT
;; (1 <= n <= 100)
score-list = "(" [score *(SP score)] ")"
search-key =/ "FUZZY" SP search-key
search-return-data =/ "RELEVANCY" SP score-list
;; Conforms to <search-return-data>, from [IMAP-ABNF]
search-return-opt =/ "RELEVANCY"
;; Conforms to <search-return-opt>, from [IMAP-ABNF]
sort-key =/ "RELEVANCY"
8. Security Considerations
Implementation of this extension might enable denial-of-service
attacks against server resources. Servers MAY limit the resources
that a single search (or a single user) may use. Additionally,
implementors should be aware of the following: Fuzzy search engines
are often complex with non-obvious disk space, memory, and/or CPU
usage patterns. Server implementors should at least test the fuzzy-
search behavior with large messages that contain very long words
and/or unique random strings. Also, very long search keys might
cause excessive memory or CPU usage.
Invalid input may also be problematic. For example, if the search
engine takes a UTF-8 stream as input, it might fail more or less
badly when illegal UTF-8 sequences are fed to it from a message whose
Sirainen Standards Track [Page 5]
RFC 6203 IMAP4 FUZZY Search March 2011
character set was claimed to be UTF-8. This could be avoided by
validating all the input and, for example, replacing illegal UTF-8
sequences with the Unicode replacement character (U+FFFD).
Search relevancy rankings might be susceptible to "poisoning" by
smart attackers using certain keywords or hidden markup (e.g., HTML)
in their messages to boost the rankings. This can't be fully
prevented by servers, so clients should prepare for it by at least
allowing users to see all the search results, rather than hiding
results below a certain score.
9. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or
IESG-approved experimental RFC. The "Internet Message Access
Protocol (IMAP) 4 Capabilities Registry" is available from
http://www.iana.org/.
This document defines the SEARCH=FUZZY IMAP capability. IANA has
added it to the registry.
10. Acknowledgements
Alexey Melnikov, Zoltan Ordogh, Barry Leiba, Cyrus Daboo, and Dave
Cridland have helped with this document.
11. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4",
RFC 5267, July 2008.
[ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
Command for Controlling What Kind of Information Is
Returned", RFC 4731, November 2006.
[IMAP-ABNF] Melnikov, A. and C. Daboo, "Collected Extensions to
IMAP4 ABNF", RFC 4466, April 2006.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
Sirainen Standards Track [Page 6]
RFC 6203 IMAP4 FUZZY Search March 2011
[RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
Message Access Protocol Internationalization", RFC 5255,
June 2008.
[SORT] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256,
June 2008.
Author's Address
Timo Sirainen
EMail: tss@iki.fi
Sirainen Standards Track [Page 7]

563
docs/rfcs/rfc6237.IMAP4_Multimailbox_SEARCH_extension.txt Normal file
View File

@ -0,0 +1,563 @@
Internet Engineering Task Force (IETF) B. Leiba
Request for Comments: 6237 Huawei Technologies
Updates: 4466 A. Melnikov
Category: Experimental Isode Limited
ISSN: 2070-1721 May 2011
IMAP4 Multimailbox SEARCH Extension
Abstract
The IMAP4 specification allows the searching of only the selected
mailbox. A user often wants to search multiple mailboxes, and a
client that wishes to support this must issue a series of SELECT and
SEARCH commands, waiting for each to complete before moving on to the
next. This extension allows a client to search multiple mailboxes
with one command, limiting the round trips and waiting for various
searches to complete, and not requiring disruption of the currently
selected mailbox. This extension also uses MAILBOX and TAG fields in
ESEARCH responses, allowing a client to pipeline the searches if it
chooses. This document updates RFC 4466.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6237.
Leiba & Melnikov Experimental [Page 1]
RFC 6237 IMAP4 Multimailbox SEARCH Extension May 2011
Copyright Notice
Copyright (c) 2011 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
(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 ....................................................2
1.1. Conventions Used in This Document ..........................3
2. New ESEARCH Command .............................................3
2.1. The ESEARCH Response .......................................4
2.2. Source Options: Specifying Mailboxes to Search .............5
3. Examples ........................................................6
4. Formal Syntax ...................................................7
5. Security Considerations .........................................8
6. IANA Considerations .............................................9
7. Acknowledgements ................................................9
8. Normative References ............................................9
1. Introduction
The IMAP4 specification allows the searching of only the selected
mailbox. A user often wants to search multiple mailboxes, and a
client that wishes to support this must issue a series of SELECT and
SEARCH commands, waiting for each to complete before moving on to the
next. The commands can't be pipelined, because the server might run
them in parallel, and the untagged SEARCH responses could not then be
distinguished from each other.
This extension allows a client to search multiple mailboxes with one
command, and includes MAILBOX and TAG fields in the ESEARCH response,
yielding the following advantages:
o A single command limits the number of round trips needed to search
a set of mailboxes.
o A single command eliminates the need to wait for one search to
complete before starting the next.
Leiba & Melnikov Experimental [Page 2]
RFC 6237 IMAP4 Multimailbox SEARCH Extension May 2011
o A single command allows the server to optimize the search, if it
can.
o A command that is not dependent upon the selected mailbox
eliminates the need to disrupt the selection state or to open
another IMAP connection.
o The MAILBOX, UIDVALIDITY, and TAG fields in the responses allow a
client to distinguish which responses go with which search (and
which mailbox). A client can safely pipeline these search
commands without danger of confusion. The addition of the MAILBOX
and UIDVALIDITY fields updates the search-correlator item defined
in [RFC4466].
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].
2. New ESEARCH Command
Arguments: OPTIONAL source options
OPTIONAL result options
OPTIONAL charset specification (see [RFC2978])
searching criteria (one or more)
Responses: REQUIRED untagged response: ESEARCH
Result: OK -- search completed
NO -- error: cannot search that charset or criteria
BAD -- command unknown or arguments invalid
This section defines a new ESEARCH command, which works similarly to
the UID SEARCH command described in Section 2.6.1 of [RFC4466]
(initially described in Section 6.4.4 of [RFC3501] and extended by
[RFC4731]).
The ESEARCH command further extends searching by allowing for
optional source and result options. This document does not define
any new result options (see Section 3.1 of [RFC4731]). A server that
supports this extension includes "MULTISEARCH" in its IMAP capability
string.
Leiba & Melnikov Experimental [Page 3]
RFC 6237 IMAP4 Multimailbox SEARCH Extension May 2011
Because there has been confusion about this, it is worth pointing out
that with ESEARCH, as with *any* SEARCH or UID SEARCH command, it
MUST NOT be considered an error if the search terms include a range
of message numbers that extends (or, in fact, starts) beyond the end
of the mailbox. For example, a client might want to establish a
rolling window through the search results this way:
C: tag1 UID ESEARCH FROM "frobozz" 1:100
...followed later by this:
C: tag1 UID ESEARCH FROM "frobozz" 101:200
...and so on. This tells the server to match only the first hundred
messages in the mailbox the first time, the second hundred the second
time, etc. In fact, it might likely allow the server to optimize the
search significantly. In the above example, whether the mailbox
contains 50 or 150 or 250 messages, neither of the search commands
shown will result in an error. It is up to the client to know when
to stop moving its search window.
2.1. The ESEARCH Response
In response to an ESEARCH command, the server MUST return ESEARCH
responses [RFC4731] (that is, not SEARCH responses). Because message
numbers are not useful for mailboxes that are not selected, the
responses MUST contain information about UIDs, not message numbers.
This is true even if the source options specify that only the
selected mailbox be searched.
Presence of a source option in the absence of a result option implies
the "ALL" result option (see Section 3.1 of [RFC4731]). Note that
this is not the same as the result from the SEARCH command described
in the IMAP base protocol [RFC3501].
Source options describe which mailboxes must be searched for
messages. An ESEARCH command with source options does not affect
which mailbox, if any, is currently selected, regardless of which
mailboxes are searched.
For each mailbox satisfying the source options, a single ESEARCH
response MUST be returned if any messages in that mailbox match the
search criteria. An ESEARCH response MUST NOT be returned for
mailboxes that contain no matching messages. This is true even when
result options such as MIN, MAX, and COUNT are specified (see
Section 3.1 of [RFC4731]), and the values returned (lowest UID
matched, highest UID matched, and number of messages matched,
respectively) apply to the mailbox reported in that ESEARCH response.
Leiba & Melnikov Experimental [Page 4]
RFC 6237 IMAP4 Multimailbox SEARCH Extension May 2011
Note that it is possible for an ESEARCH command to return *no*
untagged responses (no ESEARCH responses at all), in the case that
there are no matches to the search in any of the mailboxes that
satisfy the source options. Clients can detect this situation by
finding the tagged OK response without having received any matching
untagged ESEARCH responses.
Each ESEARCH response MUST contain the MAILBOX, TAG, and UIDVALIDITY
correlators. Correlators allow clients to issue several ESEARCH
commands at once (pipelined). If the SEARCHRES [RFC5182] extension
is used in an ESEARCH command, that ESEARCH command MUST be executed
by the server after all previous SEARCH/ESEARCH commands have
completed and before any subsequent SEARCH/ESEARCH commands are
executed. The server MAY perform consecutive ESEARCH commands in
parallel as long as none of them use the SEARCHRES extension.
2.2. Source Options: Specifying Mailboxes to Search
The source options, if present, MUST contain a mailbox specifier as
defined in the IMAP NOTIFY extension [RFC5465], Section 6 (using the
"filter-mailboxes" ABNF item), with the following differences:
1. The "selected-delayed" specifier is not valid here.
2. A "subtree-one" specifier is added. The "subtree" specifier
results in a search of the specified mailbox and all selectable
mailboxes that are subordinate to it, through an indefinitely
deep hierarchy. The "subtree-one" specifier results in a search
of the specified mailbox and all selectable child mailboxes, one
hierarchy level down.
If "subtree" is specified, the server MUST defend against loops in
the hierarchy (for example, those caused by recursive file-system
links within the message store). The server SHOULD do this by
keeping track of the mailboxes that have been searched, and
terminating the hierarchy traversal when a repeat is found. If it
cannot do that, it MAY do it by limiting the hierarchy depth.
If the source options are not present, the value "selected" is
assumed -- that is, only the currently selected mailbox is searched.
The "personal" source option is a particularly convenient way to
search all of the current user's mailboxes. Note that there is no
way to use wildcard characters to search all mailboxes; the
"mailboxes" source option does not do wildcard expansion.
Leiba & Melnikov Experimental [Page 5]
RFC 6237 IMAP4 Multimailbox SEARCH Extension May 2011
If the source options include (or default to) "selected", the IMAP
session MUST be in "selected" state. If the source options specify
other mailboxes and NOT "selected", then the IMAP session MUST be in
either "selected" or "authenticated" state. If the session is not in
a correct state, the ESEARCH command MUST return a "BAD" result.
If the server supports the SEARCHRES [RFC5182] extension, then the
"SAVE" result option is valid *only* if "selected" is specified or
defaulted as the sole mailbox to be searched. If any source option
other than "selected" is specified, the ESEARCH command MUST return a
"BAD" result.
If the server supports the CONTEXT=SEARCH and/or CONTEXT=SORT
extension [RFC5267], then the following additional rules apply:
o The CONTEXT return option (Section 4.2 of [RFC5267]) can be used
with an ESEARCH command.
o If the UPDATE return option is used (Section 4.3 of [RFC5267]), it
MUST apply ONLY to the currently selected mailbox. If UPDATE is
used and there is no mailbox currently selected, the ESEARCH
command MUST return a "BAD" result.
o The PARTIAL search return option (Section 4.4 of [RFC5267]) can be
used and applies to each mailbox searched by the ESEARCH command.
If the server supports the Access Control List (ACL) [RFC4314]
extension, then the logged-in user is required to have the "r" right
for each mailbox she wants to search. In addition, any mailboxes
that are not explicitly named (accessed through "personal" or
"subtree", for example) are required to have the "l" right.
Mailboxes matching the source options for which the logged-in user
lacks sufficient rights MUST be ignored by the ESEARCH command
processing. In particular, ESEARCH responses MUST NOT be returned
for those mailboxes.
3. Examples
In the following example, note that two ESEARCH commands are
pipelined, and that the server is running them in parallel,
interleaving a response to the second search amid the responses to
the first (watch the tags).
C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen
C: tag2 ESEARCH IN (mailboxes "folder1" subtree-one "folder2")
subject "chad"
S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL
4001,4003,4005,4007,4009
Leiba & Melnikov Experimental [Page 6]
RFC 6237 IMAP4 Multimailbox SEARCH Extension May 2011
S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 1) UID ALL
3001:3004,3788
S: * ESEARCH (TAG "tag1" MAILBOX "folder2/banana" UIDVALIDITY 503)
UID ALL 3002,4004
S: * ESEARCH (TAG "tag1" MAILBOX "folder2/peach" UIDVALIDITY 3) UID
ALL 921691
S: tag1 OK done
S: * ESEARCH (TAG "tag2" MAILBOX "folder2/salmon" UIDVALIDITY
1111111) UID ALL 50003,50006,50009,50012
S: tag2 OK done
4. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in [RFC5234]. Terms not defined here are
taken from [RFC3501], [RFC5465], or [RFC4466].
command-auth =/ esearch
; Update definition from IMAP base [RFC3501].
; Add new "esearch" command.
command-select =/ esearch
; Update definition from IMAP base [RFC3501].
; Add new "esearch" command.
filter-mailboxes-other =/ ("subtree-one" SP one-or-more-mailbox)
; Update definition from IMAP Notify [RFC5465].
; Add new "subtree-one" selector.
filter-mailboxes-selected = "selected"
; Update definition from IMAP Notify [RFC5465].
; We forbid the use of "selected-delayed".
one-correlator = ("TAG" SP tag-string) / ("MAILBOX" SP astring) /
("UIDVALIDITY" SP nz-number)
; Each correlator MUST appear exactly once.
scope-option = scope-option-name [SP scope-option-value]
; No options defined here. Syntax for future extensions.
scope-option-name = tagged-ext-label
; No options defined here. Syntax for future extensions.
scope-option-value = tagged-ext-val
; No options defined here. Syntax for future extensions.
Leiba & Melnikov Experimental [Page 7]
RFC 6237 IMAP4 Multimailbox SEARCH Extension May 2011
scope-options = scope-option *(SP scope-option)
; A given option may only appear once.
; No options defined here. Syntax for future extensions.
esearch = "ESEARCH" [SP esearch-source-opts]
[SP search-return-opts] SP search-program
search-correlator = SP "(" one-correlator *(SP one-correlator) ")"
; Updates definition in IMAP4 ABNF [RFC4466].
esearch-source-opts = "IN" SP "(" source-mbox [SP
"(" scope-options ")"] ")"
source-mbox = filter-mailboxes *(SP filter-mailboxes)
; "filter-mailboxes" is defined in IMAP Notify [RFC5465].
; See updated definition of filter-mailboxes-other, above.
; See updated definition of filter-mailboxes-selected, above.
5. Security Considerations
This new IMAP ESEARCH command allows a single command to search many
mailboxes at once. On the one hand, a client could do that by
sending many IMAP SEARCH commands. On the other hand, this makes it
easier for a client to overwork a server, by sending a single command
that results in an expensive search of tens of thousands of
mailboxes. Server implementations need to be aware of that, and
provide mechanisms that prevent a client from adversely affecting
other users. Limitations on the number of mailboxes that may be
searched in one command, and/or on the server resources that will be
devoted to responding to a single client, are reasonable limitations
for an implementation to impose.
Implementations MUST, of course, apply access controls appropriately,
limiting a user's access to ESEARCH in the same way its access is
limited for any other IMAP commands. This extension has no data-
access risks beyond what may be there in the unextended IMAP
implementation.
Mailboxes matching the source options for which the logged-in user
lacks sufficient rights MUST be ignored by the ESEARCH command
processing (see the paragraph about this in Section 2.2). In
particular, any attempt to distinguish insufficient access from
non-existent mailboxes may expose information about the mailbox
hierarchy that isn't otherwise available to the client.
If "subtree" is specified, the server MUST defend against loops in
the hierarchy (see the paragraph about this in Section 2.2).
Leiba & Melnikov Experimental [Page 8]
RFC 6237 IMAP4 Multimailbox SEARCH Extension May 2011
6. IANA Considerations
IMAP4 capabilities are registered by publishing a Standards Track or
IESG-approved Experimental RFC. The "IMAP 4 Capabilities" registry
is currently located here:
http://www.iana.org/
This document defines the IMAP capability "MULTISEARCH", and IANA has
added it to the registry.
7. Acknowledgements
The authors gratefully acknowledge feedback provided by Timo
Sirainen, Peter Coates, and Arnt Gulbrandsen.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006.
[RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
Command for Controlling What Kind of Information Is
Returned", RFC 4731, November 2006.
[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last
SEARCH Result", RFC 5182, March 2008.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
July 2008.
Leiba & Melnikov Experimental [Page 9]
RFC 6237 IMAP4 Multimailbox SEARCH Extension May 2011
[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
NOTIFY Extension", RFC 5465, February 2009.
Authors' Addresses
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
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/
Leiba & Melnikov Experimental [Page 10]

339
docs/rfcs/rfc6331.Moving_Digest-MD5_to_Historic Normal file
View File

@ -0,0 +1,339 @@
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 6331 Isode Limited
Obsoletes: 2831 July 2011
Category: Informational
ISSN: 2070-1721
Moving DIGEST-MD5 to Historic
Abstract
This memo describes problems with the DIGEST-MD5 Simple
Authentication and Security Layer (SASL) mechanism as specified in
RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of
SASL mechanisms and moves RFC 2831 to Historic status.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6331.
Copyright Notice
Copyright (c) 2011 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
(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.
Melnikov Informational [Page 1]
RFC 6331 Moving DIGEST-MD5 to Historic July 2011
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
2. Security Considerations . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . . . 5
1. Introduction and Overview
[RFC2831] defines how HTTP Digest Authentication [RFC2617] can be
used as a Simple Authentication and Security Layer (SASL) [RFC4422]
mechanism for any protocol that has a SASL profile. It was intended
both as an improvement over CRAM-MD5 [RFC2195] and as a convenient
way to support a single authentication mechanism for web, email, the
Lightweight Directory Access Protocol (LDAP), and other protocols.
While it can be argued that it is an improvement over CRAM-MD5, many
implementors commented that the additional complexity of DIGEST-MD5
makes it difficult to implement fully and securely.
Below is an incomplete list of problems with the DIGEST-MD5 mechanism
as specified in [RFC2831]:
1. The mechanism has too many options and modes. Some of them are
not well described and are not widely implemented. For example,
DIGEST-MD5 allows the "qop" directive to contain multiple values,
but it also allows for multiple qop directives to be specified.
The handling of multiple options is not specified, which results
in minor interoperability problems. Some implementations
amalgamate multiple qop values into one, while others treat
multiple qops as an error. Another example is the use of an
empty authorization identity. In SASL, an empty authorization
identity means that the client is willing to authorize as the
authentication identity. The document is not clear on whether
Melnikov Informational [Page 2]
RFC 6331 Moving DIGEST-MD5 to Historic July 2011
the authzid must be omitted or if it can be specified with an
empty value to convey this. The requirement for backward
compatibility with HTTP Digest means that the situation is even
worse. For example, DIGEST-MD5 requires all usernames/passwords
that can be entirely represented in the ISO-8859-1 charset to be
down converted from UTF-8 [RFC3629] to ISO-8859-1 [ISO-8859-1].
Another example is the use of quoted strings. Handling of
characters that need escaping is not properly described, and the
DIGEST-MD5 document has no examples to demonstrate correct
behavior.
2. The DIGEST-MD5 document uses ABNF from RFC 822 [RFC0822], which
allows an extra construct and allows for "implied folding
whitespace" to be inserted in many places. The difference from a
more common ABNF defined in [RFC5234] is confusing for some
implementors. As a result, many implementations do not accept
folding whitespace in many places where it is allowed.
3. The DIGEST-MD5 document uses the concept of a "realm" to define a
collection of accounts. A DIGEST-MD5 server can support one or
more realms. The DIGEST-MD5 document does not provide any
guidance on how realms should be named and, more importantly, how
they can be entered in User Interfaces (UIs). As a result, many
DIGEST-MD5 clients have confusing UIs, do not allow users to
enter a realm, and/or do not allow users to pick one of the
server-supported realms.
4. Use of username in the inner hash is problematic. The inner hash
of DIGEST-MD5 is an MD5 hash of colon-separated username, realm,
and password. Implementations may choose to store inner hashes
instead of clear text passwords. This has some useful
properties, such as protection from compromise of authentication
databases containing the same username and password on other
servers if a server with the username and password is
compromised; however, this is rarely done in practice. First,
the inner hash is not compatible with widely deployed Unix
password databases, and second, changing the username would
invalidate the inner hash.
5. Description of DES/3DES [DES] and RC4 security layers are
inadequate to produce independently developed interoperable
implementations. In the DES/3DES case, this is partly a problem
with existing DES APIs.
6. DIGEST-MD5 outer hash (the value of the "response" directive)
does not protect the whole authentication exchange, which makes
the mechanism vulnerable to "man-in-the-middle" (MITM) attacks,
such as modification of the list of supported qops or ciphers.
Melnikov Informational [Page 3]
RFC 6331 Moving DIGEST-MD5 to Historic July 2011
7. The following features are missing from DIGEST-MD5, making it
insecure or unsuitable for use in protocols:
A. Channel bindings [RFC5056].
B. Hash agility (i.e., no easy way to replace the MD5 hash
function with another one).
C. Support for SASLPrep [RFC4013] or any other type of Unicode
character normalization of usernames and passwords. The
original DIGEST-MD5 document predates SASLPrep and does not
recommend any Unicode character normalization.
8. The cryptographic primitives in DIGEST-MD5 are not up to today's
standards, in particular:
A. The MD5 hash is sufficiently weak to make a brute force
attack on DIGEST-MD5 easy with common hardware [RFC6151].
B. The RC4 algorithm is prone to attack when used as the
security layer without discarding the initial key stream
output [RFC6229].
C. The DES cipher for the security layer is considered insecure
due to its small key space [RFC3766].
Note that most of the problems listed above are already present in
the HTTP Digest authentication mechanism.
Because DIGEST-MD5 is defined as an extensible mechanism, it is
possible to fix most of the problems listed above. However, this
would increase implementation complexity of an already complex
mechanism even further, so the effort is not worth the cost. In
addition, an implementation of a "fixed" DIGEST-MD5 specification
would likely either not interoperate with any existing implementation
of [RFC2831] or would be vulnerable to various downgrade attacks.
Note that despite DIGEST-MD5 seeing some deployment on the Internet,
this specification recommends obsoleting DIGEST-MD5 because DIGEST-
MD5, as implemented, is not a reasonable candidate for further
standardization and should be deprecated in favor of one or more new
password-based mechanisms currently being designed.
The Salted Challenge Response Authentication Mechanism (SCRAM) family
of SASL mechanisms [RFC5802] has been developed to provide similar
features as DIGEST-MD5 but with a better design.
Melnikov Informational [Page 4]
RFC 6331 Moving DIGEST-MD5 to Historic July 2011
2. Security Considerations
Security issues are discussed throughout this document.
3. IANA Considerations
IANA has changed the "Intended usage" of the DIGEST-MD5 mechanism
registration in the SASL mechanism registry to OBSOLETE. The SASL
mechanism registry is specified in [RFC4422] and is currently
available at:
http://www.iana.org/assignments/sasl-mechanisms
4. Acknowledgements
The author gratefully acknowledges the feedback provided by Chris
Newman, Simon Josefsson, Kurt Zeilenga, Sean Turner, and Abhijit
Menon-Sen. Various text was copied from other RFCs, in particular,
from [RFC2831].
5. References
5.1. Normative References
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication
as a SASL Mechanism", RFC 2831, May 2000.
5.2. Informative References
[DES] National Institute of Standards and Technology, "Data
Encryption Standard (DES)", FIPS PUB 46-3,
October 1999.
[ISO-8859-1] International Organization for Standardization,
"Information technology - 8-bit single-byte coded
graphic character sets - Part 1: Latin alphabet No. 1",
ISO/IEC 8859-1, 1998.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
Melnikov Informational [Page 5]
RFC 6331 Moving DIGEST-MD5 to Historic July 2011
[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response",
RFC 2195, September 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys",
BCP 86, RFC 3766, April 2004.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication
and Security Layer (SASL)", RFC 4422, June 2006.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N.
Williams, "Salted Challenge Response Authentication
Mechanism (SCRAM) SASL and GSS-API Mechanisms",
RFC 5802, July 2010.
[RFC6151] Turner, S. and L. Chen, "Updated Security
Considerations for the MD5 Message-Digest and the HMAC-
MD5 Algorithms", RFC 6151, March 2011.
[RFC6229] Strombergson, J. and S. Josefsson, "Test Vectors for
the Stream Cipher RC4", RFC 6229, May 2011.
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/
Melnikov Informational [Page 6]