rfcs: update RFCs and provide better filenames
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
This commit is contained in:
parent
5ecd557dfb
commit
2377353cae
|
@ -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,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'> </span></td></tr> <tr><td>Draft:</td> <td><span class='cplate bgred'> </span></td></tr> <tr><td>Informational:</td> <td><span class='cplate bgorange'> </span></td></tr> <tr><td>Experimental:</td> <td><span class='cplate bgyellow'> </span></td></tr> <tr><td>Best Common Practice:</td> <td><span class='cplate bgmagenta'> </span></td></tr> <tr><td>Proposed Standard:</td> <td><span class='cplate bgblue'> </span></td></tr> <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'> </span></td></tr> <tr><td>Internet Standard:</td> <td><span class='cplate bggreen'> </span></td></tr> <tr><td>Historic:</td> <td><span class='cplate bggrey'> </span></td></tr> <tr><td>Obsolete:</td> <td><span class='cplate bgbrown'> </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&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=""IMAP4 Authentication Mechanisms"">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 ::= <any CHAR except atom_specials>
|
||||
|
||||
atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" /
|
||||
<"> / "\"
|
||||
|
||||
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 ::= <any 7-bit US-ASCII character except NUL,
|
||||
0x01 - 0x7f>
|
||||
|
||||
continue_req ::= "+" SPACE base64 CRLF
|
||||
|
||||
CR ::= <ASCII CR, carriage return, 0x0C>
|
||||
|
||||
CRLF ::= CR LF
|
||||
|
||||
CTL ::= <any ASCII control character and DEL,
|
||||
0x00 - 0x1f, 0x7f>
|
||||
|
||||
|
||||
|
||||
|
||||
<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 ::= <ASCII LF, line feed, 0x0A>
|
||||
|
||||
SPACE ::= <ASCII SP, space, 0x20>
|
||||
|
||||
TAB ::= <ASCII HT, tab, 0x09>
|
||||
|
||||
|
||||
|
||||
<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>
|
File diff suppressed because it is too large
Load Diff
|
@ -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]
|
||||
|
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
@ -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]
|
||||
|
|
@ -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]
|
||||
|
|
@ -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]
|
||||
|
|
@ -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]
|
||||
|
File diff suppressed because it is too large
Load Diff
|
@ -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]
|
||||
|
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
@ -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]
|
||||
|
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
@ -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]
|
||||
|
|
@ -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]
|
||||
|
|
@ -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]
|
||||
|
|
@ -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]
|
||||
|
|
@ -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]
|
||||
|
|
@ -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]
|
||||
|
|
@ -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]
|
||||
|
|
@ -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]
|
||||
|
|
@ -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]
|
||||
|
Loading…
Reference in New Issue