|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
|
|
<!-- saved from url=(0041)http://www.apps.ietf.org/rfc/rfc3501.html -->
|
|
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>RFC 3501</title></head>
|
|
<body>
|
|
<table width="100%"><tbody><tr><td align="left" valign="top">
|
|
Network Working Group<br>
|
|
Request for Comments: 3501<br>
|
|
Obsoletes: <a href="http://www.apps.ietf.org/rfc/rfc2060.html">2060</a><br>
|
|
Category: Standards Track<br>
|
|
</td><td align="right" valign="top">
|
|
M. Crispin<br>
|
|
University of Washington<br>
|
|
March 2003<br>
|
|
</td></tr></tbody></table>
|
|
<em><a name="page-1">Page 1</a></em><p>
|
|
</p><h3 align="center">INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</h3>
|
|
<p>
|
|
</p><dl><dt>Status of this Memo</dt><dd>
|
|
<p>
|
|
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" (<a href="http://www.apps.ietf.org/rfc/stdlist.html#s1">STD 1</a>) for the standardization state
|
|
and status of this protocol. Distribution of this memo is unlimited.
|
|
</p><p>
|
|
</p></dd><dt>Copyright Notice</dt><dd>
|
|
<p>
|
|
Copyright © The Internet Society (2003). All Rights Reserved.
|
|
</p><p>
|
|
</p></dd><dt>Abstract</dt><dd>
|
|
<p>
|
|
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
|
|
allows a client to access and manipulate electronic mail messages on
|
|
a server. IMAP4rev1 permits manipulation of mailboxes (remote
|
|
message folders) in a way that is functionally equivalent to local
|
|
folders. IMAP4rev1 also provides the capability for an offline
|
|
client to resynchronize with the server.
|
|
</p><p>
|
|
IMAP4rev1 includes operations for creating, deleting, and renaming
|
|
mailboxes, checking for new messages, permanently removing messages,
|
|
setting and clearing flags, <a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC 2822</a> and <a href="http://www.apps.ietf.org/rfc/rfc2045.html">RFC 2045</a> parsing, searching,
|
|
and selective fetching of message attributes, texts, and portions
|
|
thereof. Messages in IMAP4rev1 are accessed by the use of numbers.
|
|
These numbers are either message sequence numbers or unique
|
|
identifiers.
|
|
</p><p>
|
|
IMAP4rev1 supports a single server. A mechanism for accessing
|
|
configuration information to support multiple IMAP4rev1 servers is
|
|
discussed in <a href="http://www.apps.ietf.org/rfc/rfc2244.html">RFC 2244</a>.
|
|
</p><p>
|
|
IMAP4rev1 does not specify a means of posting mail; this function is
|
|
handled by a mail transfer protocol such as <a href="http://www.apps.ietf.org/rfc/rfc2821.html">RFC 2821</a>.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-2">Page 2</a></em></dt><dd><p>
|
|
</p></dd><dt>Table of Contents</dt><dd>
|
|
<p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-4">
|
|
IMAP4rev1 Protocol Specification
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-1">
|
|
1. How to Read This Document
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-1.1">
|
|
1.1. Organization of This Document
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-1.2">
|
|
1.2. Conventions Used in This Document
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-1.3">
|
|
1.3. Special Notes to Implementors
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2">
|
|
2. Protocol Overview
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.1">
|
|
2.1. Link Level
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.2">
|
|
2.2. Commands and Responses
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.2.1">
|
|
2.2.1. Client Protocol Sender and Server Protocol Receiver
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.2.2">
|
|
2.2.2. Server Protocol Sender and Client Protocol Receiver
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3">
|
|
2.3. Message Attributes
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.1">
|
|
2.3.1. Message Numbers
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.1.1">
|
|
2.3.1.1. Unique Identifier (UID) Message Attribute
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.1.2">
|
|
2.3.1.2. Message Sequence Number Message Attribute
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.2">
|
|
2.3.2. Flags Message Attribute
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.3">
|
|
2.3.3. Internal Date Message Attribute
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.4">
|
|
2.3.4. [RFC-2822] Size Message Attribute
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.5">
|
|
2.3.5. Envelope Structure Message Attribute
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.6">
|
|
2.3.6. Body Structure Message Attribute
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.4">
|
|
2.4. Message Texts
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-3">
|
|
3. State and Flow Diagram
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-3.1">
|
|
3.1. Not Authenticated State
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-3.2">
|
|
3.2. Authenticated State
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-3.3">
|
|
3.3. Selected State
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-3.4">
|
|
3.4. Logout State
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-4">
|
|
4. Data Formats
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-4.1">
|
|
4.1. Atom
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-4.2">
|
|
4.2. Number
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-4.3">
|
|
4.3. String
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-4.3.1">
|
|
4.3.1. 8-bit and Binary Strings
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-4.4">
|
|
4.4. Parenthesized List
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-4.5">
|
|
4.5. NIL
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-5">
|
|
5. Operational Considerations
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-5.1">
|
|
5.1. Mailbox Naming
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-5.1.1">
|
|
5.1.1. Mailbox Hierarchy Naming
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-5.1.2">
|
|
5.1.2. Mailbox Namespace Naming Convention
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-5.1.3">
|
|
5.1.3. Mailbox International Naming Convention
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-5.2">
|
|
5.2. Mailbox Size and Message Status Updates
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-5.3">
|
|
5.3. Response when no Command in Progress
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-5.4">
|
|
5.4. Autologout Timer
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-5.5">
|
|
5.5. Multiple Commands in Progress
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6">
|
|
6. Client Commands
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.1">
|
|
6.1. Client Commands - Any State
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.1.1">
|
|
6.1.1. CAPABILITY Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.1.2">
|
|
6.1.2. NOOP Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.1.3">
|
|
6.1.3. LOGOUT Command
|
|
</a>
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-3">Page 3</a></em></dt><dd><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.2">
|
|
6.2. Client Commands - Not Authenticated State
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.2.1">
|
|
6.2.1. STARTTLS Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.2.2">
|
|
6.2.2. AUTHENTICATE Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.2.3">
|
|
6.2.3. LOGIN Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3">
|
|
6.3. Client Commands - Authenticated State
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3.1">
|
|
6.3.1. SELECT Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3.2">
|
|
6.3.2. EXAMINE Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3.3">
|
|
6.3.3. CREATE Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3.4">
|
|
6.3.4. DELETE Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3.5">
|
|
6.3.5. RENAME Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3.6">
|
|
6.3.6. SUBSCRIBE Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3.7">
|
|
6.3.7. UNSUBSCRIBE Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3.8">
|
|
6.3.8. LIST Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3.9">
|
|
6.3.9. LSUB Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3.10">
|
|
6.3.10. STATUS Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.3.11">
|
|
6.3.11. APPEND Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.4">
|
|
6.4. Client Commands - Selected State
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.4.1">
|
|
6.4.1. CHECK Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.4.2">
|
|
6.4.2. CLOSE Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.4.3">
|
|
6.4.3. EXPUNGE Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.4.4">
|
|
6.4.4. SEARCH Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.4.5">
|
|
6.4.5. FETCH Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.4.6">
|
|
6.4.6. STORE Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.4.7">
|
|
6.4.7. COPY Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.4.8">
|
|
6.4.8. UID Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.5">
|
|
6.5. Client Commands - Experimental/Expansion
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.5.1">
|
|
6.5.1. X<atom> Command
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7">
|
|
7. Server Responses
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.1">
|
|
7.1. Server Responses - Status Responses
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.1.1">
|
|
7.1.1. OK Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.1.2">
|
|
7.1.2. NO Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.1.3">
|
|
7.1.3. BAD Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.1.4">
|
|
7.1.4. PREAUTH Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.1.5">
|
|
7.1.5. BYE Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.2">
|
|
7.2. Server Responses - Server and Mailbox Status
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.2.1">
|
|
7.2.1. CAPABILITY Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.2.2">
|
|
7.2.2. LIST Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.2.3">
|
|
7.2.3. LSUB Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.2.4">
|
|
7.2.4 STATUS Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.2.5">
|
|
7.2.5. SEARCH Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.2.6">
|
|
7.2.6. FLAGS Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.3">
|
|
7.3. Server Responses - Mailbox Size
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.3.1">
|
|
7.3.1. EXISTS Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.3.2">
|
|
7.3.2. RECENT Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.4">
|
|
7.4. Server Responses - Message Status
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.4.1">
|
|
7.4.1. EXPUNGE Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.4.2">
|
|
7.4.2. FETCH Response
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.5">
|
|
7.5. Server Responses - Command Continuation Request
|
|
</a><br>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-4">Page 4</a></em></dt><dd><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-8">
|
|
8. Sample IMAP4rev1 connection
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-9">
|
|
9. Formal Syntax
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-10">
|
|
10. Author's Note
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-11">
|
|
11. Security Considerations
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-11.1">
|
|
11.1. STARTTLS Security Considerations
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-11.2">
|
|
11.2. Other Security Considerations
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-12">
|
|
12. IANA Considerations
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-95">
|
|
Appendices
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-A">
|
|
A. References
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-B">
|
|
B. Changes from RFC 2060
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-C">
|
|
C. Key Word Index
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-107">
|
|
Author's Address
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-108">
|
|
Full Copyright Statement
|
|
</a><br>
|
|
</p></dd><dt>IMAP4rev1 Protocol Specification</dt><dd>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-1">1</a> How to Read This Document</strong></dt><dd>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-1.1">1.1</a> Organization of This Document</strong></dt><dd>
|
|
<p>
|
|
This document is written from the point of view of the implementor of
|
|
an IMAP4rev1 client or server. Beyond the protocol overview in
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2">section 2</a>, it is not optimized for someone trying to understand the
|
|
operation of the protocol. The material in sections 3 through 5
|
|
provides the general context and definitions with which IMAP4rev1
|
|
operates.
|
|
</p><p>
|
|
Sections 6, 7, and 9 describe the IMAP commands, responses, and
|
|
syntax, respectively. The relationships among these are such that it
|
|
is almost impossible to understand any of them separately. In
|
|
particular, do not attempt to deduce command syntax from the command
|
|
section alone; instead refer to the Formal Syntax section.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-1.2">1.2</a> Conventions Used in This Document</strong></dt><dd>
|
|
<p>
|
|
"Conventions" are basic principles or procedures. Document
|
|
conventions are noted in this section.
|
|
</p><p>
|
|
In examples, "C:" and "S:" indicate lines sent by the client and
|
|
server respectively.
|
|
</p><p>
|
|
The key words "<strong>MUST</strong>", "<strong>MUST NOT</strong>", "<strong>REQUIRED</strong>", "<strong>SHALL</strong>", "<strong>SHALL NOT</strong>",
|
|
"<strong>SHOULD</strong>", "<strong>SHOULD NOT</strong>", "<strong>MAY</strong>", and "<strong>OPTIONAL</strong>" in this document are to
|
|
be interpreted as described in [KEYWORDS].
|
|
</p><p>
|
|
The word "can" (not "may") is used to refer to a possible
|
|
circumstance or situation, as opposed to an optional facility of the
|
|
protocol.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-5">Page 5</a></em></dt><dd><p>
|
|
"User" is used to refer to a human user, whereas "client" refers to
|
|
the software being run by the user.
|
|
</p><p>
|
|
"Connection" refers to the entire sequence of client/server
|
|
interaction from the initial establishment of the network connection
|
|
until its termination.
|
|
</p><p>
|
|
"Session" refers to the sequence of client/server interaction from
|
|
the time that a mailbox is selected (SELECT or EXAMINE command) until
|
|
the time that selection ends (SELECT or EXAMINE of another mailbox,
|
|
CLOSE command, or connection termination).
|
|
</p><p>
|
|
Characters are 7-bit US-ASCII unless otherwise specified. Other
|
|
character sets are indicated using a "CHARSET", as described in
|
|
[MIME-IMT] and defined in [CHARSET]. CHARSETs have important
|
|
additional semantics in addition to defining character set; refer to
|
|
these documents for more detail.
|
|
</p><p>
|
|
There are several protocol conventions in IMAP. These refer to
|
|
aspects of the specification which are not strictly part of the IMAP
|
|
protocol, but reflect generally-accepted practice. Implementations
|
|
need to be aware of these conventions, and avoid conflicts whether or
|
|
not they implement the convention. For example, "&" may not be used
|
|
as a hierarchy delimiter since it conflicts with the Mailbox
|
|
International Naming Convention, and other uses of "&" in mailbox
|
|
names are impacted as well.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-1.3">1.3</a> Special Notes to Implementors</strong></dt><dd>
|
|
<p>
|
|
Implementors of the IMAP protocol are strongly encouraged to read the
|
|
IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
|
|
conjunction with this document, to help understand the intricacies of
|
|
this protocol and how best to build an interoperable product.
|
|
</p><p>
|
|
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
|
|
unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible with
|
|
the IMAP4 protocol described in <a href="http://www.apps.ietf.org/rfc/rfc1730.html">RFC 1730</a>; the exception being in
|
|
certain facilities added in <a href="http://www.apps.ietf.org/rfc/rfc1730.html">RFC 1730</a> that proved problematic and were
|
|
subsequently removed. In the course of the evolution of IMAP4rev1,
|
|
some aspects in the earlier protocols have become obsolete. Obsolete
|
|
commands, responses, and data formats which an IMAP4rev1
|
|
<br>
|
|
implementation can encounter when used with an earlier implementation
|
|
are described in [IMAP-OBSOLETE].
|
|
</p><p>
|
|
Other compatibility issues with IMAP2bis, the most common variant of
|
|
the earlier protocol, are discussed in [IMAP-COMPAT]. A full
|
|
discussion of compatibility issues with rare (and presumed extinct)
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-6">Page 6</a></em></dt><dd><p>
|
|
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
|
|
primarily of historical interest.
|
|
</p><p>
|
|
IMAP was originally developed for the older [<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC-822</a>] standard, and
|
|
as a consequence several fetch items in IMAP incorporate "<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>" in
|
|
their name. With the exception of <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.SIZE, there are more modern
|
|
replacements; for example, the modern version of <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.HEADER is
|
|
BODY.PEEK[HEADER]. In all cases, "<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>" should be interpreted as a
|
|
reference to the updated [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] standard.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2">2</a> Protocol Overview</strong></dt><dd>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-2.1">2.1</a> Link Level</strong></dt><dd>
|
|
<p>
|
|
The IMAP4rev1 protocol assumes a reliable data stream such as that
|
|
provided by TCP. When TCP is used, an IMAP4rev1 server listens on
|
|
port 143.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2.2">2.2</a> Commands and Responses</strong></dt><dd>
|
|
<p>
|
|
An IMAP4rev1 connection consists of the establishment of a
|
|
client/server network connection, an initial greeting from the
|
|
server, and client/server interactions. These client/server
|
|
interactions consist of a client command, server data, and a server
|
|
completion result response.
|
|
</p><p>
|
|
All interactions transmitted by client and server are in the form of
|
|
lines, that is, strings that end with a CRLF. The protocol receiver
|
|
of an IMAP4rev1 client or server is either reading a line, or is
|
|
reading a sequence of octets with a known count followed by a line.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2.2.1">2.2.1</a> Client Protocol Sender and Server Protocol Receiver</strong></dt><dd>
|
|
<p>
|
|
The client command begins an operation. Each client command is
|
|
prefixed with an identifier (typically a short alphanumeric string,
|
|
e.g., A0001, A0002, etc.) called a "tag". A different tag is
|
|
generated by the client for each command.
|
|
</p><p>
|
|
Clients <strong>MUST</strong> follow the syntax outlined in this specification
|
|
strictly. It is a syntax error to send a command with missing or
|
|
extraneous spaces or arguments.
|
|
</p><p>
|
|
There are two cases in which a line from the client does not
|
|
represent a complete command. In one case, a command argument is
|
|
quoted with an octet count (see the description of literal in String
|
|
under Data Formats); in the other case, the command arguments require
|
|
server feedback (see the AUTHENTICATE command). In either case, the
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-7">Page 7</a></em></dt><dd><p>
|
|
server sends a command continuation request response if it is ready
|
|
for the octets (if appropriate) and the remainder of the command.
|
|
This response is prefixed with the token "+".
|
|
</p><p>
|
|
Note: If instead, the server detected an error in the
|
|
command, it sends a BAD completion response with a tag
|
|
matching the command (as described below) to reject the
|
|
command and prevent the client from sending any more of the
|
|
command.
|
|
</p><p>
|
|
It is also possible for the server to send a completion
|
|
response for some other command (if multiple commands are
|
|
in progress), or untagged data. In either case, the
|
|
command continuation request is still pending; the client
|
|
takes the appropriate action for the response, and reads
|
|
another response from the server. In all cases, the client
|
|
<strong>MUST</strong> send a complete command (including receiving all
|
|
command continuation request responses and command
|
|
<br>
|
|
continuations for the command) before initiating a new
|
|
command.
|
|
</p><p>
|
|
The protocol receiver of an IMAP4rev1 server reads a command line
|
|
from the client, parses the command and its arguments, and transmits
|
|
server data and a server command completion result response.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2.2.2">2.2.2</a> Server Protocol Sender and Client Protocol Receiver</strong></dt><dd>
|
|
<p>
|
|
Data transmitted by the server to the client and status responses
|
|
that do not indicate command completion are prefixed with the token
|
|
"*", and are called untagged responses.
|
|
</p><p>
|
|
Server data <strong>MAY</strong> be sent as a result of a client command, or <strong>MAY</strong> be
|
|
sent unilaterally by the server. There is no syntactic difference
|
|
between server data that resulted from a specific command and server
|
|
data that were sent unilaterally.
|
|
</p><p>
|
|
The server completion result response indicates the success or
|
|
failure of the operation. It is tagged with the same tag as the
|
|
client command which began the operation. Thus, if more than one
|
|
command is in progress, the tag in a server completion response
|
|
identifies the command to which the response applies. There are
|
|
three possible server completion responses: OK (indicating success),
|
|
NO (indicating failure), or BAD (indicating a protocol error such as
|
|
unrecognized command or command syntax error).
|
|
</p><p>
|
|
Servers <strong>SHOULD</strong> enforce the syntax outlined in this specification
|
|
strictly. Any client command with a protocol syntax error, including
|
|
(but not limited to) missing or extraneous spaces or arguments,
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-8">Page 8</a></em></dt><dd><p>
|
|
<strong>SHOULD</strong> be rejected, and the client given a BAD server completion
|
|
response.
|
|
</p><p>
|
|
The protocol receiver of an IMAP4rev1 client reads a response line
|
|
from the server. It then takes action on the response based upon the
|
|
first token of the response, which can be a tag, a "*", or a "+".
|
|
</p><p>
|
|
A client <strong>MUST</strong> be prepared to accept any server response at all times.
|
|
This includes server data that was not requested. Server data <strong>SHOULD</strong>
|
|
be recorded, so that the client can reference its recorded copy
|
|
rather than sending a command to the server to request the data. In
|
|
the case of certain server data, the data <strong>MUST</strong> be recorded.
|
|
</p><p>
|
|
This topic is discussed in greater detail in the Server Responses
|
|
section.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2.3">2.3</a> Message Attributes</strong></dt><dd>
|
|
<p>
|
|
In addition to message text, each message has several attributes
|
|
associated with it. These attributes can be retrieved individually
|
|
or in conjunction with other attributes or message texts.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2.3.1">2.3.1</a> Message Numbers</strong></dt><dd>
|
|
<p>
|
|
Messages in IMAP4rev1 are accessed by one of two numbers; the unique
|
|
identifier or the message sequence number.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2.3.1.1">2.3.1.1</a> Unique Identifier (UID) Message Attribute</strong></dt><dd>
|
|
<p>
|
|
A 32-bit value assigned to each message, which when used with the
|
|
unique identifier validity value (see below) forms a 64-bit value
|
|
that <strong>MUST NOT</strong> refer to any other message in the mailbox or any
|
|
subsequent mailbox with the same name forever. Unique identifiers
|
|
are assigned in a strictly ascending fashion in the mailbox; as each
|
|
message is added to the mailbox it is assigned a higher UID than the
|
|
message(s) which were added previously. Unlike message sequence
|
|
numbers, unique identifiers are not necessarily contiguous.
|
|
</p><p>
|
|
The unique identifier of a message <strong>MUST NOT</strong> change during the
|
|
session, and <strong>SHOULD NOT</strong> change between sessions. Any change of
|
|
unique identifiers between sessions <strong>MUST</strong> be detectable using the
|
|
UIDVALIDITY mechanism discussed below. Persistent unique identifiers
|
|
are required for a client to resynchronize its state from a previous
|
|
session with the server (e.g., disconnected or offline access
|
|
clients); this is discussed further in [IMAP-DISC].
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-9">Page 9</a></em></dt><dd><p>
|
|
Associated with every mailbox are two values which aid in unique
|
|
identifier handling: the next unique identifier value and the unique
|
|
identifier validity value.
|
|
</p><p>
|
|
The next unique identifier value is the predicted value that will be
|
|
assigned to a new message in the mailbox. Unless the unique
|
|
identifier validity also changes (see below), the next unique
|
|
identifier value <strong>MUST</strong> have the following two characteristics. First,
|
|
the next unique identifier value <strong>MUST NOT</strong> change unless new messages
|
|
are added to the mailbox; and second, the next unique identifier
|
|
value <strong>MUST</strong> change whenever new messages are added to the mailbox,
|
|
even if those new messages are subsequently expunged.
|
|
</p><p>
|
|
Note: The next unique identifier value is intended to
|
|
provide a means for a client to determine whether any
|
|
messages have been delivered to the mailbox since the
|
|
previous time it checked this value. It is not intended to
|
|
provide any guarantee that any message will have this
|
|
unique identifier. A client can only assume, at the time
|
|
that it obtains the next unique identifier value, that
|
|
messages arriving after that time will have a UID greater
|
|
than or equal to that value.
|
|
</p><p>
|
|
The unique identifier validity value is sent in a UIDVALIDITY
|
|
response code in an OK untagged response at mailbox selection time.
|
|
If unique identifiers from an earlier session fail to persist in this
|
|
session, the unique identifier validity value <strong>MUST</strong> be greater than
|
|
the one used in the earlier session.
|
|
</p><p>
|
|
Note: Ideally, unique identifiers <strong>SHOULD</strong> persist at all
|
|
times. Although this specification recognizes that failure
|
|
to persist can be unavoidable in certain server
|
|
<br>
|
|
environments, it STRONGLY ENCOURAGES message store
|
|
<br>
|
|
implementation techniques that avoid this problem. For
|
|
example:
|
|
</p><p>
|
|
1) Unique identifiers <strong>MUST</strong> be strictly ascending in the
|
|
mailbox at all times. If the physical message store is
|
|
re-ordered by a non-IMAP agent, this requires that the
|
|
unique identifiers in the mailbox be regenerated, since
|
|
the former unique identifiers are no longer strictly
|
|
ascending as a result of the re-ordering.
|
|
</p><p>
|
|
2) If the message store has no mechanism to store unique
|
|
identifiers, it must regenerate unique identifiers at
|
|
each session, and each session must have a unique
|
|
UIDVALIDITY value.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-10">Page 10</a></em></dt><dd><p>
|
|
3) If the mailbox is deleted and a new mailbox with the
|
|
same name is created at a later date, the server must
|
|
either keep track of unique identifiers from the
|
|
previous instance of the mailbox, or it must assign a
|
|
new UIDVALIDITY value to the new instance of the
|
|
mailbox. A good UIDVALIDITY value to use in this case
|
|
is a 32-bit representation of the creation date/time of
|
|
the mailbox. It is alright to use a constant such as
|
|
1, but only if it guaranteed that unique identifiers
|
|
will never be reused, even in the case of a mailbox
|
|
being deleted (or renamed) and a new mailbox by the
|
|
same name created at some future time.
|
|
</p><p>
|
|
4) The combination of mailbox name, UIDVALIDITY, and UID
|
|
must refer to a single immutable message on that server
|
|
forever. In particular, the internal date, [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>]
|
|
size, envelope, body structure, and message texts
|
|
(<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>, <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.HEADER, <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.TEXT, and all BODY[...]
|
|
fetch data items) must never change. This does not
|
|
include message numbers, nor does it include attributes
|
|
that can be set by a STORE command (e.g., FLAGS).
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2.3.1.2">2.3.1.2</a> Message Sequence Number Message Attribute</strong></dt><dd>
|
|
<p>
|
|
A relative position from 1 to the number of messages in the mailbox.
|
|
This position <strong>MUST</strong> be ordered by ascending unique identifier. As
|
|
each new message is added, it is assigned a message sequence number
|
|
that is 1 higher than the number of messages in the mailbox before
|
|
that new message was added.
|
|
</p><p>
|
|
Message sequence numbers can be reassigned during the session. For
|
|
example, when a message is permanently removed (expunged) from the
|
|
mailbox, the message sequence number for all subsequent messages is
|
|
decremented. The number of messages in the mailbox is also
|
|
decremented. Similarly, a new message can be assigned a message
|
|
sequence number that was once held by some other message prior to an
|
|
expunge.
|
|
</p><p>
|
|
In addition to accessing messages by relative position in the
|
|
mailbox, message sequence numbers can be used in mathematical
|
|
calculations. For example, if an untagged "11 EXISTS" is received,
|
|
and previously an untagged "8 EXISTS" was received, three new
|
|
messages have arrived with message sequence numbers of 9, 10, and 11.
|
|
Another example, if message 287 in a 523 message mailbox has UID
|
|
12345, there are exactly 286 messages which have lesser UIDs and 236
|
|
messages which have greater UIDs.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-11">Page 11</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-2.3.2">2.3.2</a> Flags Message Attribute</strong></dt><dd>
|
|
<p>
|
|
A list of zero or more named tokens associated with the message. A
|
|
flag is set by its addition to this list, and is cleared by its
|
|
removal. There are two types of flags in IMAP4rev1. A flag of
|
|
either type can be permanent or session-only.
|
|
</p><p>
|
|
A system flag is a flag name that is pre-defined in this
|
|
<br>
|
|
specification. All system flags begin with "\". Certain system
|
|
flags (\Deleted and \Seen) have special semantics described
|
|
elsewhere. The currently-defined system flags are:
|
|
</p><p>
|
|
\Seen
|
|
<br>
|
|
Message has been read
|
|
</p><p>
|
|
\Answered
|
|
<br>
|
|
Message has been answered
|
|
</p><p>
|
|
\Flagged
|
|
<br>
|
|
Message is "flagged" for urgent/special attention
|
|
</p><p>
|
|
\Deleted
|
|
<br>
|
|
Message is "deleted" for removal by later EXPUNGE
|
|
</p><p>
|
|
\Draft
|
|
<br>
|
|
Message has not completed composition (marked as a draft).
|
|
</p><p>
|
|
\Recent
|
|
<br>
|
|
Message is "recently" arrived in this mailbox. This session
|
|
is the first session to have been notified about this
|
|
message; if the session is read-write, subsequent sessions
|
|
will not see \Recent set for this message. This flag can not
|
|
be altered by the client.
|
|
</p><p>
|
|
If it is not possible to determine whether or not this
|
|
session is the first session to be notified about a message,
|
|
then that message <strong>SHOULD</strong> be considered recent.
|
|
</p><p>
|
|
If multiple connections have the same mailbox selected
|
|
simultaneously, it is undefined which of these connections
|
|
will see newly-arrived messages with \Recent set and which
|
|
will see it without \Recent set.
|
|
</p><p>
|
|
A keyword is defined by the server implementation. Keywords do not
|
|
begin with "\". Servers <strong>MAY</strong> permit the client to define new keywords
|
|
in the mailbox (see the description of the PERMANENTFLAGS response
|
|
code for more information).
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-12">Page 12</a></em></dt><dd><p>
|
|
A flag can be permanent or session-only on a per-flag basis.
|
|
Permanent flags are those which the client can add or remove from the
|
|
message flags permanently; that is, concurrent and subsequent
|
|
sessions will see any change in permanent flags. Changes to session
|
|
flags are valid only in that session.
|
|
</p><p>
|
|
Note: The \Recent system flag is a special case of a
|
|
session flag. \Recent can not be used as an argument in a
|
|
STORE or APPEND command, and thus can not be changed at
|
|
all.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2.3.3">2.3.3</a> Internal Date Message Attribute</strong></dt><dd>
|
|
<p>
|
|
The internal date and time of the message on the server. This
|
|
is not the date and time in the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header, but rather a
|
|
date and time which reflects when the message was received. In
|
|
the case of messages delivered via [SMTP], this <strong>SHOULD</strong> be the
|
|
date and time of final delivery of the message as defined by
|
|
[SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
|
|
command, this <strong>SHOULD</strong> be the internal date and time of the source
|
|
message. In the case of messages delivered by the IMAP4rev1
|
|
APPEND command, this <strong>SHOULD</strong> be the date and time as specified in
|
|
the APPEND command description. All other cases are
|
|
<br>
|
|
implementation defined.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2.3.4">2.3.4</a> [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] Size Message Attribute</strong></dt><dd>
|
|
<p>
|
|
The number of octets in the message, as expressed in [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>]
|
|
format.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2.3.5">2.3.5</a> Envelope Structure Message Attribute</strong></dt><dd>
|
|
<p>
|
|
A parsed representation of the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header of the message.
|
|
Note that the IMAP Envelope structure is not the same as an
|
|
[SMTP] envelope.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-2.3.6">2.3.6</a> Body Structure Message Attribute</strong></dt><dd>
|
|
<p>
|
|
A parsed representation of the [MIME-IMB] body structure
|
|
<br>
|
|
information of the message.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-13">Page 13</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-2.4">2.4</a> Message Texts</strong></dt><dd>
|
|
<p>
|
|
In addition to being able to fetch the full [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] text of a
|
|
message, IMAP4rev1 permits the fetching of portions of the full
|
|
message text. Specifically, it is possible to fetch the
|
|
<br>
|
|
[<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] message header, [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] message body, a [MIME-IMB]
|
|
body part, or a [MIME-IMB] header.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-3">3</a> State and Flow Diagram</strong></dt><dd>
|
|
<p>
|
|
Once the connection between client and server is established, an
|
|
IMAP4rev1 connection is in one of four states. The initial
|
|
state is identified in the server greeting. Most commands are
|
|
only valid in certain states. It is a protocol error for the
|
|
client to attempt a command while the connection is in an
|
|
inappropriate state, and the server will respond with a BAD or
|
|
NO (depending upon server implementation) command completion
|
|
result.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-3.1">3.1</a> Not Authenticated State</strong></dt><dd>
|
|
<p>
|
|
In the not authenticated state, the client <strong>MUST</strong> supply
|
|
<br>
|
|
authentication credentials before most commands will be
|
|
<br>
|
|
permitted. This state is entered when a connection starts
|
|
unless the connection has been pre-authenticated.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-3.2">3.2</a> Authenticated State</strong></dt><dd>
|
|
<p>
|
|
In the authenticated state, the client is authenticated and <strong>MUST</strong>
|
|
select a mailbox to access before commands that affect messages
|
|
will be permitted. This state is entered when a
|
|
<br>
|
|
pre-authenticated connection starts, when acceptable
|
|
<br>
|
|
authentication credentials have been provided, after an error in
|
|
selecting a mailbox, or after a successful CLOSE command.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-3.3">3.3</a> Selected State</strong></dt><dd>
|
|
<p>
|
|
In a selected state, a mailbox has been selected to access.
|
|
This state is entered when a mailbox has been successfully
|
|
selected.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-14">Page 14</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-3.4">3.4</a> Logout State</strong></dt><dd>
|
|
<p>
|
|
In the logout state, the connection is being terminated. This
|
|
state can be entered as a result of a client request (via the
|
|
LOGOUT command) or by unilateral action on the part of either
|
|
the client or server.
|
|
</p><p>
|
|
If the client requests the logout state, the server <strong>MUST</strong> send an
|
|
untagged BYE response and a tagged OK response to the LOGOUT
|
|
command before the server closes the connection; and the client
|
|
<strong>MUST</strong> read the tagged OK response to the LOGOUT command before
|
|
the client closes the connection.
|
|
</p><p>
|
|
A server <strong>MUST NOT</strong> unilaterally close the connection without
|
|
sending an untagged BYE response that contains the reason for
|
|
having done so. A client <strong>SHOULD NOT</strong> unilaterally close the
|
|
connection, and instead <strong>SHOULD</strong> issue a LOGOUT command. If the
|
|
server detects that the client has unilaterally closed the
|
|
connection, the server <strong>MAY</strong> omit the untagged BYE response and
|
|
simply close its connection.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-15">Page 15</a></em></dt><dd><p>
|
|
</p><pre> +----------------------+
|
|
|connection established|
|
|
+----------------------+
|
|
||
|
|
\/
|
|
+--------------------------------------+
|
|
| server greeting |
|
|
+--------------------------------------+
|
|
|| (1) || (2) || (3)
|
|
\/ || ||
|
|
+-----------------+ || ||
|
|
|Not Authenticated| || ||
|
|
+-----------------+ || ||
|
|
|| (7) || (4) || ||
|
|
|| \/ \/ ||
|
|
|| +----------------+ ||
|
|
|| | Authenticated |<=++ ||
|
|
|| +----------------+ || ||
|
|
|| || (7) || (5) || (6) ||
|
|
|| || \/ || ||
|
|
|| || +--------+ || ||
|
|
|| || |Selected|==++ ||
|
|
|| || +--------+ ||
|
|
|| || || (7) ||
|
|
\/ \/ \/ \/
|
|
+--------------------------------------+
|
|
| Logout |
|
|
+--------------------------------------+
|
|
||
|
|
\/
|
|
+-------------------------------+
|
|
|both sides close the connection|
|
|
+-------------------------------+
|
|
</pre>
|
|
<p>
|
|
(1) connection without pre-authentication (OK greeting)
|
|
(2) pre-authenticated connection (PREAUTH greeting)
|
|
(3) rejected connection (BYE greeting)
|
|
<br>
|
|
(4) successful LOGIN or AUTHENTICATE command
|
|
<br>
|
|
(5) successful SELECT or EXAMINE command
|
|
<br>
|
|
(6) CLOSE command, or failed SELECT or EXAMINE command
|
|
(7) LOGOUT command, server shutdown, or connection closed
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-16">Page 16</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-4">4</a> Data Formats</strong></dt><dd>
|
|
<p>
|
|
IMAP4rev1 uses textual commands and responses. Data in
|
|
<br>
|
|
IMAP4rev1 can be in one of several forms: atom, number, string,
|
|
parenthesized list, or NIL. Note that a particular data item
|
|
may take more than one form; for example, a data item defined as
|
|
using "astring" syntax may be either an atom or a string.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-4.1">4.1</a> Atom</strong></dt><dd>
|
|
<p>
|
|
An atom consists of one or more non-special characters.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-4.2">4.2</a> Number</strong></dt><dd>
|
|
<p>
|
|
A number consists of one or more digit characters, and
|
|
<br>
|
|
represents a numeric value.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-4.3">4.3</a> String</strong></dt><dd>
|
|
<p>
|
|
A string is in one of two forms: either literal or quoted
|
|
string. The literal form is the general form of string. The
|
|
quoted string form is an alternative that avoids the overhead of
|
|
processing a literal at the cost of limitations of characters
|
|
which may be used.
|
|
</p><p>
|
|
A literal is a sequence of zero or more octets (including CR and
|
|
LF), prefix-quoted with an octet count in the form of an open
|
|
brace ("{"), the number of octets, close brace ("}"), and CRLF.
|
|
In the case of literals transmitted from server to client, the
|
|
CRLF is immediately followed by the octet data. In the case of
|
|
literals transmitted from client to server, the client <strong>MUST</strong> wait
|
|
to receive a command continuation request (described later in
|
|
this document) before sending the octet data (and the remainder
|
|
of the command).
|
|
</p><p>
|
|
A quoted string is a sequence of zero or more 7-bit characters,
|
|
excluding CR and LF, with double quote (<">) characters at each
|
|
end.
|
|
</p><p>
|
|
The empty string is represented as either "" (a quoted string
|
|
with zero characters between double quotes) or as {0} followed
|
|
by CRLF (a literal with an octet count of 0).
|
|
</p><p>
|
|
Note: Even if the octet count is 0, a client transmitting a
|
|
literal <strong>MUST</strong> wait to receive a command continuation request.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-17">Page 17</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-4.3.1">4.3.1</a> 8-bit and Binary Strings</strong></dt><dd>
|
|
<p>
|
|
8-bit textual and binary mail is supported through the use of a
|
|
[MIME-IMB] content transfer encoding. IMAP4rev1 implementations <strong>MAY</strong>
|
|
transmit 8-bit or multi-octet characters in literals, but <strong>SHOULD</strong> do
|
|
so only when the [CHARSET] is identified.
|
|
</p><p>
|
|
Although a BINARY body encoding is defined, unencoded binary strings
|
|
are not permitted. A "binary string" is any string with NUL
|
|
characters. Implementations <strong>MUST</strong> encode binary data into a textual
|
|
form, such as BASE64, before transmitting the data. A string with an
|
|
excessive amount of CTL characters <strong>MAY</strong> also be considered to be
|
|
binary.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-4.4">4.4</a> Parenthesized List</strong></dt><dd>
|
|
<p>
|
|
Data structures are represented as a "parenthesized list"; a sequence
|
|
of data items, delimited by space, and bounded at each end by
|
|
parentheses. A parenthesized list can contain other parenthesized
|
|
lists, using multiple levels of parentheses to indicate nesting.
|
|
</p><p>
|
|
The empty list is represented as () -- a parenthesized list with no
|
|
members.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-4.5">4.5</a> NIL</strong></dt><dd>
|
|
<p>
|
|
The special form "NIL" represents the non-existence of a particular
|
|
data item that is represented as a string or parenthesized list, as
|
|
distinct from the empty string "" or the empty parenthesized list ().
|
|
</p><p>
|
|
Note: NIL is never used for any data item which takes the
|
|
form of an atom. For example, a mailbox name of "NIL" is a
|
|
mailbox named NIL as opposed to a non-existent mailbox
|
|
name. This is because mailbox uses "astring" syntax which
|
|
is an atom or a string. Conversely, an addr-name of NIL is
|
|
a non-existent personal name, because addr-name uses
|
|
"nstring" syntax which is NIL or a string, but never an
|
|
atom.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-18">Page 18</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-5">5</a> Operational Considerations</strong></dt><dd>
|
|
<p>
|
|
The following rules are listed here to ensure that all IMAP4rev1
|
|
implementations interoperate properly.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-5.1">5.1</a> Mailbox Naming</strong></dt><dd>
|
|
<p>
|
|
Mailbox names are 7-bit. Client implementations <strong>MUST NOT</strong> attempt to
|
|
create 8-bit mailbox names, and <strong>SHOULD</strong> interpret any 8-bit mailbox
|
|
names returned by LIST or LSUB as UTF-8. Server implementations
|
|
<strong>SHOULD</strong> prohibit the creation of 8-bit mailbox names, and <strong>SHOULD NOT</strong>
|
|
return 8-bit mailbox names in LIST or LSUB. See <a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-5.1.3">section 5.1.3</a> for
|
|
more information on how to represent non-ASCII mailbox names.
|
|
</p><p>
|
|
Note: 8-bit mailbox names were undefined in earlier
|
|
<br>
|
|
versions of this protocol. Some sites used a local 8-bit
|
|
character set to represent non-ASCII mailbox names. Such
|
|
usage is not interoperable, and is now formally deprecated.
|
|
</p><p>
|
|
The case-insensitive mailbox name INBOX is a special name reserved to
|
|
mean "the primary mailbox for this user on this server". The
|
|
interpretation of all other names is implementation-dependent.
|
|
</p><p>
|
|
In particular, this specification takes no position on case
|
|
sensitivity in non-INBOX mailbox names. Some server implementations
|
|
are fully case-sensitive; others preserve case of a newly-created
|
|
name but otherwise are case-insensitive; and yet others coerce names
|
|
to a particular case. Client implementations <strong>MUST</strong> interact with any
|
|
of these. If a server implementation interprets non-INBOX mailbox
|
|
names as case-insensitive, it <strong>MUST</strong> treat names using the
|
|
<br>
|
|
international naming convention specially as described in section
|
|
5.1.3.
|
|
</p><p>
|
|
There are certain client considerations when creating a new mailbox
|
|
name:
|
|
</p><p>
|
|
</p><pre> 1) Any character which is one of the atom-specials (see the Formal
|
|
Syntax) will require that the mailbox name be represented as a
|
|
quoted string or literal.
|
|
|
|
2) CTL and other non-graphic characters are difficult to represent
|
|
in a user interface and are best avoided.
|
|
|
|
3) Although the list-wildcard characters ("%" and "*") are valid
|
|
in a mailbox name, it is difficult to use such mailbox names
|
|
with the LIST and LSUB commands due to the conflict with
|
|
wildcard interpretation.
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-19">Page 19</a></em></dt><dd><p>
|
|
</p><pre> 4) Usually, a character (determined by the server implementation)
|
|
is reserved to delimit levels of hierarchy.
|
|
|
|
5) Two characters, "#" and "&", have meanings by convention, and
|
|
should be avoided except when used in that convention.
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-5.1.1">5.1.1</a> Mailbox Hierarchy Naming</strong></dt><dd>
|
|
<p>
|
|
If it is desired to export hierarchical mailbox names, mailbox names
|
|
<strong>MUST</strong> be left-to-right hierarchical using a single character to
|
|
separate levels of hierarchy. The same hierarchy separator character
|
|
is used for all levels of hierarchy within a single name.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-5.1.2">5.1.2</a> Mailbox Namespace Naming Convention</strong></dt><dd>
|
|
<p>
|
|
By convention, the first hierarchical element of any mailbox name
|
|
which begins with "#" identifies the "namespace" of the remainder of
|
|
the name. This makes it possible to disambiguate between different
|
|
types of mailbox stores, each of which have their own namespaces.
|
|
</p><p>
|
|
For example, implementations which offer access to USENET
|
|
newsgroups <strong>MAY</strong> use the "#news" namespace to partition the
|
|
USENET newsgroup namespace from that of other mailboxes.
|
|
Thus, the comp.mail.misc newsgroup would have a mailbox
|
|
name of "#news.comp.mail.misc", and the name
|
|
<br>
|
|
"comp.mail.misc" can refer to a different object (e.g., a
|
|
user's private mailbox).
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-5.1.3">5.1.3</a> Mailbox International Naming Convention</strong></dt><dd>
|
|
<p>
|
|
By convention, international mailbox names in IMAP4rev1 are specified
|
|
using a modified version of the UTF-7 encoding described in [UTF-7].
|
|
Modified UTF-7 may also be usable in servers that implement an
|
|
earlier version of this protocol.
|
|
</p><p>
|
|
In modified UTF-7, printable US-ASCII characters, except for "&",
|
|
represent themselves; that is, characters with octet values 0x20-0x25
|
|
and 0x27-0x7e. The character "&" (0x26) is represented by the
|
|
two-octet sequence "&-".
|
|
</p><p>
|
|
All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
|
|
represented in modified BASE64, with a further modification from
|
|
[UTF-7] that "," is used instead of "/". Modified BASE64 <strong>MUST NOT</strong> be
|
|
used to represent any printing US-ASCII character which can represent
|
|
itself.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-20">Page 20</a></em></dt><dd><p>
|
|
"&" is used to shift to modified BASE64 and "-" to shift back to
|
|
US-ASCII. There is no implicit shift from BASE64 to US-ASCII, and
|
|
null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII
|
|
means "&") are not permitted. However, all names start in US-ASCII,
|
|
and <strong>MUST</strong> end in US-ASCII; that is, a name that ends with a non-ASCII
|
|
ISO-10646 character <strong>MUST</strong> end with a "-").
|
|
</p><p>
|
|
The purpose of these modifications is to correct the following
|
|
problems with UTF-7:
|
|
</p><p>
|
|
1) UTF-7 uses the "+" character for shifting; this conflicts with
|
|
the common use of "+" in mailbox names, in particular USENET
|
|
newsgroup names.
|
|
</p><p>
|
|
2) UTF-7's encoding is BASE64 which uses the "/" character; this
|
|
conflicts with the use of "/" as a popular hierarchy delimiter.
|
|
</p><p>
|
|
3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
|
|
the use of "\" as a popular hierarchy delimiter.
|
|
</p><p>
|
|
4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
|
|
the use of "~" in some servers as a home directory indicator.
|
|
</p><p>
|
|
5) UTF-7 permits multiple alternate forms to represent the same
|
|
string; in particular, printable US-ASCII characters can be
|
|
represented in encoded form.
|
|
</p><p>
|
|
Although modified UTF-7 is a convention, it establishes certain
|
|
requirements on server handling of any mailbox name with an
|
|
embedded "&" character. In particular, server implementations
|
|
<strong>MUST</strong> preserve the exact form of the modified BASE64 portion of a
|
|
modified UTF-7 name and treat that text as case-sensitive, even if
|
|
names are otherwise case-insensitive or case-folded.
|
|
</p><p>
|
|
Server implementations <strong>SHOULD</strong> verify that any mailbox name with an
|
|
embedded "&" character, used as an argument to CREATE, is: in the
|
|
correctly modified UTF-7 syntax, has no superfluous shifts, and
|
|
has no encoding in modified BASE64 of any printing US-ASCII
|
|
character which can represent itself. However, client
|
|
implementations <strong>MUST NOT</strong> depend upon the server doing this, and
|
|
<strong>SHOULD NOT</strong> attempt to create a mailbox name with an embedded "&"
|
|
character unless it complies with the modified UTF-7 syntax.
|
|
</p><p>
|
|
Server implementations which export a mail store that does not
|
|
follow the modified UTF-7 convention <strong>MUST</strong> convert to modified
|
|
UTF-7 any mailbox name that contains either non-ASCII characters
|
|
or the "&" character.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-21">Page 21</a></em></dt><dd><p>
|
|
For example, here is a mailbox name which mixes English,
|
|
Chinese, and Japanese text:
|
|
<br>
|
|
~peter/mail/&U,BTFw-/&ZeVnLIqe-
|
|
</p><p>
|
|
For example, the string "&Jjo!" is not a valid mailbox
|
|
name because it does not contain a shift to US-ASCII
|
|
before the "!". The correct form is "&Jjo-!". The
|
|
string "&U,BTFw-&ZeVnLIqe-" is not permitted because it
|
|
contains a superfluous shift. The correct form is
|
|
"&U,BTF2XlZyyKng-".
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-5.2">5.2</a> Mailbox Size and Message Status Updates</strong></dt><dd>
|
|
<p>
|
|
At any time, a server can send data that the client did not request.
|
|
Sometimes, such behavior is <strong>REQUIRED</strong>. For example, agents other than
|
|
the server <strong>MAY</strong> add messages to the mailbox (e.g., new message
|
|
delivery), change the flags of the messages in the mailbox (e.g.,
|
|
simultaneous access to the same mailbox by multiple agents), or even
|
|
remove messages from the mailbox. A server <strong>MUST</strong> send mailbox size
|
|
updates automatically if a mailbox size change is observed during the
|
|
processing of a command. A server <strong>SHOULD</strong> send message flag updates
|
|
automatically, without requiring the client to request such updates
|
|
explicitly.
|
|
</p><p>
|
|
Special rules exist for server notification of a client about the
|
|
removal of messages to prevent synchronization errors; see the
|
|
description of the EXPUNGE response for more detail. In particular,
|
|
it is NOT permitted to send an EXISTS response that would reduce the
|
|
number of messages in the mailbox; only the EXPUNGE response can do
|
|
this.
|
|
</p><p>
|
|
Regardless of what implementation decisions a client makes on
|
|
remembering data from the server, a client implementation <strong>MUST</strong> record
|
|
mailbox size updates. It <strong>MUST NOT</strong> assume that any command after the
|
|
initial mailbox selection will return the size of the mailbox.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-5.3">5.3</a> Response when no Command in Progress</strong></dt><dd>
|
|
<p>
|
|
Server implementations are permitted to send an untagged response
|
|
(except for EXPUNGE) while there is no command in progress. Server
|
|
implementations that send such responses <strong>MUST</strong> deal with flow control
|
|
considerations. Specifically, they <strong>MUST</strong> either (1) verify that the
|
|
size of the data does not exceed the underlying transport's available
|
|
window size, or (2) use non-blocking writes.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-22">Page 22</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-5.4">5.4</a> Autologout Timer</strong></dt><dd>
|
|
<p>
|
|
If a server has an inactivity autologout timer, the duration of that
|
|
timer <strong>MUST</strong> be at least 30 minutes. The receipt of ANY command from
|
|
the client during that interval <strong>SHOULD</strong> suffice to reset the
|
|
autologout timer.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-5.5">5.5</a> Multiple Commands in Progress</strong></dt><dd>
|
|
<p>
|
|
The client <strong>MAY</strong> send another command without waiting for the
|
|
completion result response of a command, subject to ambiguity rules
|
|
(see below) and flow control constraints on the underlying data
|
|
stream. Similarly, a server <strong>MAY</strong> begin processing another command
|
|
before processing the current command to completion, subject to
|
|
ambiguity rules. However, any command continuation request responses
|
|
and command continuations <strong>MUST</strong> be negotiated before any subsequent
|
|
command is initiated.
|
|
</p><p>
|
|
The exception is if an ambiguity would result because of a command
|
|
that would affect the results of other commands. Clients <strong>MUST NOT</strong>
|
|
send multiple commands without waiting if an ambiguity would result.
|
|
If the server detects a possible ambiguity, it <strong>MUST</strong> execute commands
|
|
to completion in the order given by the client.
|
|
</p><p>
|
|
The most obvious example of ambiguity is when a command would affect
|
|
the results of another command, e.g., a FETCH of a message's flags
|
|
and a STORE of that same message's flags.
|
|
</p><p>
|
|
A non-obvious ambiguity occurs with commands that permit an untagged
|
|
EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
|
|
since an untagged EXPUNGE response can invalidate sequence numbers in
|
|
a subsequent command. This is not a problem for FETCH, STORE, or
|
|
SEARCH commands because servers are prohibited from sending EXPUNGE
|
|
responses while any of those commands are in progress. Therefore, if
|
|
the client sends any command other than FETCH, STORE, or SEARCH, it
|
|
<strong>MUST</strong> wait for the completion result response before sending a command
|
|
with message sequence numbers.
|
|
</p><p>
|
|
Note: UID FETCH, UID STORE, and UID SEARCH are different
|
|
commands from FETCH, STORE, and SEARCH. If the client
|
|
sends a UID command, it must wait for a completion result
|
|
response before sending a command with message sequence
|
|
numbers.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-23">Page 23</a></em></dt><dd><p>
|
|
For example, the following non-waiting command sequences are invalid:
|
|
</p><p>
|
|
FETCH + NOOP + STORE
|
|
<br>
|
|
STORE + COPY + FETCH
|
|
<br>
|
|
COPY + COPY
|
|
<br>
|
|
CHECK + FETCH
|
|
</p><p>
|
|
The following are examples of valid non-waiting command sequences:
|
|
</p><p>
|
|
FETCH + STORE + SEARCH + CHECK
|
|
<br>
|
|
STORE + COPY + EXPUNGE
|
|
</p><p>
|
|
UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
|
|
command sequence, depending upon whether or not the second UID
|
|
SEARCH contains message sequence numbers.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-6">6</a> Client Commands</strong></dt><dd>
|
|
<p>
|
|
IMAP4rev1 commands are described in this section. Commands are
|
|
organized by the state in which the command is permitted. Commands
|
|
which are permitted in multiple states are listed in the minimum
|
|
permitted state (for example, commands valid in authenticated and
|
|
selected state are listed in the authenticated state commands).
|
|
</p><p>
|
|
Command arguments, identified by "Arguments:" in the command
|
|
descriptions below, are described by function, not by syntax. The
|
|
precise syntax of command arguments is described in the Formal Syntax
|
|
section.
|
|
</p><p>
|
|
Some commands cause specific server responses to be returned; these
|
|
are identified by "Responses:" in the command descriptions below.
|
|
See the response descriptions in the Responses section for
|
|
information on these responses, and the Formal Syntax section for the
|
|
precise syntax of these responses. It is possible for server data to
|
|
be transmitted as a result of any command. Thus, commands that do
|
|
not specifically require server data specify "no specific responses
|
|
for this command" instead of "none".
|
|
</p><p>
|
|
The "Result:" in the command description refers to the possible
|
|
tagged status responses to a command, and any special interpretation
|
|
of these status responses.
|
|
</p><p>
|
|
The state of a connection is only changed by successful commands
|
|
which are documented as changing state. A rejected command (BAD
|
|
response) never changes the state of the connection or of the
|
|
selected mailbox. A failed command (NO response) generally does not
|
|
change the state of the connection or of the selected mailbox; the
|
|
exception being the SELECT and EXAMINE commands.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-24">Page 24</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-6.1">6.1</a> Client Commands - Any State</strong></dt><dd>
|
|
<p>
|
|
The following commands are valid in any state: CAPABILITY, NOOP, and
|
|
LOGOUT.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-6.1.1">6.1.1</a> CAPABILITY Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: none
|
|
</p><p>
|
|
Responses: <strong>REQUIRED</strong> untagged response: CAPABILITY
|
|
</p><p>
|
|
</p><pre> Result: OK - capability completed
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The CAPABILITY command requests a listing of capabilities that the
|
|
server supports. The server <strong>MUST</strong> send a single untagged
|
|
CAPABILITY response with "IMAP4rev1" as one of the listed
|
|
capabilities before the (tagged) OK response.
|
|
</p><p>
|
|
A capability name which begins with "AUTH=" indicates that the
|
|
server supports that particular authentication mechanism. All
|
|
such names are, by definition, part of this specification. For
|
|
example, the authorization capability for an experimental
|
|
"blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
|
|
"XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
|
|
</p><p>
|
|
Other capability names refer to extensions, revisions, or
|
|
amendments to this specification. See the documentation of the
|
|
CAPABILITY response for additional information. No capabilities,
|
|
beyond the base IMAP4rev1 set defined in this specification, are
|
|
enabled without explicit client action to invoke the capability.
|
|
</p><p>
|
|
Client and server implementations <strong>MUST</strong> implement the STARTTLS,
|
|
LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
|
|
capabilities. See the Security Considerations section for
|
|
important information.
|
|
</p><p>
|
|
See the section entitled "Client Commands -
|
|
<br>
|
|
Experimental/Expansion" for information about the form of site or
|
|
implementation-specific capabilities.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-25">Page 25</a></em></dt><dd><p>
|
|
</p><pre> Example: C: abcd CAPABILITY
|
|
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
|
|
LOGINDISABLED
|
|
S: abcd OK CAPABILITY completed
|
|
C: efgh STARTTLS
|
|
S: efgh OK STARTLS completed
|
|
<TLS negotiation, further commands are under [TLS] layer>
|
|
C: ijkl CAPABILITY
|
|
S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
|
|
S: ijkl OK CAPABILITY completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.1.2">6.1.2</a> NOOP Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: none
|
|
</p><p>
|
|
Responses: no specific responses for this command (but see below)
|
|
</p><p>
|
|
</p><pre> Result: OK - noop completed
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The NOOP command always succeeds. It does nothing.
|
|
</p><p>
|
|
Since any command can return a status update as untagged data, the
|
|
NOOP command can be used as a periodic poll for new messages or
|
|
message status updates during a period of inactivity (this is the
|
|
preferred method to do this). The NOOP command can also be used
|
|
to reset any inactivity autologout timer on the server.
|
|
</p><p>
|
|
</p><pre> Example: C: a002 NOOP
|
|
S: a002 OK NOOP completed
|
|
. . .
|
|
C: a047 NOOP
|
|
S: * 22 EXPUNGE
|
|
S: * 23 EXISTS
|
|
S: * 3 RECENT
|
|
S: * 14 FETCH (FLAGS (\Seen \Deleted))
|
|
S: a047 OK NOOP completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-26">Page 26</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-6.1.3">6.1.3</a> LOGOUT Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: none
|
|
</p><p>
|
|
Responses: <strong>REQUIRED</strong> untagged response: BYE
|
|
</p><p>
|
|
</p><pre> Result: OK - logout completed
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The LOGOUT command informs the server that the client is done with
|
|
the connection. The server <strong>MUST</strong> send a BYE untagged response
|
|
before the (tagged) OK response, and then close the network
|
|
connection.
|
|
</p><p>
|
|
</p><pre> Example: C: A023 LOGOUT
|
|
S: * BYE IMAP4rev1 Server logging out
|
|
S: A023 OK LOGOUT completed
|
|
(Server and client then close the connection)
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.2">6.2</a> Client Commands - Not Authenticated State</strong></dt><dd>
|
|
<p>
|
|
In the not authenticated state, the AUTHENTICATE or LOGIN command
|
|
establishes authentication and enters the authenticated state. The
|
|
AUTHENTICATE command provides a general mechanism for a variety of
|
|
authentication techniques, privacy protection, and integrity
|
|
checking; whereas the LOGIN command uses a traditional user name and
|
|
plaintext password pair and has no means of establishing privacy
|
|
protection or integrity checking.
|
|
</p><p>
|
|
The STARTTLS command is an alternate form of establishing session
|
|
privacy protection and integrity checking, but does not establish
|
|
authentication or enter the authenticated state.
|
|
</p><p>
|
|
Server implementations <strong>MAY</strong> allow access to certain mailboxes without
|
|
establishing authentication. This can be done by means of the
|
|
ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older
|
|
convention is a LOGIN command using the userid "anonymous"; in this
|
|
case, a password is required although the server may choose to accept
|
|
any password. The restrictions placed on anonymous users are
|
|
implementation-dependent.
|
|
</p><p>
|
|
Once authenticated (including as anonymous), it is not possible to
|
|
re-enter not authenticated state.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-27">Page 27</a></em></dt><dd><p>
|
|
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
|
|
the following commands are valid in the not authenticated state:
|
|
STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations
|
|
section for important information about these commands.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-6.2.1">6.2.1</a> STARTTLS Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: none
|
|
</p><p>
|
|
Responses: no specific response for this command
|
|
</p><p>
|
|
</p><pre> Result: OK - starttls completed, begin TLS negotiation
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
A [TLS] negotiation begins immediately after the CRLF at the end
|
|
of the tagged OK response from the server. Once a client issues a
|
|
STARTTLS command, it <strong>MUST NOT</strong> issue further commands until a
|
|
server response is seen and the [TLS] negotiation is complete.
|
|
</p><p>
|
|
The server remains in the non-authenticated state, even if client
|
|
credentials are supplied during the [TLS] negotiation. This does
|
|
not preclude an authentication mechanism such as EXTERNAL (defined
|
|
in [SASL]) from using client identity determined by the [TLS]
|
|
negotiation.
|
|
</p><p>
|
|
Once [TLS] has been started, the client <strong>MUST</strong> discard cached
|
|
information about server capabilities and <strong>SHOULD</strong> re-issue the
|
|
CAPABILITY command. This is necessary to protect against man-in-
|
|
the-middle attacks which alter the capabilities list prior to
|
|
STARTTLS. The server <strong>MAY</strong> advertise different capabilities after
|
|
STARTTLS.
|
|
</p><p>
|
|
</p><pre> Example: C: a001 CAPABILITY
|
|
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
|
|
S: a001 OK CAPABILITY completed
|
|
C: a002 STARTTLS
|
|
S: a002 OK Begin TLS negotiation now
|
|
<TLS negotiation, further commands are under [TLS] layer>
|
|
C: a003 CAPABILITY
|
|
S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
|
|
S: a003 OK CAPABILITY completed
|
|
C: a004 LOGIN joe password
|
|
S: a004 OK LOGIN completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-28">Page 28</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-6.2.2">6.2.2</a> AUTHENTICATE Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: authentication mechanism name
|
|
</p><p>
|
|
Responses: continuation data can be requested
|
|
</p><p>
|
|
</p><pre> Result: OK - authenticate completed, now in authenticated state
|
|
NO - authenticate failure: unsupported authentication
|
|
mechanism, credentials rejected
|
|
BAD - command unknown or arguments invalid,
|
|
authentication exchange cancelled
|
|
</pre>
|
|
<p>
|
|
The AUTHENTICATE command indicates a [SASL] authentication
|
|
mechanism to the server. If the server supports the requested
|
|
authentication mechanism, it performs an authentication protocol
|
|
exchange to authenticate and identify the client. It <strong>MAY</strong> also
|
|
negotiate an <strong>OPTIONAL</strong> security layer for subsequent protocol
|
|
interactions. If the requested authentication mechanism is not
|
|
supported, the server <strong>SHOULD</strong> reject the AUTHENTICATE command by
|
|
sending a tagged NO response.
|
|
</p><p>
|
|
The AUTHENTICATE command does not support the optional "initial
|
|
response" feature of [SASL]. Section 5.1 of [SASL] specifies how
|
|
to handle an authentication mechanism which uses an initial
|
|
response.
|
|
</p><p>
|
|
The service name specified by this protocol's profile of [SASL] is
|
|
"imap".
|
|
</p><p>
|
|
The authentication protocol exchange consists of a series of
|
|
server challenges and client responses that are specific to the
|
|
authentication mechanism. A server challenge consists of a
|
|
command continuation request response with the "+" token followed
|
|
by a BASE64 encoded string. The client response consists of a
|
|
single line consisting of a BASE64 encoded string. If the client
|
|
wishes to cancel an authentication exchange, it issues a line
|
|
consisting of a single "*". If the server receives such a
|
|
response, it <strong>MUST</strong> reject the AUTHENTICATE command by sending a
|
|
tagged BAD response.
|
|
</p><p>
|
|
If a security layer is negotiated through the [SASL]
|
|
<br>
|
|
authentication exchange, it takes effect immediately following the
|
|
CRLF that concludes the authentication exchange for the client,
|
|
and the CRLF of the tagged OK response for the server.
|
|
</p><p>
|
|
While client and server implementations <strong>MUST</strong> implement the
|
|
AUTHENTICATE command itself, it is not required to implement any
|
|
authentication mechanisms other than the PLAIN mechanism described
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-29">Page 29</a></em></dt><dd><p>
|
|
in [IMAP-TLS]. Also, an authentication mechanism is not required
|
|
to support any security layers.
|
|
</p><p>
|
|
Note: a server implementation <strong>MUST</strong> implement a
|
|
<br>
|
|
configuration in which it does NOT permit any plaintext
|
|
password mechanisms, unless either the STARTTLS command
|
|
has been negotiated or some other mechanism that
|
|
<br>
|
|
protects the session from password snooping has been
|
|
provided. Server sites <strong>SHOULD NOT</strong> use any configuration
|
|
which permits a plaintext password mechanism without
|
|
such a protection mechanism against password snooping.
|
|
Client and server implementations <strong>SHOULD</strong> implement
|
|
additional [SASL] mechanisms that do not use plaintext
|
|
passwords, such the GSSAPI mechanism described in [SASL]
|
|
and/or the [DIGEST-MD5] mechanism.
|
|
</p><p>
|
|
Servers and clients can support multiple authentication
|
|
mechanisms. The server <strong>SHOULD</strong> list its supported authentication
|
|
mechanisms in the response to the CAPABILITY command so that the
|
|
client knows which authentication mechanisms to use.
|
|
</p><p>
|
|
A server <strong>MAY</strong> include a CAPABILITY response code in the tagged OK
|
|
response of a successful AUTHENTICATE command in order to send
|
|
capabilities automatically. It is unnecessary for a client to
|
|
send a separate CAPABILITY command if it recognizes these
|
|
automatic capabilities. This should only be done if a security
|
|
layer was not negotiated by the AUTHENTICATE command, because the
|
|
tagged OK response as part of an AUTHENTICATE command is not
|
|
protected by encryption/integrity checking. [SASL] requires the
|
|
client to re-issue a CAPABILITY command in this case.
|
|
</p><p>
|
|
If an AUTHENTICATE command fails with a NO response, the client
|
|
<strong>MAY</strong> try another authentication mechanism by issuing another
|
|
AUTHENTICATE command. It <strong>MAY</strong> also attempt to authenticate by
|
|
using the LOGIN command (see <a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-6.2.3">section 6.2.3</a> for more detail). In
|
|
other words, the client <strong>MAY</strong> request authentication types in
|
|
decreasing order of preference, with the LOGIN command as a last
|
|
resort.
|
|
</p><p>
|
|
The authorization identity passed from the client to the server
|
|
during the authentication exchange is interpreted by the server as
|
|
the user name whose privileges the client is requesting.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-30">Page 30</a></em></dt><dd><p>
|
|
</p><pre> Example: S: * OK IMAP4rev1 Server
|
|
C: A001 AUTHENTICATE GSSAPI
|
|
S: +
|
|
C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
|
|
MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
|
|
b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
|
|
Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
|
|
cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
|
|
AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
|
|
C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
|
|
I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
|
|
vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
|
|
pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
|
|
FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
|
|
NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
|
|
O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
|
|
vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
|
|
S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
|
|
AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
|
|
uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
|
|
C:
|
|
S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
|
|
ceP2CWY0SR0fAQAgAAQEBAQ=
|
|
C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
|
|
wkhbfa2QteAQAgAG1yYwE=
|
|
S: A001 OK GSSAPI authentication successful
|
|
</pre>
|
|
<p>
|
|
Note: The line breaks within server challenges and client
|
|
responses are for editorial clarity and are not in real
|
|
authenticators.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-6.2.3">6.2.3</a> LOGIN Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: user name
|
|
<br>
|
|
password
|
|
</p><p>
|
|
Responses: no specific responses for this command
|
|
</p><p>
|
|
</p><pre> Result: OK - login completed, now in authenticated state
|
|
NO - login failure: user name or password rejected
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The LOGIN command identifies the client to the server and carries
|
|
the plaintext password authenticating this user.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-31">Page 31</a></em></dt><dd><p>
|
|
A server <strong>MAY</strong> include a CAPABILITY response code in the tagged OK
|
|
response to a successful LOGIN command in order to send
|
|
capabilities automatically. It is unnecessary for a client to
|
|
send a separate CAPABILITY command if it recognizes these
|
|
automatic capabilities.
|
|
</p><p>
|
|
</p><pre> Example: C: a001 LOGIN SMITH SESAME
|
|
S: a001 OK LOGIN completed
|
|
</pre>
|
|
<p>
|
|
Note: Use of the LOGIN command over an insecure network
|
|
(such as the Internet) is a security risk, because anyone
|
|
monitoring network traffic can obtain plaintext passwords.
|
|
The LOGIN command <strong>SHOULD NOT</strong> be used except as a last
|
|
resort, and it is recommended that client implementations
|
|
have a means to disable any automatic use of the LOGIN
|
|
command.
|
|
</p><p>
|
|
Unless either the STARTTLS command has been negotiated or
|
|
some other mechanism that protects the session from
|
|
<br>
|
|
password snooping has been provided, a server
|
|
<br>
|
|
implementation <strong>MUST</strong> implement a configuration in which it
|
|
advertises the LOGINDISABLED capability and does NOT permit
|
|
the LOGIN command. Server sites <strong>SHOULD NOT</strong> use any
|
|
<br>
|
|
configuration which permits the LOGIN command without such
|
|
a protection mechanism against password snooping. A client
|
|
implementation <strong>MUST NOT</strong> send a LOGIN command if the
|
|
<br>
|
|
LOGINDISABLED capability is advertised.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-6.3">6.3</a> Client Commands - Authenticated State</strong></dt><dd>
|
|
<p>
|
|
In the authenticated state, commands that manipulate mailboxes as
|
|
atomic entities are permitted. Of these commands, the SELECT and
|
|
EXAMINE commands will select a mailbox for access and enter the
|
|
selected state.
|
|
</p><p>
|
|
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
|
|
the following commands are valid in the authenticated state: SELECT,
|
|
EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
|
|
STATUS, and APPEND.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-32">Page 32</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-6.3.1">6.3.1</a> SELECT Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: mailbox name
|
|
</p><p>
|
|
Responses: <strong>REQUIRED</strong> untagged responses: FLAGS, EXISTS, RECENT
|
|
<strong>REQUIRED</strong> OK untagged responses: UNSEEN, PERMANENTFLAGS,
|
|
UIDNEXT, UIDVALIDITY
|
|
</p><p>
|
|
</p><pre> Result: OK - select completed, now in selected state
|
|
NO - select failure, now in authenticated state: no
|
|
such mailbox, can't access mailbox
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The SELECT command selects a mailbox so that messages in the
|
|
mailbox can be accessed. Before returning an OK to the client,
|
|
the server <strong>MUST</strong> send the following untagged data to the client.
|
|
Note that earlier versions of this protocol only required the
|
|
FLAGS, EXISTS, and RECENT untagged data; consequently, client
|
|
implementations <strong>SHOULD</strong> implement default behavior for missing data
|
|
as discussed with the individual item.
|
|
</p><p>
|
|
</p><pre> FLAGS Defined flags in the mailbox. See the description
|
|
of the FLAGS response for more detail.
|
|
|
|
<n> EXISTS The number of messages in the mailbox. See the
|
|
description of the EXISTS response for more detail.
|
|
|
|
<n> RECENT The number of messages with the \Recent flag set.
|
|
See the description of the RECENT response for more
|
|
detail.
|
|
</pre>
|
|
<p>
|
|
OK [UNSEEN <n>]
|
|
<br>
|
|
The message sequence number of the first unseen
|
|
message in the mailbox. If this is missing, the
|
|
client can not make any assumptions about the first
|
|
unseen message in the mailbox, and needs to issue a
|
|
SEARCH command if it wants to find it.
|
|
</p><p>
|
|
OK [PERMANENTFLAGS (<list of flags>)]
|
|
<br>
|
|
A list of message flags that the client can change
|
|
permanently. If this is missing, the client should
|
|
assume that all flags can be changed permanently.
|
|
</p><p>
|
|
OK [UIDNEXT <n>]
|
|
<br>
|
|
The next unique identifier value. Refer to section
|
|
2.3.1.1 for more information. If this is missing,
|
|
the client can not make any assumptions about the
|
|
next unique identifier value.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-33">Page 33</a></em></dt><dd><p>
|
|
OK [UIDVALIDITY <n>]
|
|
<br>
|
|
The unique identifier validity value. Refer to
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.1.1">section 2.3.1.1</a> for more information. If this is
|
|
missing, the server does not support unique
|
|
identifiers.
|
|
</p><p>
|
|
Only one mailbox can be selected at a time in a connection;
|
|
simultaneous access to multiple mailboxes requires multiple
|
|
connections. The SELECT command automatically deselects any
|
|
currently selected mailbox before attempting the new selection.
|
|
Consequently, if a mailbox is selected and a SELECT command that
|
|
fails is attempted, no mailbox is selected.
|
|
</p><p>
|
|
If the client is permitted to modify the mailbox, the server
|
|
<strong>SHOULD</strong> prefix the text of the tagged OK response with the
|
|
"[READ-WRITE]" response code.
|
|
</p><p>
|
|
If the client is not permitted to modify the mailbox but is
|
|
permitted read access, the mailbox is selected as read-only, and
|
|
the server <strong>MUST</strong> prefix the text of the tagged OK response to
|
|
SELECT with the "[READ-ONLY]" response code. Read-only access
|
|
through SELECT differs from the EXAMINE command in that certain
|
|
read-only mailboxes <strong>MAY</strong> permit the change of permanent state on a
|
|
per-user (as opposed to global) basis. Netnews messages marked in
|
|
a server-based .newsrc file are an example of such per-user
|
|
permanent state that can be modified with read-only mailboxes.
|
|
</p><p>
|
|
</p><pre> Example: C: A142 SELECT INBOX
|
|
S: * 172 EXISTS
|
|
S: * 1 RECENT
|
|
S: * OK [UNSEEN 12] Message 12 is first unseen
|
|
S: * OK [UIDVALIDITY 3857529045] UIDs valid
|
|
S: * OK [UIDNEXT 4392] Predicted next UID
|
|
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
|
|
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
|
|
S: A142 OK [READ-WRITE] SELECT completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-34">Page 34</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-6.3.2">6.3.2</a> EXAMINE Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: mailbox name
|
|
</p><p>
|
|
Responses: <strong>REQUIRED</strong> untagged responses: FLAGS, EXISTS, RECENT
|
|
<strong>REQUIRED</strong> OK untagged responses: UNSEEN, PERMANENTFLAGS,
|
|
UIDNEXT, UIDVALIDITY
|
|
</p><p>
|
|
</p><pre> Result: OK - examine completed, now in selected state
|
|
NO - examine failure, now in authenticated state: no
|
|
such mailbox, can't access mailbox
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The EXAMINE command is identical to SELECT and returns the same
|
|
output; however, the selected mailbox is identified as read-only.
|
|
No changes to the permanent state of the mailbox, including
|
|
per-user state, are permitted; in particular, EXAMINE <strong>MUST NOT</strong>
|
|
cause messages to lose the \Recent flag.
|
|
</p><p>
|
|
The text of the tagged OK response to the EXAMINE command <strong>MUST</strong>
|
|
begin with the "[READ-ONLY]" response code.
|
|
</p><p>
|
|
</p><pre> Example: C: A932 EXAMINE blurdybloop
|
|
S: * 17 EXISTS
|
|
S: * 2 RECENT
|
|
S: * OK [UNSEEN 8] Message 8 is first unseen
|
|
S: * OK [UIDVALIDITY 3857529045] UIDs valid
|
|
S: * OK [UIDNEXT 4392] Predicted next UID
|
|
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
|
|
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
|
|
S: A932 OK [READ-ONLY] EXAMINE completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.3.3">6.3.3</a> CREATE Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: mailbox name
|
|
</p><p>
|
|
Responses: no specific responses for this command
|
|
</p><p>
|
|
</p><pre> Result: OK - create completed
|
|
NO - create failure: can't create mailbox with that name
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The CREATE command creates a mailbox with the given name. An OK
|
|
response is returned only if a new mailbox with that name has been
|
|
created. It is an error to attempt to create INBOX or a mailbox
|
|
with a name that refers to an extant mailbox. Any error in
|
|
creation will return a tagged NO response.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-35">Page 35</a></em></dt><dd><p>
|
|
If the mailbox name is suffixed with the server's hierarchy
|
|
separator character (as returned from the server by a LIST
|
|
command), this is a declaration that the client intends to create
|
|
mailbox names under this name in the hierarchy. Server
|
|
implementations that do not require this declaration <strong>MUST</strong> ignore
|
|
the declaration. In any case, the name created is without the
|
|
trailing hierarchy delimiter.
|
|
</p><p>
|
|
If the server's hierarchy separator character appears elsewhere in
|
|
the name, the server <strong>SHOULD</strong> create any superior hierarchical names
|
|
that are needed for the CREATE command to be successfully
|
|
completed. In other words, an attempt to create "foo/bar/zap" on
|
|
a server in which "/" is the hierarchy separator character <strong>SHOULD</strong>
|
|
create foo/ and foo/bar/ if they do not already exist.
|
|
</p><p>
|
|
If a new mailbox is created with the same name as a mailbox which
|
|
was deleted, its unique identifiers <strong>MUST</strong> be greater than any
|
|
unique identifiers used in the previous incarnation of the mailbox
|
|
UNLESS the new incarnation has a different unique identifier
|
|
validity value. See the description of the UID command for more
|
|
detail.
|
|
</p><p>
|
|
</p><pre> Example: C: A003 CREATE owatagusiam/
|
|
S: A003 OK CREATE completed
|
|
C: A004 CREATE owatagusiam/blurdybloop
|
|
S: A004 OK CREATE completed
|
|
</pre>
|
|
<p>
|
|
Note: The interpretation of this example depends on whether
|
|
"/" was returned as the hierarchy separator from LIST. If
|
|
"/" is the hierarchy separator, a new level of hierarchy
|
|
named "owatagusiam" with a member called "blurdybloop" is
|
|
created. Otherwise, two mailboxes at the same hierarchy
|
|
level are created.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-6.3.4">6.3.4</a> DELETE Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: mailbox name
|
|
</p><p>
|
|
Responses: no specific responses for this command
|
|
</p><p>
|
|
</p><pre> Result: OK - delete completed
|
|
NO - delete failure: can't delete mailbox with that name
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-36">Page 36</a></em></dt><dd><p>
|
|
The DELETE command permanently removes the mailbox with the given
|
|
name. A tagged OK response is returned only if the mailbox has
|
|
been deleted. It is an error to attempt to delete INBOX or a
|
|
mailbox name that does not exist.
|
|
</p><p>
|
|
The DELETE command <strong>MUST NOT</strong> remove inferior hierarchical names.
|
|
For example, if a mailbox "foo" has an inferior "foo.bar"
|
|
(assuming "." is the hierarchy delimiter character), removing
|
|
"foo" <strong>MUST NOT</strong> remove "foo.bar". It is an error to attempt to
|
|
delete a name that has inferior hierarchical names and also has
|
|
the \Noselect mailbox name attribute (see the description of the
|
|
LIST response for more details).
|
|
</p><p>
|
|
It is permitted to delete a name that has inferior hierarchical
|
|
names and does not have the \Noselect mailbox name attribute. In
|
|
this case, all messages in that mailbox are removed, and the name
|
|
will acquire the \Noselect mailbox name attribute.
|
|
</p><p>
|
|
The value of the highest-used unique identifier of the deleted
|
|
mailbox <strong>MUST</strong> be preserved so that a new mailbox created with the
|
|
same name will not reuse the identifiers of the former
|
|
incarnation, UNLESS the new incarnation has a different unique
|
|
identifier validity value. See the description of the UID command
|
|
for more detail.
|
|
</p><p>
|
|
</p><pre> Examples: C: A682 LIST "" *
|
|
S: * LIST () "/" blurdybloop
|
|
S: * LIST (\Noselect) "/" foo
|
|
S: * LIST () "/" foo/bar
|
|
S: A682 OK LIST completed
|
|
C: A683 DELETE blurdybloop
|
|
S: A683 OK DELETE completed
|
|
C: A684 DELETE foo
|
|
S: A684 NO Name "foo" has inferior hierarchical names
|
|
C: A685 DELETE foo/bar
|
|
S: A685 OK DELETE Completed
|
|
C: A686 LIST "" *
|
|
S: * LIST (\Noselect) "/" foo
|
|
S: A686 OK LIST completed
|
|
C: A687 DELETE foo
|
|
S: A687 OK DELETE Completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-37">Page 37</a></em></dt><dd><p>
|
|
</p><pre> C: A82 LIST "" *
|
|
S: * LIST () "." blurdybloop
|
|
S: * LIST () "." foo
|
|
S: * LIST () "." foo.bar
|
|
S: A82 OK LIST completed
|
|
C: A83 DELETE blurdybloop
|
|
S: A83 OK DELETE completed
|
|
C: A84 DELETE foo
|
|
S: A84 OK DELETE Completed
|
|
C: A85 LIST "" *
|
|
S: * LIST () "." foo.bar
|
|
S: A85 OK LIST completed
|
|
C: A86 LIST "" %
|
|
S: * LIST (\Noselect) "." foo
|
|
S: A86 OK LIST completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.3.5">6.3.5</a> RENAME Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: existing mailbox name
|
|
<br>
|
|
new mailbox name
|
|
</p><p>
|
|
Responses: no specific responses for this command
|
|
</p><p>
|
|
</p><pre> Result: OK - rename completed
|
|
NO - rename failure: can't rename mailbox with that name,
|
|
can't rename to mailbox with that name
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The RENAME command changes the name of a mailbox. A tagged OK
|
|
response is returned only if the mailbox has been renamed. It is
|
|
an error to attempt to rename from a mailbox name that does not
|
|
exist or to a mailbox name that already exists. Any error in
|
|
renaming will return a tagged NO response.
|
|
</p><p>
|
|
If the name has inferior hierarchical names, then the inferior
|
|
hierarchical names <strong>MUST</strong> also be renamed. For example, a rename of
|
|
"foo" to "zap" will rename "foo/bar" (assuming "/" is the
|
|
hierarchy delimiter character) to "zap/bar".
|
|
</p><p>
|
|
If the server's hierarchy separator character appears in the name,
|
|
the server <strong>SHOULD</strong> create any superior hierarchical names that are
|
|
needed for the RENAME command to complete successfully. In other
|
|
words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
|
|
server in which "/" is the hierarchy separator character <strong>SHOULD</strong>
|
|
create baz/ and baz/rag/ if they do not already exist.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-38">Page 38</a></em></dt><dd><p>
|
|
The value of the highest-used unique identifier of the old mailbox
|
|
name <strong>MUST</strong> be preserved so that a new mailbox created with the same
|
|
name will not reuse the identifiers of the former incarnation,
|
|
UNLESS the new incarnation has a different unique identifier
|
|
validity value. See the description of the UID command for more
|
|
detail.
|
|
</p><p>
|
|
Renaming INBOX is permitted, and has special behavior. It moves
|
|
all messages in INBOX to a new mailbox with the given name,
|
|
leaving INBOX empty. If the server implementation supports
|
|
inferior hierarchical names of INBOX, these are unaffected by a
|
|
rename of INBOX.
|
|
</p><p>
|
|
</p><pre> Examples: C: A682 LIST "" *
|
|
S: * LIST () "/" blurdybloop
|
|
S: * LIST (\Noselect) "/" foo
|
|
S: * LIST () "/" foo/bar
|
|
S: A682 OK LIST completed
|
|
C: A683 RENAME blurdybloop sarasoop
|
|
S: A683 OK RENAME completed
|
|
C: A684 RENAME foo zowie
|
|
S: A684 OK RENAME Completed
|
|
C: A685 LIST "" *
|
|
S: * LIST () "/" sarasoop
|
|
S: * LIST (\Noselect) "/" zowie
|
|
S: * LIST () "/" zowie/bar
|
|
S: A685 OK LIST completed
|
|
|
|
C: Z432 LIST "" *
|
|
S: * LIST () "." INBOX
|
|
S: * LIST () "." INBOX.bar
|
|
S: Z432 OK LIST completed
|
|
C: Z433 RENAME INBOX old-mail
|
|
S: Z433 OK RENAME completed
|
|
C: Z434 LIST "" *
|
|
S: * LIST () "." INBOX
|
|
S: * LIST () "." INBOX.bar
|
|
S: * LIST () "." old-mail
|
|
S: Z434 OK LIST completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-39">Page 39</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-6.3.6">6.3.6</a> SUBSCRIBE Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: mailbox
|
|
</p><p>
|
|
Responses: no specific responses for this command
|
|
</p><p>
|
|
</p><pre> Result: OK - subscribe completed
|
|
NO - subscribe failure: can't subscribe to that name
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The SUBSCRIBE command adds the specified mailbox name to the
|
|
server's set of "active" or "subscribed" mailboxes as returned by
|
|
the LSUB command. This command returns a tagged OK response only
|
|
if the subscription is successful.
|
|
</p><p>
|
|
A server <strong>MAY</strong> validate the mailbox argument to SUBSCRIBE to verify
|
|
that it exists. However, it <strong>MUST NOT</strong> unilaterally remove an
|
|
existing mailbox name from the subscription list even if a mailbox
|
|
by that name no longer exists.
|
|
</p><p>
|
|
Note: This requirement is because a server site can
|
|
choose to routinely remove a mailbox with a well-known
|
|
name (e.g., "system-alerts") after its contents expire,
|
|
with the intention of recreating it when new contents
|
|
are appropriate.
|
|
</p><p>
|
|
</p><pre> Example: C: A002 SUBSCRIBE #news.comp.mail.mime
|
|
S: A002 OK SUBSCRIBE completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.3.7">6.3.7</a> UNSUBSCRIBE Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: mailbox name
|
|
</p><p>
|
|
Responses: no specific responses for this command
|
|
</p><p>
|
|
</p><pre> Result: OK - unsubscribe completed
|
|
NO - unsubscribe failure: can't unsubscribe that name
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The UNSUBSCRIBE command removes the specified mailbox name from
|
|
the server's set of "active" or "subscribed" mailboxes as returned
|
|
by the LSUB command. This command returns a tagged OK response
|
|
only if the unsubscription is successful.
|
|
</p><p>
|
|
</p><pre> Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
|
|
S: A002 OK UNSUBSCRIBE completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-40">Page 40</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-6.3.8">6.3.8</a> LIST Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: reference name
|
|
<br>
|
|
mailbox name with possible wildcards
|
|
</p><p>
|
|
Responses: untagged responses: LIST
|
|
</p><p>
|
|
</p><pre> Result: OK - list completed
|
|
NO - list failure: can't list that reference or name
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The LIST command returns a subset of names from the complete set
|
|
of all names available to the client. Zero or more untagged LIST
|
|
replies are returned, containing the name attributes, hierarchy
|
|
delimiter, and name; see the description of the LIST reply for
|
|
more detail.
|
|
</p><p>
|
|
The LIST command <strong>SHOULD</strong> return its data quickly, without undue
|
|
delay. For example, it <strong>SHOULD NOT</strong> go to excess trouble to
|
|
calculate the \Marked or \Unmarked status or perform other
|
|
processing; if each name requires 1 second of processing, then a
|
|
list of 1200 names would take 20 minutes!
|
|
</p><p>
|
|
An empty ("" string) reference name argument indicates that the
|
|
mailbox name is interpreted as by SELECT. The returned mailbox
|
|
names <strong>MUST</strong> match the supplied mailbox name pattern. A non-empty
|
|
reference name argument is the name of a mailbox or a level of
|
|
mailbox hierarchy, and indicates the context in which the mailbox
|
|
name is interpreted.
|
|
</p><p>
|
|
An empty ("" string) mailbox name argument is a special request to
|
|
return the hierarchy delimiter and the root name of the name given
|
|
in the reference. The value returned as the root <strong>MAY</strong> be the empty
|
|
string if the reference is non-rooted or is an empty string. In
|
|
all cases, a hierarchy delimiter (or NIL if there is no hierarchy)
|
|
is returned. This permits a client to get the hierarchy delimiter
|
|
(or find out that the mailbox names are flat) even when no
|
|
mailboxes by that name currently exist.
|
|
</p><p>
|
|
The reference and mailbox name arguments are interpreted into a
|
|
canonical form that represents an unambiguous left-to-right
|
|
hierarchy. The returned mailbox names will be in the interpreted
|
|
form.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-41">Page 41</a></em></dt><dd><p>
|
|
Note: The interpretation of the reference argument is
|
|
implementation-defined. It depends upon whether the
|
|
server implementation has a concept of the "current
|
|
working directory" and leading "break out characters",
|
|
which override the current working directory.
|
|
</p><p>
|
|
For example, on a server which exports a UNIX or NT
|
|
filesystem, the reference argument contains the current
|
|
working directory, and the mailbox name argument would
|
|
contain the name as interpreted in the current working
|
|
directory.
|
|
</p><p>
|
|
If a server implementation has no concept of break out
|
|
characters, the canonical form is normally the reference
|
|
name appended with the mailbox name. Note that if the
|
|
server implements the namespace convention (section
|
|
5.1.2), "#" is a break out character and must be treated
|
|
as such.
|
|
</p><p>
|
|
If the reference argument is not a level of mailbox
|
|
hierarchy (that is, it is a \NoInferiors name), and/or
|
|
the reference argument does not end with the hierarchy
|
|
delimiter, it is implementation-dependent how this is
|
|
interpreted. For example, a reference of "foo/bar" and
|
|
mailbox name of "rag/baz" could be interpreted as
|
|
"foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz".
|
|
A client <strong>SHOULD NOT</strong> use such a reference argument except
|
|
at the explicit request of the user. A hierarchical
|
|
browser <strong>MUST NOT</strong> make any assumptions about server
|
|
interpretation of the reference unless the reference is
|
|
a level of mailbox hierarchy AND ends with the hierarchy
|
|
delimiter.
|
|
</p><p>
|
|
Any part of the reference argument that is included in the
|
|
interpreted form <strong>SHOULD</strong> prefix the interpreted form. It <strong>SHOULD</strong>
|
|
also be in the same form as the reference name argument. This
|
|
rule permits the client to determine if the returned mailbox name
|
|
is in the context of the reference argument, or if something about
|
|
the mailbox argument overrode the reference argument. Without
|
|
this rule, the client would have to have knowledge of the server's
|
|
naming semantics including what characters are "breakouts" that
|
|
override a naming context.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-42">Page 42</a></em></dt><dd><p>
|
|
For example, here are some examples of how references
|
|
and mailbox names might be interpreted on a UNIX-based
|
|
server:
|
|
</p><p>
|
|
</p><pre> Reference Mailbox Name Interpretation
|
|
------------ ------------ --------------
|
|
~smith/Mail/ foo.* ~smith/Mail/foo.*
|
|
archive/ % archive/%
|
|
#news. comp.mail.* #news.comp.mail.*
|
|
~smith/Mail/ /usr/doc/foo /usr/doc/foo
|
|
archive/ ~fred/Mail/* ~fred/Mail/*
|
|
</pre>
|
|
<p>
|
|
The first three examples demonstrate interpretations in
|
|
the context of the reference argument. Note that
|
|
"~smith/Mail" <strong>SHOULD NOT</strong> be transformed into something
|
|
like "/u2/users/smith/Mail", or it would be impossible
|
|
for the client to determine that the interpretation was
|
|
in the context of the reference.
|
|
</p><p>
|
|
The character "*" is a wildcard, and matches zero or more
|
|
characters at this position. The character "%" is similar to "*",
|
|
but it does not match a hierarchy delimiter. If the "%" wildcard
|
|
is the last character of a mailbox name argument, matching levels
|
|
of hierarchy are also returned. If these levels of hierarchy are
|
|
not also selectable mailboxes, they are returned with the
|
|
\Noselect mailbox name attribute (see the description of the LIST
|
|
response for more details).
|
|
</p><p>
|
|
Server implementations are permitted to "hide" otherwise
|
|
accessible mailboxes from the wildcard characters, by preventing
|
|
certain characters or names from matching a wildcard in certain
|
|
situations. For example, a UNIX-based server might restrict the
|
|
interpretation of "*" so that an initial "/" character does not
|
|
match.
|
|
</p><p>
|
|
The special name INBOX is included in the output from LIST, if
|
|
INBOX is supported by this server for this user and if the
|
|
uppercase string "INBOX" matches the interpreted reference and
|
|
mailbox name arguments with wildcards as described above. The
|
|
criteria for omitting INBOX is whether SELECT INBOX will return
|
|
failure; it is not relevant whether the user's real INBOX resides
|
|
on this or some other server.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-43">Page 43</a></em></dt><dd><p>
|
|
</p><pre> Example: C: A101 LIST "" ""
|
|
S: * LIST (\Noselect) "/" ""
|
|
S: A101 OK LIST Completed
|
|
C: A102 LIST #news.comp.mail.misc ""
|
|
S: * LIST (\Noselect) "." #news.
|
|
S: A102 OK LIST Completed
|
|
C: A103 LIST /usr/staff/jones ""
|
|
S: * LIST (\Noselect) "/" /
|
|
S: A103 OK LIST Completed
|
|
C: A202 LIST ~/Mail/ %
|
|
S: * LIST (\Noselect) "/" ~/Mail/foo
|
|
S: * LIST () "/" ~/Mail/meetings
|
|
S: A202 OK LIST completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.3.9">6.3.9</a> LSUB Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: reference name
|
|
<br>
|
|
mailbox name with possible wildcards
|
|
</p><p>
|
|
Responses: untagged responses: LSUB
|
|
</p><p>
|
|
</p><pre> Result: OK - lsub completed
|
|
NO - lsub failure: can't list that reference or name
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The LSUB command returns a subset of names from the set of names
|
|
that the user has declared as being "active" or "subscribed".
|
|
Zero or more untagged LSUB replies are returned. The arguments to
|
|
LSUB are in the same form as those for LIST.
|
|
</p><p>
|
|
The returned untagged LSUB response <strong>MAY</strong> contain different mailbox
|
|
flags from a LIST untagged response. If this should happen, the
|
|
flags in the untagged LIST are considered more authoritative.
|
|
</p><p>
|
|
A special situation occurs when using LSUB with the % wildcard.
|
|
Consider what happens if "foo/bar" (with a hierarchy delimiter of
|
|
"/") is subscribed but "foo" is not. A "%" wildcard to LSUB must
|
|
return foo, not foo/bar, in the LSUB response, and it <strong>MUST</strong> be
|
|
flagged with the \Noselect attribute.
|
|
</p><p>
|
|
The server <strong>MUST NOT</strong> unilaterally remove an existing mailbox name
|
|
from the subscription list even if a mailbox by that name no
|
|
longer exists.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-44">Page 44</a></em></dt><dd><p>
|
|
</p><pre> Example: C: A002 LSUB "#news." "comp.mail.*"
|
|
S: * LSUB () "." #news.comp.mail.mime
|
|
S: * LSUB () "." #news.comp.mail.misc
|
|
S: A002 OK LSUB completed
|
|
C: A003 LSUB "#news." "comp.%"
|
|
S: * LSUB (\NoSelect) "." #news.comp.mail
|
|
S: A003 OK LSUB completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.3.10">6.3.10</a> STATUS Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: mailbox name
|
|
<br>
|
|
status data item names
|
|
</p><p>
|
|
Responses: untagged responses: STATUS
|
|
</p><p>
|
|
</p><pre> Result: OK - status completed
|
|
NO - status failure: no status for that name
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The STATUS command requests the status of the indicated mailbox.
|
|
It does not change the currently selected mailbox, nor does it
|
|
affect the state of any messages in the queried mailbox (in
|
|
particular, STATUS <strong>MUST NOT</strong> cause messages to lose the \Recent
|
|
flag).
|
|
</p><p>
|
|
The STATUS command provides an alternative to opening a second
|
|
IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
|
|
query that mailbox's status without deselecting the current
|
|
mailbox in the first IMAP4rev1 connection.
|
|
</p><p>
|
|
Unlike the LIST command, the STATUS command is not guaranteed to
|
|
be fast in its response. Under certain circumstances, it can be
|
|
quite slow. In some implementations, the server is obliged to
|
|
open the mailbox read-only internally to obtain certain status
|
|
information. Also unlike the LIST command, the STATUS command
|
|
does not accept wildcards.
|
|
</p><p>
|
|
Note: The STATUS command is intended to access the
|
|
status of mailboxes other than the currently selected
|
|
mailbox. Because the STATUS command can cause the
|
|
mailbox to be opened internally, and because this
|
|
information is available by other means on the selected
|
|
mailbox, the STATUS command <strong>SHOULD NOT</strong> be used on the
|
|
currently selected mailbox.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-45">Page 45</a></em></dt><dd><p>
|
|
The STATUS command <strong>MUST NOT</strong> be used as a "check for new
|
|
messages in the selected mailbox" operation (refer to
|
|
sections 7, 7.3.1, and 7.3.2 for more information about
|
|
the proper method for new message checking).
|
|
</p><p>
|
|
Because the STATUS command is not guaranteed to be fast
|
|
in its results, clients <strong>SHOULD NOT</strong> expect to be able to
|
|
issue many consecutive STATUS commands and obtain
|
|
reasonable performance.
|
|
</p><p>
|
|
The currently defined status data items that can be requested are:
|
|
</p><p>
|
|
MESSAGES
|
|
<br>
|
|
The number of messages in the mailbox.
|
|
</p><p>
|
|
RECENT
|
|
<br>
|
|
The number of messages with the \Recent flag set.
|
|
</p><p>
|
|
UIDNEXT
|
|
<br>
|
|
The next unique identifier value of the mailbox. Refer to
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.1.1">section 2.3.1.1</a> for more information.
|
|
</p><p>
|
|
UIDVALIDITY
|
|
<br>
|
|
The unique identifier validity value of the mailbox. Refer to
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.1.1">section 2.3.1.1</a> for more information.
|
|
</p><p>
|
|
UNSEEN
|
|
<br>
|
|
The number of messages which do not have the \Seen flag set.
|
|
</p><p>
|
|
</p><pre> Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
|
|
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
|
|
S: A042 OK STATUS completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-46">Page 46</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-6.3.11">6.3.11</a> APPEND Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: mailbox name
|
|
<br>
|
|
<strong>OPTIONAL</strong> flag parenthesized list
|
|
<br>
|
|
<strong>OPTIONAL</strong> date/time string
|
|
<br>
|
|
message literal
|
|
</p><p>
|
|
Responses: no specific responses for this command
|
|
</p><p>
|
|
</p><pre> Result: OK - append completed
|
|
NO - append error: can't append to that mailbox, error
|
|
in flags or date/time or message text
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The APPEND command appends the literal argument as a new message
|
|
to the end of the specified destination mailbox. This argument
|
|
<strong>SHOULD</strong> be in the format of an [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] message. 8-bit
|
|
characters are permitted in the message. A server implementation
|
|
that is unable to preserve 8-bit data properly <strong>MUST</strong> be able to
|
|
reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
|
|
content transfer encoding.
|
|
</p><p>
|
|
Note: There <strong>MAY</strong> be exceptions, e.g., draft messages, in
|
|
which required [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header lines are omitted in
|
|
the message literal argument to APPEND. The full
|
|
implications of doing so <strong>MUST</strong> be understood and
|
|
<br>
|
|
carefully weighed.
|
|
</p><p>
|
|
If a flag parenthesized list is specified, the flags <strong>SHOULD</strong> be set
|
|
in the resulting message; otherwise, the flag list of the
|
|
resulting message is set to empty by default. In either case, the
|
|
Recent flag is also set.
|
|
</p><p>
|
|
If a date-time is specified, the internal date <strong>SHOULD</strong> be set in
|
|
the resulting message; otherwise, the internal date of the
|
|
resulting message is set to the current date and time by default.
|
|
</p><p>
|
|
If the append is unsuccessful for any reason, the mailbox <strong>MUST</strong> be
|
|
restored to its state before the APPEND attempt; no partial
|
|
appending is permitted.
|
|
</p><p>
|
|
If the destination mailbox does not exist, a server <strong>MUST</strong> return an
|
|
error, and <strong>MUST NOT</strong> automatically create the mailbox. Unless it
|
|
is certain that the destination mailbox can not be created, the
|
|
server <strong>MUST</strong> send the response code "[TRYCREATE]" as the prefix of
|
|
the text of the tagged NO response. This gives a hint to the
|
|
client that it can attempt a CREATE command and retry the APPEND
|
|
if the CREATE is successful.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-47">Page 47</a></em></dt><dd><p>
|
|
If the mailbox is currently selected, the normal new message
|
|
actions <strong>SHOULD</strong> occur. Specifically, the server <strong>SHOULD</strong> notify the
|
|
client immediately via an untagged EXISTS response. If the server
|
|
does not do so, the client <strong>MAY</strong> issue a NOOP command (or failing
|
|
that, a CHECK command) after one or more APPEND commands.
|
|
</p><p>
|
|
</p><pre> Example: C: A003 APPEND saved-messages (\Seen) {310}
|
|
S: + Ready for literal data
|
|
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
|
|
C: From: Fred Foobar <foobar@Blurdybloop.COM>
|
|
C: Subject: afternoon meeting
|
|
C: To: mooch@owatagu.siam.edu
|
|
C: Message-Id: <B27397-0100000@Blurdybloop.COM>
|
|
C: MIME-Version: 1.0
|
|
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
|
|
C:
|
|
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
|
|
C:
|
|
S: A003 OK APPEND completed
|
|
</pre>
|
|
<p>
|
|
Note: The APPEND command is not used for message delivery,
|
|
because it does not provide a mechanism to transfer [SMTP]
|
|
envelope information.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-6.4">6.4</a> Client Commands - Selected State</strong></dt><dd>
|
|
<p>
|
|
In the selected state, commands that manipulate messages in a mailbox
|
|
are permitted.
|
|
</p><p>
|
|
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
|
|
and the authenticated state commands (SELECT, EXAMINE, CREATE,
|
|
DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and
|
|
APPEND), the following commands are valid in the selected state:
|
|
CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-6.4.1">6.4.1</a> CHECK Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: none
|
|
</p><p>
|
|
Responses: no specific responses for this command
|
|
</p><p>
|
|
</p><pre> Result: OK - check completed
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The CHECK command requests a checkpoint of the currently selected
|
|
mailbox. A checkpoint refers to any implementation-dependent
|
|
housekeeping associated with the mailbox (e.g., resolving the
|
|
server's in-memory state of the mailbox with the state on its
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-48">Page 48</a></em></dt><dd><p>
|
|
disk) that is not normally executed as part of each command. A
|
|
checkpoint <strong>MAY</strong> take a non-instantaneous amount of real time to
|
|
complete. If a server implementation has no such housekeeping
|
|
considerations, CHECK is equivalent to NOOP.
|
|
</p><p>
|
|
There is no guarantee that an EXISTS untagged response will happen
|
|
as a result of CHECK. NOOP, not CHECK, <strong>SHOULD</strong> be used for new
|
|
message polling.
|
|
</p><p>
|
|
</p><pre> Example: C: FXXZ CHECK
|
|
S: FXXZ OK CHECK Completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.4.2">6.4.2</a> CLOSE Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: none
|
|
</p><p>
|
|
Responses: no specific responses for this command
|
|
</p><p>
|
|
</p><pre> Result: OK - close completed, now in authenticated state
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The CLOSE command permanently removes all messages that have the
|
|
\Deleted flag set from the currently selected mailbox, and returns
|
|
to the authenticated state from the selected state. No untagged
|
|
EXPUNGE responses are sent.
|
|
</p><p>
|
|
No messages are removed, and no error is given, if the mailbox is
|
|
selected by an EXAMINE command or is otherwise selected read-only.
|
|
</p><p>
|
|
Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
|
|
command <strong>MAY</strong> be issued without previously issuing a CLOSE command.
|
|
The SELECT, EXAMINE, and LOGOUT commands implicitly close the
|
|
currently selected mailbox without doing an expunge. However,
|
|
when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
|
|
sequence is considerably faster than an EXPUNGE-LOGOUT or
|
|
EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
|
|
client would probably ignore) are sent.
|
|
</p><p>
|
|
</p><pre> Example: C: A341 CLOSE
|
|
S: A341 OK CLOSE completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-49">Page 49</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-6.4.3">6.4.3</a> EXPUNGE Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: none
|
|
</p><p>
|
|
Responses: untagged responses: EXPUNGE
|
|
</p><p>
|
|
</p><pre> Result: OK - expunge completed
|
|
NO - expunge failure: can't expunge (e.g., permission
|
|
denied)
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The EXPUNGE command permanently removes all messages that have the
|
|
\Deleted flag set from the currently selected mailbox. Before
|
|
returning an OK to the client, an untagged EXPUNGE response is
|
|
sent for each message that is removed.
|
|
</p><p>
|
|
</p><pre> Example: C: A202 EXPUNGE
|
|
S: * 3 EXPUNGE
|
|
S: * 3 EXPUNGE
|
|
S: * 5 EXPUNGE
|
|
S: * 8 EXPUNGE
|
|
S: A202 OK EXPUNGE completed
|
|
</pre>
|
|
<p>
|
|
Note: In this example, messages 3, 4, 7, and 11 had the
|
|
\Deleted flag set. See the description of the EXPUNGE
|
|
response for further explanation.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-6.4.4">6.4.4</a> SEARCH Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: <strong>OPTIONAL</strong> [CHARSET] specification
|
|
<br>
|
|
searching criteria (one or more)
|
|
</p><p>
|
|
Responses: <strong>REQUIRED</strong> untagged response: SEARCH
|
|
</p><p>
|
|
</p><pre> Result: OK - search completed
|
|
NO - search error: can't search that [CHARSET] or
|
|
criteria
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The SEARCH command searches the mailbox for messages that match
|
|
the given searching criteria. Searching criteria consist of one
|
|
or more search keys. The untagged SEARCH response from the server
|
|
contains a listing of message sequence numbers corresponding to
|
|
those messages that match the searching criteria.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-50">Page 50</a></em></dt><dd><p>
|
|
When multiple keys are specified, the result is the intersection
|
|
(AND function) of all the messages that match those keys. For
|
|
example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
|
|
to all deleted messages from Smith that were placed in the mailbox
|
|
since February 1, 1994. A search key can also be a parenthesized
|
|
list of one or more search keys (e.g., for use with the OR and NOT
|
|
keys).
|
|
</p><p>
|
|
Server implementations <strong>MAY</strong> exclude [MIME-IMB] body parts with
|
|
terminal content media types other than TEXT and MESSAGE from
|
|
consideration in SEARCH matching.
|
|
</p><p>
|
|
The <strong>OPTIONAL</strong> [CHARSET] specification consists of the word
|
|
"CHARSET" followed by a registered [CHARSET]. It indicates the
|
|
[CHARSET] of the strings that appear in the search criteria.
|
|
[MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
|
|
[<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>]/[MIME-IMB] headers, <strong>MUST</strong> be decoded before comparing
|
|
text in a [CHARSET] other than US-ASCII. US-ASCII <strong>MUST</strong> be
|
|
supported; other [CHARSET]s <strong>MAY</strong> be supported.
|
|
</p><p>
|
|
If the server does not support the specified [CHARSET], it <strong>MUST</strong>
|
|
return a tagged NO response (not a BAD). This response <strong>SHOULD</strong>
|
|
contain the BADCHARSET response code, which <strong>MAY</strong> list the
|
|
[CHARSET]s supported by the server.
|
|
</p><p>
|
|
In all search keys that use strings, a message matches the key if
|
|
the string is a substring of the field. The matching is
|
|
case-insensitive.
|
|
</p><p>
|
|
The defined search keys are as follows. Refer to the Formal
|
|
Syntax section for the precise syntactic definitions of the
|
|
arguments.
|
|
</p><p>
|
|
</p><pre> <sequence set>
|
|
Messages with message sequence numbers corresponding to the
|
|
specified message sequence number set.
|
|
</pre>
|
|
<p>
|
|
ALL
|
|
<br>
|
|
All messages in the mailbox; the default initial key for
|
|
ANDing.
|
|
</p><p>
|
|
ANSWERED
|
|
<br>
|
|
Messages with the \Answered flag set.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-51">Page 51</a></em></dt><dd><p>
|
|
BCC <string>
|
|
<br>
|
|
Messages that contain the specified string in the envelope
|
|
structure's BCC field.
|
|
</p><p>
|
|
BEFORE <date>
|
|
<br>
|
|
Messages whose internal date (disregarding time and timezone)
|
|
is earlier than the specified date.
|
|
</p><p>
|
|
BODY <string>
|
|
<br>
|
|
Messages that contain the specified string in the body of the
|
|
message.
|
|
</p><p>
|
|
CC <string>
|
|
<br>
|
|
Messages that contain the specified string in the envelope
|
|
structure's CC field.
|
|
</p><p>
|
|
DELETED
|
|
<br>
|
|
Messages with the \Deleted flag set.
|
|
</p><p>
|
|
DRAFT
|
|
<br>
|
|
Messages with the \Draft flag set.
|
|
</p><p>
|
|
FLAGGED
|
|
<br>
|
|
Messages with the \Flagged flag set.
|
|
</p><p>
|
|
FROM <string>
|
|
<br>
|
|
Messages that contain the specified string in the envelope
|
|
structure's FROM field.
|
|
</p><p>
|
|
HEADER <field-name> <string>
|
|
<br>
|
|
Messages that have a header with the specified field-name (as
|
|
defined in [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>]) and that contains the specified string
|
|
in the text of the header (what comes after the colon). If the
|
|
string to search is zero-length, this matches all messages that
|
|
have a header line with the specified field-name regardless of
|
|
the contents.
|
|
</p><p>
|
|
KEYWORD <flag>
|
|
<br>
|
|
Messages with the specified keyword flag set.
|
|
</p><p>
|
|
LARGER <n>
|
|
<br>
|
|
Messages with an [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] size larger than the specified
|
|
number of octets.
|
|
</p><p>
|
|
NEW
|
|
<br>
|
|
Messages that have the \Recent flag set but not the \Seen flag.
|
|
This is functionally equivalent to "(RECENT UNSEEN)".
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-52">Page 52</a></em></dt><dd><p>
|
|
NOT <search-key>
|
|
<br>
|
|
Messages that do not match the specified search key.
|
|
</p><p>
|
|
OLD
|
|
<br>
|
|
Messages that do not have the \Recent flag set. This is
|
|
functionally equivalent to "NOT RECENT" (as opposed to "NOT
|
|
NEW").
|
|
</p><p>
|
|
ON <date>
|
|
<br>
|
|
Messages whose internal date (disregarding time and timezone)
|
|
is within the specified date.
|
|
</p><p>
|
|
OR <search-key1> <search-key2>
|
|
<br>
|
|
Messages that match either search key.
|
|
</p><p>
|
|
RECENT
|
|
<br>
|
|
Messages that have the \Recent flag set.
|
|
</p><p>
|
|
SEEN
|
|
<br>
|
|
Messages that have the \Seen flag set.
|
|
</p><p>
|
|
SENTBEFORE <date>
|
|
<br>
|
|
Messages whose [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] Date: header (disregarding time and
|
|
timezone) is earlier than the specified date.
|
|
</p><p>
|
|
SENTON <date>
|
|
<br>
|
|
Messages whose [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] Date: header (disregarding time and
|
|
timezone) is within the specified date.
|
|
</p><p>
|
|
SENTSINCE <date>
|
|
<br>
|
|
Messages whose [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] Date: header (disregarding time and
|
|
timezone) is within or later than the specified date.
|
|
</p><p>
|
|
SINCE <date>
|
|
<br>
|
|
Messages whose internal date (disregarding time and timezone)
|
|
is within or later than the specified date.
|
|
</p><p>
|
|
SMALLER <n>
|
|
<br>
|
|
Messages with an [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] size smaller than the specified
|
|
number of octets.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-53">Page 53</a></em></dt><dd><p>
|
|
SUBJECT <string>
|
|
<br>
|
|
Messages that contain the specified string in the envelope
|
|
structure's SUBJECT field.
|
|
</p><p>
|
|
TEXT <string>
|
|
<br>
|
|
Messages that contain the specified string in the header or
|
|
body of the message.
|
|
</p><p>
|
|
TO <string>
|
|
<br>
|
|
Messages that contain the specified string in the envelope
|
|
structure's TO field.
|
|
</p><p>
|
|
UID <sequence set>
|
|
<br>
|
|
Messages with unique identifiers corresponding to the specified
|
|
unique identifier set. Sequence set ranges are permitted.
|
|
</p><p>
|
|
UNANSWERED
|
|
<br>
|
|
Messages that do not have the \Answered flag set.
|
|
</p><p>
|
|
UNDELETED
|
|
<br>
|
|
Messages that do not have the \Deleted flag set.
|
|
</p><p>
|
|
UNDRAFT
|
|
<br>
|
|
Messages that do not have the \Draft flag set.
|
|
</p><p>
|
|
UNFLAGGED
|
|
<br>
|
|
Messages that do not have the \Flagged flag set.
|
|
</p><p>
|
|
UNKEYWORD <flag>
|
|
<br>
|
|
Messages that do not have the specified keyword flag set.
|
|
</p><p>
|
|
UNSEEN
|
|
<br>
|
|
Messages that do not have the \Seen flag set.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-54">Page 54</a></em></dt><dd><p>
|
|
</p><pre> Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
|
|
S: * SEARCH 2 84 882
|
|
S: A282 OK SEARCH completed
|
|
C: A283 SEARCH TEXT "string not in mailbox"
|
|
S: * SEARCH
|
|
S: A283 OK SEARCH completed
|
|
C: A284 SEARCH CHARSET UTF-8 TEXT {6}
|
|
C: XXXXXX
|
|
S: * SEARCH 43
|
|
S: A284 OK SEARCH completed
|
|
</pre>
|
|
<p>
|
|
Note: Since this document is restricted to 7-bit ASCII
|
|
text, it is not possible to show actual UTF-8 data. The
|
|
"XXXXXX" is a placeholder for what would be 6 octets of
|
|
8-bit data in an actual transaction.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-6.4.5">6.4.5</a> FETCH Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: sequence set
|
|
<br>
|
|
message data item names or macro
|
|
</p><p>
|
|
Responses: untagged responses: FETCH
|
|
</p><p>
|
|
</p><pre> Result: OK - fetch completed
|
|
NO - fetch error: can't fetch that data
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The FETCH command retrieves data associated with a message in the
|
|
mailbox. The data items to be fetched can be either a single atom
|
|
or a parenthesized list.
|
|
</p><p>
|
|
Most data items, identified in the formal syntax under the
|
|
msg-att-static rule, are static and <strong>MUST NOT</strong> change for any
|
|
particular message. Other data items, identified in the formal
|
|
syntax under the msg-att-dynamic rule, <strong>MAY</strong> change, either as a
|
|
result of a STORE command or due to external events.
|
|
</p><p>
|
|
For example, if a client receives an ENVELOPE for a
|
|
message when it already knows the envelope, it can
|
|
safely ignore the newly transmitted envelope.
|
|
</p><p>
|
|
There are three macros which specify commonly-used sets of data
|
|
items, and can be used instead of data items. A macro must be
|
|
used by itself, and not in conjunction with other macros or data
|
|
items.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-55">Page 55</a></em></dt><dd><p>
|
|
ALL
|
|
<br>
|
|
Macro equivalent to: (FLAGS INTERNALDATE <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.SIZE ENVELOPE)
|
|
</p><p>
|
|
FAST
|
|
<br>
|
|
Macro equivalent to: (FLAGS INTERNALDATE <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.SIZE)
|
|
</p><p>
|
|
FULL
|
|
<br>
|
|
Macro equivalent to: (FLAGS INTERNALDATE <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.SIZE ENVELOPE
|
|
BODY)
|
|
</p><p>
|
|
The currently defined data items that can be fetched are:
|
|
</p><p>
|
|
BODY
|
|
<br>
|
|
Non-extensible form of BODYSTRUCTURE.
|
|
</p><p>
|
|
BODY[<section>]<<partial>>
|
|
<br>
|
|
The text of a particular body section. The section
|
|
specification is a set of zero or more part specifiers
|
|
delimited by periods. A part specifier is either a part number
|
|
or one of the following: HEADER, HEADER.FIELDS,
|
|
<br>
|
|
HEADER.FIELDS.NOT, MIME, and TEXT. An empty section
|
|
specification refers to the entire message, including the
|
|
header.
|
|
</p><p>
|
|
Every message has at least one part number. Non-[MIME-IMB]
|
|
messages, and non-multipart [MIME-IMB] messages with no
|
|
encapsulated message, only have a part 1.
|
|
</p><p>
|
|
Multipart messages are assigned consecutive part numbers, as
|
|
they occur in the message. If a particular part is of type
|
|
message or multipart, its parts <strong>MUST</strong> be indicated by a period
|
|
followed by the part number within that nested multipart part.
|
|
</p><p>
|
|
A part of type MESSAGE/<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a> also has nested part numbers,
|
|
referring to parts of the MESSAGE part's body.
|
|
</p><p>
|
|
The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
|
|
specifiers can be the sole part specifier or can be prefixed by
|
|
one or more numeric part specifiers, provided that the numeric
|
|
part specifier refers to a part of type MESSAGE/<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>. The
|
|
MIME part specifier <strong>MUST</strong> be prefixed by one or more numeric
|
|
part specifiers.
|
|
</p><p>
|
|
The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
|
|
specifiers refer to the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header of the message or of
|
|
an encapsulated [MIME-IMT] MESSAGE/<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a> message.
|
|
<br>
|
|
HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of
|
|
field-name (as defined in [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>]) names, and return a
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-56">Page 56</a></em></dt><dd><p>
|
|
subset of the header. The subset returned by HEADER.FIELDS
|
|
contains only those header fields with a field-name that
|
|
matches one of the names in the list; similarly, the subset
|
|
returned by HEADER.FIELDS.NOT contains only the header fields
|
|
with a non-matching field-name. The field-matching is
|
|
case-insensitive but otherwise exact. Subsetting does not
|
|
exclude the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] delimiting blank line between the header
|
|
and the body; the blank line is included in all header fetches,
|
|
except in the case of a message which has no body and no blank
|
|
line.
|
|
</p><p>
|
|
The MIME part specifier refers to the [MIME-IMB] header for
|
|
this part.
|
|
</p><p>
|
|
The TEXT part specifier refers to the text body of the message,
|
|
omitting the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header.
|
|
</p><p>
|
|
Here is an example of a complex message with some of its
|
|
part specifiers:
|
|
</p><p>
|
|
</p><pre> HEADER ([RFC-2822] header of the message)
|
|
TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
|
|
1 TEXT/PLAIN
|
|
2 APPLICATION/OCTET-STREAM
|
|
3 MESSAGE/RFC822
|
|
3.HEADER ([RFC-2822] header of the message)
|
|
3.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
|
|
3.1 TEXT/PLAIN
|
|
3.2 APPLICATION/OCTET-STREAM
|
|
4 MULTIPART/MIXED
|
|
4.1 IMAGE/GIF
|
|
4.1.MIME ([MIME-IMB] header for the IMAGE/GIF)
|
|
4.2 MESSAGE/RFC822
|
|
4.2.HEADER ([<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header of the message)
|
|
4.2.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
|
|
4.2.1 TEXT/PLAIN
|
|
4.2.2 MULTIPART/ALTERNATIVE
|
|
4.2.2.1 TEXT/PLAIN
|
|
4.2.2.2 TEXT/RICHTEXT
|
|
</pre>
|
|
<p>
|
|
It is possible to fetch a substring of the designated text.
|
|
This is done by appending an open angle bracket ("<"), the
|
|
octet position of the first desired octet, a period, the
|
|
maximum number of octets desired, and a close angle bracket
|
|
(">") to the part specifier. If the starting octet is beyond
|
|
the end of the text, an empty string is returned.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-57">Page 57</a></em></dt><dd><p>
|
|
Any partial fetch that attempts to read beyond the end of the
|
|
text is truncated as appropriate. A partial fetch that starts
|
|
at octet 0 is returned as a partial fetch, even if this
|
|
truncation happened.
|
|
</p><p>
|
|
Note: This means that BODY[]<0.2048> of a 1500-octet message
|
|
will return BODY[]<0> with a literal of size 1500, not
|
|
BODY[].
|
|
</p><p>
|
|
Note: A substring fetch of a HEADER.FIELDS or
|
|
<br>
|
|
HEADER.FIELDS.NOT part specifier is calculated after
|
|
subsetting the header.
|
|
</p><p>
|
|
The \Seen flag is implicitly set; if this causes the flags to
|
|
change, they <strong>SHOULD</strong> be included as part of the FETCH responses.
|
|
</p><p>
|
|
BODY.PEEK[<section>]<<partial>>
|
|
<br>
|
|
An alternate form of BODY[<section>] that does not implicitly
|
|
set the \Seen flag.
|
|
</p><p>
|
|
BODYSTRUCTURE
|
|
<br>
|
|
The [MIME-IMB] body structure of the message. This is computed
|
|
by the server by parsing the [MIME-IMB] header fields in the
|
|
[<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header and [MIME-IMB] headers.
|
|
</p><p>
|
|
ENVELOPE
|
|
<br>
|
|
The envelope structure of the message. This is computed by the
|
|
server by parsing the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header into the component
|
|
parts, defaulting various fields as necessary.
|
|
</p><p>
|
|
FLAGS
|
|
<br>
|
|
The flags that are set for this message.
|
|
</p><p>
|
|
INTERNALDATE
|
|
<br>
|
|
The internal date of the message.
|
|
</p><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>
|
|
<br>
|
|
Functionally equivalent to BODY[], differing in the syntax of
|
|
the resulting untagged FETCH data (<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a> is returned).
|
|
</p><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.HEADER
|
|
<br>
|
|
Functionally equivalent to BODY.PEEK[HEADER], differing in the
|
|
syntax of the resulting untagged FETCH data (<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.HEADER is
|
|
returned).
|
|
</p><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.SIZE
|
|
<br>
|
|
The [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] size of the message.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-58">Page 58</a></em></dt><dd><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.TEXT
|
|
<br>
|
|
Functionally equivalent to BODY[TEXT], differing in the syntax
|
|
of the resulting untagged FETCH data (<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.TEXT is returned).
|
|
</p><p>
|
|
UID
|
|
<br>
|
|
The unique identifier for the message.
|
|
</p><p>
|
|
</p><pre> Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
|
|
S: * 2 FETCH ....
|
|
S: * 3 FETCH ....
|
|
S: * 4 FETCH ....
|
|
S: A654 OK FETCH completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.4.6">6.4.6</a> STORE Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: sequence set
|
|
<br>
|
|
message data item name
|
|
<br>
|
|
value for message data item
|
|
</p><p>
|
|
Responses: untagged responses: FETCH
|
|
</p><p>
|
|
</p><pre> Result: OK - store completed
|
|
NO - store error: can't store that data
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The STORE command alters data associated with a message in the
|
|
mailbox. Normally, STORE will return the updated value of the
|
|
data with an untagged FETCH response. A suffix of ".SILENT" in
|
|
the data item name prevents the untagged FETCH, and the server
|
|
<strong>SHOULD</strong> assume that the client has determined the updated value
|
|
itself or does not care about the updated value.
|
|
</p><p>
|
|
Note: Regardless of whether or not the ".SILENT" suffix
|
|
was used, the server <strong>SHOULD</strong> send an untagged FETCH
|
|
response if a change to a message's flags from an
|
|
external source is observed. The intent is that the
|
|
status of the flags is determinate without a race
|
|
condition.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-59">Page 59</a></em></dt><dd><p>
|
|
The currently defined data items that can be stored are:
|
|
</p><p>
|
|
FLAGS <flag list>
|
|
<br>
|
|
Replace the flags for the message (other than \Recent) with the
|
|
argument. The new value of the flags is returned as if a FETCH
|
|
of those flags was done.
|
|
</p><p>
|
|
FLAGS.SILENT <flag list>
|
|
<br>
|
|
Equivalent to FLAGS, but without returning a new value.
|
|
</p><p>
|
|
</p><pre> +FLAGS <flag list>
|
|
Add the argument to the flags for the message. The new value
|
|
of the flags is returned as if a FETCH of those flags was done.
|
|
|
|
+FLAGS.SILENT <flag list>
|
|
Equivalent to +FLAGS, but without returning a new value.
|
|
|
|
-FLAGS <flag list>
|
|
Remove the argument from the flags for the message. The new
|
|
value of the flags is returned as if a FETCH of those flags was
|
|
done.
|
|
|
|
-FLAGS.SILENT <flag list>
|
|
Equivalent to -FLAGS, but without returning a new value.
|
|
|
|
Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
|
|
S: * 2 FETCH (FLAGS (\Deleted \Seen))
|
|
S: * 3 FETCH (FLAGS (\Deleted))
|
|
S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
|
|
S: A003 OK STORE completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.4.7">6.4.7</a> COPY Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: sequence set
|
|
<br>
|
|
mailbox name
|
|
</p><p>
|
|
Responses: no specific responses for this command
|
|
</p><p>
|
|
</p><pre> Result: OK - copy completed
|
|
NO - copy error: can't copy those messages or to that
|
|
name
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-60">Page 60</a></em></dt><dd><p>
|
|
The COPY command copies the specified message(s) to the end of the
|
|
specified destination mailbox. The flags and internal date of the
|
|
message(s) <strong>SHOULD</strong> be preserved, and the Recent flag <strong>SHOULD</strong> be set,
|
|
in the copy.
|
|
</p><p>
|
|
If the destination mailbox does not exist, a server <strong>SHOULD</strong> return
|
|
an error. It <strong>SHOULD NOT</strong> automatically create the mailbox. Unless
|
|
it is certain that the destination mailbox can not be created, the
|
|
server <strong>MUST</strong> send the response code "[TRYCREATE]" as the prefix of
|
|
the text of the tagged NO response. This gives a hint to the
|
|
client that it can attempt a CREATE command and retry the COPY if
|
|
the CREATE is successful.
|
|
</p><p>
|
|
If the COPY command is unsuccessful for any reason, server
|
|
implementations <strong>MUST</strong> restore the destination mailbox to its state
|
|
before the COPY attempt.
|
|
</p><p>
|
|
</p><pre> Example: C: A003 COPY 2:4 MEETING
|
|
S: A003 OK COPY completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.4.8">6.4.8</a> UID Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: command name
|
|
<br>
|
|
command arguments
|
|
</p><p>
|
|
Responses: untagged responses: FETCH, SEARCH
|
|
</p><p>
|
|
</p><pre> Result: OK - UID command completed
|
|
NO - UID command error
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
The UID command has two forms. In the first form, it takes as its
|
|
arguments a COPY, FETCH, or STORE command with arguments
|
|
appropriate for the associated command. However, the numbers in
|
|
the sequence set argument are unique identifiers instead of
|
|
message sequence numbers. Sequence set ranges are permitted, but
|
|
there is no guarantee that unique identifiers will be contiguous.
|
|
</p><p>
|
|
A non-existent unique identifier is ignored without any error
|
|
message generated. Thus, it is possible for a UID FETCH command
|
|
to return an OK without any data or a UID COPY or UID STORE to
|
|
return an OK without performing any operations.
|
|
</p><p>
|
|
In the second form, the UID command takes a SEARCH command with
|
|
SEARCH command arguments. The interpretation of the arguments is
|
|
the same as with SEARCH; however, the numbers returned in a SEARCH
|
|
response for a UID SEARCH command are unique identifiers instead
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-61">Page 61</a></em></dt><dd><p>
|
|
of message sequence numbers. For example, the command UID SEARCH
|
|
1:100 UID 443:557 returns the unique identifiers corresponding to
|
|
the intersection of two sequence sets, the message sequence number
|
|
range 1:100 and the UID range 443:557.
|
|
</p><p>
|
|
Note: in the above example, the UID range 443:557
|
|
appears. The same comment about a non-existent unique
|
|
identifier being ignored without any error message also
|
|
applies here. Hence, even if neither UID 443 or 557
|
|
exist, this range is valid and would include an existing
|
|
UID 495.
|
|
</p><p>
|
|
Also note that a UID range of 559:* always includes the
|
|
UID of the last message in the mailbox, even if 559 is
|
|
higher than any assigned UID value. This is because the
|
|
contents of a range are independent of the order of the
|
|
range endpoints. Thus, any UID range with * as one of
|
|
the endpoints indicates at least one message (the
|
|
message with the highest numbered UID), unless the
|
|
mailbox is empty.
|
|
</p><p>
|
|
The number after the "*" in an untagged FETCH response is always a
|
|
message sequence number, not a unique identifier, even for a UID
|
|
command response. However, server implementations <strong>MUST</strong> implicitly
|
|
include the UID message data item as part of any FETCH response
|
|
caused by a UID command, regardless of whether a UID was specified
|
|
as a message data item to the FETCH.
|
|
</p><p>
|
|
Note: The rule about including the UID message data item as part
|
|
of a FETCH response primarily applies to the UID FETCH and UID
|
|
STORE commands, including a UID FETCH command that does not
|
|
include UID as a message data item. Although it is unlikely that
|
|
the other UID commands will cause an untagged FETCH, this rule
|
|
applies to these commands as well.
|
|
</p><p>
|
|
</p><pre> Example: C: A999 UID FETCH 4827313:4828442 FLAGS
|
|
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
|
|
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
|
|
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
|
|
S: A999 OK UID FETCH completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-62">Page 62</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-6.5">6.5</a> Client Commands - Experimental/Expansion</strong></dt><dd>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-6.5.1">6.5.1</a> X<atom> Command</strong></dt><dd>
|
|
<p>
|
|
Arguments: implementation defined
|
|
</p><p>
|
|
Responses: implementation defined
|
|
</p><p>
|
|
</p><pre> Result: OK - command completed
|
|
NO - failure
|
|
BAD - command unknown or arguments invalid
|
|
</pre>
|
|
<p>
|
|
Any command prefixed with an X is an experimental command.
|
|
Commands which are not part of this specification, a standard or
|
|
standards-track revision of this specification, or an
|
|
<br>
|
|
IESG-approved experimental protocol, <strong>MUST</strong> use the X prefix.
|
|
</p><p>
|
|
Any added untagged responses issued by an experimental command
|
|
<strong>MUST</strong> also be prefixed with an X. Server implementations <strong>MUST NOT</strong>
|
|
send any such untagged responses, unless the client requested it
|
|
by issuing the associated experimental command.
|
|
</p><p>
|
|
</p><pre> Example: C: a441 CAPABILITY
|
|
S: * CAPABILITY IMAP4rev1 XPIG-LATIN
|
|
S: a441 OK CAPABILITY completed
|
|
C: A442 XPIG-LATIN
|
|
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
|
|
S: A442 OK XPIG-LATIN ompleted-cay
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7">7</a> Server Responses</strong></dt><dd>
|
|
<p>
|
|
Server responses are in three forms: status responses, server data,
|
|
and command continuation request. The information contained in a
|
|
server response, identified by "Contents:" in the response
|
|
descriptions below, is described by function, not by syntax. The
|
|
precise syntax of server responses is described in the Formal Syntax
|
|
section.
|
|
</p><p>
|
|
The client <strong>MUST</strong> be prepared to accept any response at all times.
|
|
</p><p>
|
|
Status responses can be tagged or untagged. Tagged status responses
|
|
indicate the completion result (OK, NO, or BAD status) of a client
|
|
command, and have a tag matching the command.
|
|
</p><p>
|
|
Some status responses, and all server data, are untagged. An
|
|
untagged response is indicated by the token "*" instead of a tag.
|
|
Untagged status responses indicate server greeting, or server status
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-63">Page 63</a></em></dt><dd><p>
|
|
that does not indicate the completion of a command (for example, an
|
|
impending system shutdown alert). For historical reasons, untagged
|
|
server data responses are also called "unsolicited data", although
|
|
strictly speaking, only unilateral server data is truly
|
|
<br>
|
|
"unsolicited".
|
|
</p><p>
|
|
Certain server data <strong>MUST</strong> be recorded by the client when it is
|
|
received; this is noted in the description of that data. Such data
|
|
conveys critical information which affects the interpretation of all
|
|
subsequent commands and responses (e.g., updates reflecting the
|
|
creation or destruction of messages).
|
|
</p><p>
|
|
Other server data <strong>SHOULD</strong> be recorded for later reference; if the
|
|
client does not need to record the data, or if recording the data has
|
|
no obvious purpose (e.g., a SEARCH response when no SEARCH command is
|
|
in progress), the data <strong>SHOULD</strong> be ignored.
|
|
</p><p>
|
|
An example of unilateral untagged server data occurs when the IMAP
|
|
connection is in the selected state. In the selected state, the
|
|
server checks the mailbox for new messages as part of command
|
|
execution. Normally, this is part of the execution of every command;
|
|
hence, a NOOP command suffices to check for new messages. If new
|
|
messages are found, the server sends untagged EXISTS and RECENT
|
|
responses reflecting the new size of the mailbox. Server
|
|
implementations that offer multiple simultaneous access to the same
|
|
mailbox <strong>SHOULD</strong> also send appropriate unilateral untagged FETCH and
|
|
EXPUNGE responses if another agent changes the state of any message
|
|
flags or expunges any messages.
|
|
</p><p>
|
|
Command continuation request responses use the token "+" instead of a
|
|
tag. These responses are sent by the server to indicate acceptance
|
|
of an incomplete client command and readiness for the remainder of
|
|
the command.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-7.1">7.1</a> Server Responses - Status Responses</strong></dt><dd>
|
|
<p>
|
|
Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD
|
|
can be tagged or untagged. PREAUTH and BYE are always untagged.
|
|
</p><p>
|
|
Status responses <strong>MAY</strong> include an <strong>OPTIONAL</strong> "response code". A response
|
|
code consists of data inside square brackets in the form of an atom,
|
|
possibly followed by a space and arguments. The response code
|
|
contains additional information or status codes for client software
|
|
beyond the OK/NO/BAD condition, and are defined when there is a
|
|
specific action that a client can take based upon the additional
|
|
information.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-64">Page 64</a></em></dt><dd><p>
|
|
The currently defined response codes are:
|
|
</p><p>
|
|
ALERT
|
|
</p><p>
|
|
The human-readable text contains a special alert that <strong>MUST</strong> be
|
|
presented to the user in a fashion that calls the user's
|
|
attention to the message.
|
|
</p><p>
|
|
BADCHARSET
|
|
</p><p>
|
|
Optionally followed by a parenthesized list of charsets. A
|
|
SEARCH failed because the given charset is not supported by
|
|
this implementation. If the optional list of charsets is
|
|
given, this lists the charsets that are supported by this
|
|
implementation.
|
|
</p><p>
|
|
CAPABILITY
|
|
</p><p>
|
|
Followed by a list of capabilities. This can appear in the
|
|
initial OK or PREAUTH response to transmit an initial
|
|
capabilities list. This makes it unnecessary for a client to
|
|
send a separate CAPABILITY command if it recognizes this
|
|
response.
|
|
</p><p>
|
|
PARSE
|
|
</p><p>
|
|
The human-readable text represents an error in parsing the
|
|
[<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header or [MIME-IMB] headers of a message in the
|
|
mailbox.
|
|
</p><p>
|
|
PERMANENTFLAGS
|
|
</p><p>
|
|
Followed by a parenthesized list of flags, indicates which of
|
|
the known flags the client can change permanently. Any flags
|
|
that are in the FLAGS untagged response, but not the
|
|
PERMANENTFLAGS list, can not be set permanently. If the client
|
|
attempts to STORE a flag that is not in the PERMANENTFLAGS
|
|
list, the server will either ignore the change or store the
|
|
state change for the remainder of the current session only.
|
|
The PERMANENTFLAGS list can also include the special flag \*,
|
|
which indicates that it is possible to create new keywords by
|
|
attempting to store those flags in the mailbox.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-65">Page 65</a></em></dt><dd><p>
|
|
READ-ONLY
|
|
</p><p>
|
|
The mailbox is selected read-only, or its access while selected
|
|
has changed from read-write to read-only.
|
|
</p><p>
|
|
READ-WRITE
|
|
</p><p>
|
|
The mailbox is selected read-write, or its access while
|
|
selected has changed from read-only to read-write.
|
|
</p><p>
|
|
TRYCREATE
|
|
</p><p>
|
|
An APPEND or COPY attempt is failing because the target mailbox
|
|
does not exist (as opposed to some other reason). This is a
|
|
hint to the client that the operation can succeed if the
|
|
mailbox is first created by the CREATE command.
|
|
</p><p>
|
|
UIDNEXT
|
|
</p><p>
|
|
Followed by a decimal number, indicates the next unique
|
|
identifier value. Refer to <a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.1.1">section 2.3.1.1</a> for more
|
|
information.
|
|
</p><p>
|
|
UIDVALIDITY
|
|
</p><p>
|
|
Followed by a decimal number, indicates the unique identifier
|
|
validity value. Refer to <a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-2.3.1.1">section 2.3.1.1</a> for more information.
|
|
</p><p>
|
|
UNSEEN
|
|
</p><p>
|
|
Followed by a decimal number, indicates the number of the first
|
|
message without the \Seen flag set.
|
|
</p><p>
|
|
Additional response codes defined by particular client or server
|
|
implementations <strong>SHOULD</strong> be prefixed with an "X" until they are
|
|
added to a revision of this protocol. Client implementations
|
|
<strong>SHOULD</strong> ignore response codes that they do not recognize.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-7.1.1">7.1.1</a> OK Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: <strong>OPTIONAL</strong> response code
|
|
human-readable text
|
|
</pre>
|
|
<p>
|
|
The OK response indicates an information message from the server.
|
|
When tagged, it indicates successful completion of the associated
|
|
command. The human-readable text <strong>MAY</strong> be presented to the user as
|
|
an information message. The untagged form indicates an
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-66">Page 66</a></em></dt><dd><p>
|
|
information-only message; the nature of the information <strong>MAY</strong> be
|
|
indicated by a response code.
|
|
</p><p>
|
|
The untagged form is also used as one of three possible greetings
|
|
at connection startup. It indicates that the connection is not
|
|
yet authenticated and that a LOGIN command is needed.
|
|
</p><p>
|
|
</p><pre> Example: S: * OK IMAP4rev1 server ready
|
|
C: A001 LOGIN fred blurdybloop
|
|
S: * OK [ALERT] System shutdown in 10 minutes
|
|
S: A001 OK LOGIN Completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.1.2">7.1.2</a> NO Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: <strong>OPTIONAL</strong> response code
|
|
human-readable text
|
|
</pre>
|
|
<p>
|
|
The NO response indicates an operational error message from the
|
|
server. When tagged, it indicates unsuccessful completion of the
|
|
associated command. The untagged form indicates a warning; the
|
|
command can still complete successfully. The human-readable text
|
|
describes the condition.
|
|
</p><p>
|
|
</p><pre> Example: C: A222 COPY 1:2 owatagusiam
|
|
S: * NO Disk is 98% full, please delete unnecessary data
|
|
S: A222 OK COPY completed
|
|
C: A223 COPY 3:200 blurdybloop
|
|
S: * NO Disk is 98% full, please delete unnecessary data
|
|
S: * NO Disk is 99% full, please delete unnecessary data
|
|
S: A223 NO COPY failed: disk is full
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.1.3">7.1.3</a> BAD Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: <strong>OPTIONAL</strong> response code
|
|
human-readable text
|
|
</pre>
|
|
<p>
|
|
The BAD response indicates an error message from the server. When
|
|
tagged, it reports a protocol-level error in the client's command;
|
|
the tag indicates the command that caused the error. The untagged
|
|
form indicates a protocol-level error for which the associated
|
|
command can not be determined; it can also indicate an internal
|
|
server failure. The human-readable text describes the condition.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-67">Page 67</a></em></dt><dd><p>
|
|
</p><pre> Example: C: ...very long command line...
|
|
S: * BAD Command line too long
|
|
C: ...empty line...
|
|
S: * BAD Empty command line
|
|
C: A443 EXPUNGE
|
|
S: * BAD Disk crash, attempting salvage to a new disk!
|
|
S: * OK Salvage successful, no data lost
|
|
S: A443 OK Expunge completed
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.1.4">7.1.4</a> PREAUTH Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: <strong>OPTIONAL</strong> response code
|
|
human-readable text
|
|
</pre>
|
|
<p>
|
|
The PREAUTH response is always untagged, and is one of three
|
|
possible greetings at connection startup. It indicates that the
|
|
connection has already been authenticated by external means; thus
|
|
no LOGIN command is needed.
|
|
</p><p>
|
|
</p><pre> Example: S: * PREAUTH IMAP4rev1 server logged in as Smith
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.1.5">7.1.5</a> BYE Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: <strong>OPTIONAL</strong> response code
|
|
human-readable text
|
|
</pre>
|
|
<p>
|
|
The BYE response is always untagged, and indicates that the server
|
|
is about to close the connection. The human-readable text <strong>MAY</strong> be
|
|
displayed to the user in a status report by the client. The BYE
|
|
response is sent under one of four conditions:
|
|
</p><p>
|
|
1) as part of a normal logout sequence. The server will close
|
|
the connection after sending the tagged OK response to the
|
|
LOGOUT command.
|
|
</p><p>
|
|
2) as a panic shutdown announcement. The server closes the
|
|
connection immediately.
|
|
</p><p>
|
|
3) as an announcement of an inactivity autologout. The server
|
|
closes the connection immediately.
|
|
</p><p>
|
|
4) as one of three possible greetings at connection startup,
|
|
indicating that the server is not willing to accept a
|
|
connection from this client. The server closes the
|
|
connection immediately.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-68">Page 68</a></em></dt><dd><p>
|
|
The difference between a BYE that occurs as part of a normal
|
|
LOGOUT sequence (the first case) and a BYE that occurs because of
|
|
a failure (the other three cases) is that the connection closes
|
|
immediately in the failure case. In all cases the client <strong>SHOULD</strong>
|
|
continue to read response data from the server until the
|
|
connection is closed; this will ensure that any pending untagged
|
|
or completion responses are read and processed.
|
|
</p><p>
|
|
</p><pre> Example: S: * BYE Autologout; idle for too long
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.2">7.2</a> Server Responses - Server and Mailbox Status</strong></dt><dd>
|
|
<p>
|
|
These responses are always untagged. This is how server and mailbox
|
|
status data are transmitted from the server to the client. Many of
|
|
these responses typically result from a command with the same name.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-7.2.1">7.2.1</a> CAPABILITY Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: capability listing
|
|
</pre>
|
|
<p>
|
|
The CAPABILITY response occurs as a result of a CAPABILITY
|
|
command. The capability listing contains a space-separated
|
|
listing of capability names that the server supports. The
|
|
capability listing <strong>MUST</strong> include the atom "IMAP4rev1".
|
|
</p><p>
|
|
In addition, client and server implementations <strong>MUST</strong> implement the
|
|
STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
|
|
capabilities. See the Security Considerations section for
|
|
important information.
|
|
</p><p>
|
|
A capability name which begins with "AUTH=" indicates that the
|
|
server supports that particular authentication mechanism.
|
|
</p><p>
|
|
The LOGINDISABLED capability indicates that the LOGIN command is
|
|
disabled, and that the server will respond with a tagged NO
|
|
response to any attempt to use the LOGIN command even if the user
|
|
name and password are valid. An IMAP client <strong>MUST NOT</strong> issue the
|
|
LOGIN command if the server advertises the LOGINDISABLED
|
|
capability.
|
|
</p><p>
|
|
Other capability names indicate that the server supports an
|
|
extension, revision, or amendment to the IMAP4rev1 protocol.
|
|
Server responses <strong>MUST</strong> conform to this document until the client
|
|
issues a command that uses the associated capability.
|
|
</p><p>
|
|
Capability names <strong>MUST</strong> either begin with "X" or be standard or
|
|
standards-track IMAP4rev1 extensions, revisions, or amendments
|
|
registered with IANA. A server <strong>MUST NOT</strong> offer unregistered or
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-69">Page 69</a></em></dt><dd><p>
|
|
non-standard capability names, unless such names are prefixed with
|
|
an "X".
|
|
</p><p>
|
|
Client implementations <strong>SHOULD NOT</strong> require any capability name
|
|
other than "IMAP4rev1", and <strong>MUST</strong> ignore any unknown capability
|
|
names.
|
|
</p><p>
|
|
A server <strong>MAY</strong> send capabilities automatically, by using the
|
|
CAPABILITY response code in the initial PREAUTH or OK responses,
|
|
and by sending an updated CAPABILITY response code in the tagged
|
|
OK response as part of a successful authentication. It is
|
|
unnecessary for a client to send a separate CAPABILITY command if
|
|
it recognizes these automatic capabilities.
|
|
</p><p>
|
|
</p><pre> Example: S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.2.2">7.2.2</a> LIST Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: name attributes
|
|
hierarchy delimiter
|
|
name
|
|
</pre>
|
|
<p>
|
|
The LIST response occurs as a result of a LIST command. It
|
|
returns a single name that matches the LIST specification. There
|
|
can be multiple LIST responses for a single LIST command.
|
|
</p><p>
|
|
Four name attributes are defined:
|
|
</p><p>
|
|
\Noinferiors
|
|
<br>
|
|
It is not possible for any child levels of hierarchy to exist
|
|
under this name; no child levels exist now and none can be
|
|
created in the future.
|
|
</p><p>
|
|
\Noselect
|
|
<br>
|
|
It is not possible to use this name as a selectable mailbox.
|
|
</p><p>
|
|
\Marked
|
|
<br>
|
|
The mailbox has been marked "interesting" by the server; the
|
|
mailbox probably contains messages that have been added since
|
|
the last time the mailbox was selected.
|
|
</p><p>
|
|
\Unmarked
|
|
<br>
|
|
The mailbox does not contain any additional messages since the
|
|
last time the mailbox was selected.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-70">Page 70</a></em></dt><dd><p>
|
|
If it is not feasible for the server to determine whether or not
|
|
the mailbox is "interesting", or if the name is a \Noselect name,
|
|
the server <strong>SHOULD NOT</strong> send either \Marked or \Unmarked.
|
|
</p><p>
|
|
The hierarchy delimiter is a character used to delimit levels of
|
|
hierarchy in a mailbox name. A client can use it to create child
|
|
mailboxes, and to search higher or lower levels of naming
|
|
hierarchy. All children of a top-level hierarchy node <strong>MUST</strong> use
|
|
the same separator character. A NIL hierarchy delimiter means
|
|
that no hierarchy exists; the name is a "flat" name.
|
|
</p><p>
|
|
The name represents an unambiguous left-to-right hierarchy, and
|
|
<strong>MUST</strong> be valid for use as a reference in LIST and LSUB commands.
|
|
Unless \Noselect is indicated, the name <strong>MUST</strong> also be valid as an
|
|
argument for commands, such as SELECT, that accept mailbox names.
|
|
</p><p>
|
|
</p><pre> Example: S: * LIST (\Noselect) "/" ~/Mail/foo
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.2.3">7.2.3</a> LSUB Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: name attributes
|
|
hierarchy delimiter
|
|
name
|
|
</pre>
|
|
<p>
|
|
The LSUB response occurs as a result of an LSUB command. It
|
|
returns a single name that matches the LSUB specification. There
|
|
can be multiple LSUB responses for a single LSUB command. The
|
|
data is identical in format to the LIST response.
|
|
</p><p>
|
|
</p><pre> Example: S: * LSUB () "." #news.comp.mail.misc
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.2.4">7.2.4</a> STATUS Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: name
|
|
status parenthesized list
|
|
</pre>
|
|
<p>
|
|
The STATUS response occurs as a result of an STATUS command. It
|
|
returns the mailbox name that matches the STATUS specification and
|
|
the requested mailbox status information.
|
|
</p><p>
|
|
</p><pre> Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-71">Page 71</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-7.2.5">7.2.5</a> SEARCH Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: zero or more numbers
|
|
</pre>
|
|
<p>
|
|
The SEARCH response occurs as a result of a SEARCH or UID SEARCH
|
|
command. The number(s) refer to those messages that match the
|
|
search criteria. For SEARCH, these are message sequence numbers;
|
|
for UID SEARCH, these are unique identifiers. Each number is
|
|
delimited by a space.
|
|
</p><p>
|
|
</p><pre> Example: S: * SEARCH 2 3 6
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.2.6">7.2.6</a> FLAGS Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: flag parenthesized list
|
|
</pre>
|
|
<p>
|
|
The FLAGS response occurs as a result of a SELECT or EXAMINE
|
|
command. The flag parenthesized list identifies the flags (at a
|
|
minimum, the system-defined flags) that are applicable for this
|
|
mailbox. Flags other than the system flags can also exist,
|
|
depending on server implementation.
|
|
</p><p>
|
|
The update from the FLAGS response <strong>MUST</strong> be recorded by the client.
|
|
</p><p>
|
|
</p><pre> Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.3">7.3</a> Server Responses - Mailbox Size</strong></dt><dd>
|
|
<p>
|
|
These responses are always untagged. This is how changes in the size
|
|
of the mailbox are transmitted from the server to the client.
|
|
Immediately following the "*" token is a number that represents a
|
|
message count.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-7.3.1">7.3.1</a> EXISTS Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: none
|
|
</pre>
|
|
<p>
|
|
The EXISTS response reports the number of messages in the mailbox.
|
|
This response occurs as a result of a SELECT or EXAMINE command,
|
|
and if the size of the mailbox changes (e.g., new messages).
|
|
</p><p>
|
|
The update from the EXISTS response <strong>MUST</strong> be recorded by the
|
|
client.
|
|
</p><p>
|
|
</p><pre> Example: S: * 23 EXISTS
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-72">Page 72</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-7.3.2">7.3.2</a> RECENT Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: none
|
|
</pre>
|
|
<p>
|
|
The RECENT response reports the number of messages with the
|
|
\Recent flag set. This response occurs as a result of a SELECT or
|
|
EXAMINE command, and if the size of the mailbox changes (e.g., new
|
|
messages).
|
|
</p><p>
|
|
Note: It is not guaranteed that the message sequence
|
|
numbers of recent messages will be a contiguous range of
|
|
the highest n messages in the mailbox (where n is the
|
|
value reported by the RECENT response). Examples of
|
|
situations in which this is not the case are: multiple
|
|
clients having the same mailbox open (the first session
|
|
to be notified will see it as recent, others will
|
|
probably see it as non-recent), and when the mailbox is
|
|
re-ordered by a non-IMAP agent.
|
|
</p><p>
|
|
The only reliable way to identify recent messages is to
|
|
look at message flags to see which have the \Recent flag
|
|
set, or to do a SEARCH RECENT.
|
|
</p><p>
|
|
The update from the RECENT response <strong>MUST</strong> be recorded by the
|
|
client.
|
|
</p><p>
|
|
</p><pre> Example: S: * 5 RECENT
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.4">7.4</a> Server Responses - Message Status</strong></dt><dd>
|
|
<p>
|
|
These responses are always untagged. This is how message data are
|
|
transmitted from the server to the client, often as a result of a
|
|
command with the same name. Immediately following the "*" token is a
|
|
number that represents a message sequence number.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-7.4.1">7.4.1</a> EXPUNGE Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: none
|
|
</pre>
|
|
<p>
|
|
The EXPUNGE response reports that the specified message sequence
|
|
number has been permanently removed from the mailbox. The message
|
|
sequence number for each successive message in the mailbox is
|
|
immediately decremented by 1, and this decrement is reflected in
|
|
message sequence numbers in subsequent responses (including other
|
|
untagged EXPUNGE responses).
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-73">Page 73</a></em></dt><dd><p>
|
|
The EXPUNGE response also decrements the number of messages in the
|
|
mailbox; it is not necessary to send an EXISTS response with the
|
|
new value.
|
|
</p><p>
|
|
As a result of the immediate decrement rule, message sequence
|
|
numbers that appear in a set of successive EXPUNGE responses
|
|
depend upon whether the messages are removed starting from lower
|
|
numbers to higher numbers, or from higher numbers to lower
|
|
numbers. For example, if the last 5 messages in a 9-message
|
|
mailbox are expunged, a "lower to higher" server will send five
|
|
untagged EXPUNGE responses for message sequence number 5, whereas
|
|
a "higher to lower server" will send successive untagged EXPUNGE
|
|
responses for message sequence numbers 9, 8, 7, 6, and 5.
|
|
</p><p>
|
|
An EXPUNGE response <strong>MUST NOT</strong> be sent when no command is in
|
|
progress, nor while responding to a FETCH, STORE, or SEARCH
|
|
command. This rule is necessary to prevent a loss of
|
|
<br>
|
|
synchronization of message sequence numbers between client and
|
|
server. A command is not "in progress" until the complete command
|
|
has been received; in particular, a command is not "in progress"
|
|
during the negotiation of command continuation.
|
|
</p><p>
|
|
Note: UID FETCH, UID STORE, and UID SEARCH are different
|
|
commands from FETCH, STORE, and SEARCH. An EXPUNGE
|
|
response <strong>MAY</strong> be sent during a UID command.
|
|
</p><p>
|
|
The update from the EXPUNGE response <strong>MUST</strong> be recorded by the
|
|
client.
|
|
</p><p>
|
|
</p><pre> Example: S: * 44 EXPUNGE
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.4.2">7.4.2</a> FETCH Response</strong></dt><dd>
|
|
<p>
|
|
</p><pre> Contents: message data
|
|
</pre>
|
|
<p>
|
|
The FETCH response returns data about a message to the client.
|
|
The data are pairs of data item names and their values in
|
|
parentheses. This response occurs as the result of a FETCH or
|
|
STORE command, as well as by unilateral server decision (e.g.,
|
|
flag updates).
|
|
</p><p>
|
|
The current data items are:
|
|
</p><p>
|
|
BODY
|
|
<br>
|
|
A form of BODYSTRUCTURE without extension data.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-74">Page 74</a></em></dt><dd><p>
|
|
BODY[<section>]<<origin octet>>
|
|
<br>
|
|
A string expressing the body contents of the specified section.
|
|
The string <strong>SHOULD</strong> be interpreted by the client according to the
|
|
content transfer encoding, body type, and subtype.
|
|
</p><p>
|
|
If the origin octet is specified, this string is a substring of
|
|
the entire body contents, starting at that origin octet. This
|
|
means that BODY[]<0> <strong>MAY</strong> be truncated, but BODY[] is NEVER
|
|
truncated.
|
|
</p><p>
|
|
Note: The origin octet facility <strong>MUST NOT</strong> be used by a server
|
|
in a FETCH response unless the client specifically requested
|
|
it by means of a FETCH of a BODY[<section>]<<partial>> data
|
|
item.
|
|
</p><p>
|
|
8-bit textual data is permitted if a [CHARSET] identifier is
|
|
part of the body parameter parenthesized list for this section.
|
|
Note that headers (part specifiers HEADER or MIME, or the
|
|
header portion of a MESSAGE/<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a> part), <strong>MUST</strong> be 7-bit; 8-bit
|
|
characters are not permitted in headers. Note also that the
|
|
[<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] delimiting blank line between the header and the
|
|
body is not affected by header line subsetting; the blank line
|
|
is always included as part of header data, except in the case
|
|
of a message which has no body and no blank line.
|
|
</p><p>
|
|
Non-textual data such as binary data <strong>MUST</strong> be transfer encoded
|
|
into a textual form, such as BASE64, prior to being sent to the
|
|
client. To derive the original binary data, the client <strong>MUST</strong>
|
|
decode the transfer encoded string.
|
|
</p><p>
|
|
BODYSTRUCTURE
|
|
<br>
|
|
A parenthesized list that describes the [MIME-IMB] body
|
|
structure of a message. This is computed by the server by
|
|
parsing the [MIME-IMB] header fields, defaulting various fields
|
|
as necessary.
|
|
</p><p>
|
|
For example, a simple text message of 48 lines and 2279 octets
|
|
can have a body structure of: ("TEXT" "PLAIN" ("CHARSET"
|
|
"US-ASCII") NIL NIL "7BIT" 2279 48)
|
|
</p><p>
|
|
Multiple parts are indicated by parenthesis nesting. Instead
|
|
of a body type as the first element of the parenthesized list,
|
|
there is a sequence of one or more nested body structures. The
|
|
second element of the parenthesized list is the multipart
|
|
subtype (mixed, digest, parallel, alternative, etc.).
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-75">Page 75</a></em></dt><dd><p>
|
|
For example, a two part message consisting of a text and a
|
|
BASE64-encoded text attachment can have a body structure of:
|
|
(("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
|
|
23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
|
|
"<960723163407.20117h@cac.washington.edu>" "Compiler diff"
|
|
"BASE64" 4554 73) "MIXED")
|
|
</p><p>
|
|
Extension data follows the multipart subtype. Extension data
|
|
is never returned with the BODY fetch, but can be returned with
|
|
a BODYSTRUCTURE fetch. Extension data, if present, <strong>MUST</strong> be in
|
|
the defined order. The extension data of a multipart body part
|
|
are in the following order:
|
|
</p><p>
|
|
body parameter parenthesized list
|
|
<br>
|
|
A parenthesized list of attribute/value pairs [e.g., ("foo"
|
|
"bar" "baz" "rag") where "bar" is the value of "foo", and
|
|
"rag" is the value of "baz"] as defined in [MIME-IMB].
|
|
</p><p>
|
|
body disposition
|
|
<br>
|
|
A parenthesized list, consisting of a disposition type
|
|
string, followed by a parenthesized list of disposition
|
|
attribute/value pairs as defined in [DISPOSITION].
|
|
</p><p>
|
|
body language
|
|
<br>
|
|
A string or parenthesized list giving the body language
|
|
value as defined in [LANGUAGE-TAGS].
|
|
</p><p>
|
|
body location
|
|
<br>
|
|
A string list giving the body content URI as defined in
|
|
[LOCATION].
|
|
</p><p>
|
|
Any following extension data are not yet defined in this
|
|
version of the protocol. Such extension data can consist of
|
|
zero or more NILs, strings, numbers, or potentially nested
|
|
parenthesized lists of such data. Client implementations that
|
|
do a BODYSTRUCTURE fetch <strong>MUST</strong> be prepared to accept such
|
|
extension data. Server implementations <strong>MUST NOT</strong> send such
|
|
extension data until it has been defined by a revision of this
|
|
protocol.
|
|
</p><p>
|
|
The basic fields of a non-multipart body part are in the
|
|
following order:
|
|
</p><p>
|
|
body type
|
|
<br>
|
|
A string giving the content media type name as defined in
|
|
[MIME-IMB].
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-76">Page 76</a></em></dt><dd><p>
|
|
body subtype
|
|
<br>
|
|
A string giving the content subtype name as defined in
|
|
[MIME-IMB].
|
|
</p><p>
|
|
body parameter parenthesized list
|
|
<br>
|
|
A parenthesized list of attribute/value pairs [e.g., ("foo"
|
|
"bar" "baz" "rag") where "bar" is the value of "foo" and
|
|
"rag" is the value of "baz"] as defined in [MIME-IMB].
|
|
</p><p>
|
|
body id
|
|
<br>
|
|
A string giving the content id as defined in [MIME-IMB].
|
|
</p><p>
|
|
body description
|
|
<br>
|
|
A string giving the content description as defined in
|
|
[MIME-IMB].
|
|
</p><p>
|
|
body encoding
|
|
<br>
|
|
A string giving the content transfer encoding as defined in
|
|
[MIME-IMB].
|
|
</p><p>
|
|
body size
|
|
<br>
|
|
A number giving the size of the body in octets. Note that
|
|
this size is the size in its transfer encoding and not the
|
|
resulting size after any decoding.
|
|
</p><p>
|
|
A body type of type MESSAGE and subtype <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a> contains,
|
|
immediately after the basic fields, the envelope structure,
|
|
body structure, and size in text lines of the encapsulated
|
|
message.
|
|
</p><p>
|
|
A body type of type TEXT contains, immediately after the basic
|
|
fields, the size of the body in text lines. Note that this
|
|
size is the size in its content transfer encoding and not the
|
|
resulting size after any decoding.
|
|
</p><p>
|
|
Extension data follows the basic fields and the type-specific
|
|
fields listed above. Extension data is never returned with the
|
|
BODY fetch, but can be returned with a BODYSTRUCTURE fetch.
|
|
Extension data, if present, <strong>MUST</strong> be in the defined order.
|
|
</p><p>
|
|
The extension data of a non-multipart body part are in the
|
|
following order:
|
|
</p><p>
|
|
body MD5
|
|
<br>
|
|
A string giving the body MD5 value as defined in [MD5].
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-77">Page 77</a></em></dt><dd><p>
|
|
body disposition
|
|
<br>
|
|
A parenthesized list with the same content and function as
|
|
the body disposition for a multipart body part.
|
|
</p><p>
|
|
body language
|
|
<br>
|
|
A string or parenthesized list giving the body language
|
|
value as defined in [LANGUAGE-TAGS].
|
|
</p><p>
|
|
body location
|
|
<br>
|
|
A string list giving the body content URI as defined in
|
|
[LOCATION].
|
|
</p><p>
|
|
Any following extension data are not yet defined in this
|
|
version of the protocol, and would be as described above under
|
|
multipart extension data.
|
|
</p><p>
|
|
ENVELOPE
|
|
<br>
|
|
A parenthesized list that describes the envelope structure of a
|
|
message. This is computed by the server by parsing the
|
|
[<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header into the component parts, defaulting various
|
|
fields as necessary.
|
|
</p><p>
|
|
The fields of the envelope structure are in the following
|
|
order: date, subject, from, sender, reply-to, to, cc, bcc,
|
|
in-reply-to, and message-id. The date, subject, in-reply-to,
|
|
and message-id fields are strings. The from, sender, reply-to,
|
|
to, cc, and bcc fields are parenthesized lists of address
|
|
structures.
|
|
</p><p>
|
|
An address structure is a parenthesized list that describes an
|
|
electronic mail address. The fields of an address structure
|
|
are in the following order: personal name, [SMTP]
|
|
<br>
|
|
at-domain-list (source route), mailbox name, and host name.
|
|
</p><p>
|
|
[<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] group syntax is indicated by a special form of
|
|
address structure in which the host name field is NIL. If the
|
|
mailbox name field is also NIL, this is an end of group marker
|
|
(semi-colon in <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC 822</a> syntax). If the mailbox name field is
|
|
non-NIL, this is a start of group marker, and the mailbox name
|
|
field holds the group name phrase.
|
|
</p><p>
|
|
If the Date, Subject, In-Reply-To, and Message-ID header lines
|
|
are absent in the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header, the corresponding member
|
|
of the envelope is NIL; if these header lines are present but
|
|
empty the corresponding member of the envelope is the empty
|
|
string.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-78">Page 78</a></em></dt><dd><p>
|
|
Note: some servers may return a NIL envelope member in the
|
|
"present but empty" case. Clients <strong>SHOULD</strong> treat NIL and
|
|
empty string as identical.
|
|
</p><p>
|
|
Note: [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] requires that all messages have a valid
|
|
Date header. Therefore, the date member in the envelope can
|
|
not be NIL or the empty string.
|
|
</p><p>
|
|
Note: [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] requires that the In-Reply-To and
|
|
Message-ID headers, if present, have non-empty content.
|
|
Therefore, the in-reply-to and message-id members in the
|
|
envelope can not be the empty string.
|
|
</p><p>
|
|
If the From, To, cc, and bcc header lines are absent in the
|
|
[<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header, or are present but empty, the corresponding
|
|
member of the envelope is NIL.
|
|
</p><p>
|
|
If the Sender or Reply-To lines are absent in the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>]
|
|
header, or are present but empty, the server sets the
|
|
corresponding member of the envelope to be the same value as
|
|
the from member (the client is not expected to know to do
|
|
this).
|
|
</p><p>
|
|
Note: [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] requires that all messages have a valid
|
|
From header. Therefore, the from, sender, and reply-to
|
|
members in the envelope can not be NIL.
|
|
</p><p>
|
|
FLAGS
|
|
<br>
|
|
A parenthesized list of flags that are set for this message.
|
|
</p><p>
|
|
INTERNALDATE
|
|
<br>
|
|
A string representing the internal date of the message.
|
|
</p><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>
|
|
<br>
|
|
Equivalent to BODY[].
|
|
</p><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.HEADER
|
|
<br>
|
|
Equivalent to BODY[HEADER]. Note that this did not result in
|
|
\Seen being set, because <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.HEADER response data occurs as
|
|
a result of a FETCH of <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.HEADER. BODY[HEADER] response
|
|
data occurs as a result of a FETCH of BODY[HEADER] (which sets
|
|
\Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
|
|
</p><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.SIZE
|
|
<br>
|
|
A number expressing the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] size of the message.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-79">Page 79</a></em></dt><dd><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.TEXT
|
|
<br>
|
|
Equivalent to BODY[TEXT].
|
|
</p><p>
|
|
UID
|
|
<br>
|
|
A number expressing the unique identifier of the message.
|
|
</p><p>
|
|
</p><pre> Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-7.5">7.5</a> Server Responses - Command Continuation Request</strong></dt><dd>
|
|
<p>
|
|
The command continuation request response is indicated by a "+" token
|
|
instead of a tag. This form of response indicates that the server is
|
|
ready to accept the continuation of a command from the client. The
|
|
remainder of this response is a line of text.
|
|
</p><p>
|
|
This response is used in the AUTHENTICATE command to transmit server
|
|
data to the client, and request additional client data. This
|
|
response is also used if an argument to any command is a literal.
|
|
</p><p>
|
|
The client is not permitted to send the octets of the literal unless
|
|
the server indicates that it is expected. This permits the server to
|
|
process commands and reject errors on a line-by-line basis. The
|
|
remainder of the command, including the CRLF that terminates a
|
|
command, follows the octets of the literal. If there are any
|
|
additional command arguments, the literal octets are followed by a
|
|
space and those arguments.
|
|
</p><p>
|
|
</p><pre> Example: C: A001 LOGIN {11}
|
|
S: + Ready for additional command text
|
|
C: FRED FOOBAR {7}
|
|
S: + Ready for additional command text
|
|
C: fat man
|
|
S: A001 OK LOGIN completed
|
|
C: A044 BLURDYBLOOP {102856}
|
|
S: A044 BAD No such command as "BLURDYBLOOP"
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-80">Page 80</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-8">8</a> Sample IMAP4rev1 connection</strong></dt><dd>
|
|
<p>
|
|
The following is a transcript of an IMAP4rev1 connection. A long
|
|
line in this sample is broken for editorial clarity.
|
|
</p><p>
|
|
</p></dd><dt>S: * OK IMAP4rev1 Service Ready</dt><dd>
|
|
</dd><dt>C: a001 login mrc secret</dt><dd>
|
|
</dd><dt>S: a001 OK LOGIN completed</dt><dd>
|
|
</dd><dt>C: a002 select inbox</dt><dd>
|
|
</dd><dt>S: * 18 EXISTS</dt><dd>
|
|
</dd><dt>S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)</dt><dd>
|
|
</dd><dt>S: * 2 RECENT</dt><dd>
|
|
</dd><dt>S: * OK [UNSEEN 17] Message 17 is the first unseen message</dt><dd>
|
|
</dd><dt>S: * OK [UIDVALIDITY 3857529045] UIDs valid</dt><dd>
|
|
</dd><dt>S: a002 OK [READ-WRITE] SELECT completed</dt><dd>
|
|
</dd><dt>C: a003 fetch 12 full</dt><dd>
|
|
</dd><dt>S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"</dt><dd>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
|
|
"IMAP4rev1 WG mtg summary and minutes"
|
|
<br>
|
|
(("Terry Gray" NIL "gray" "cac.washington.edu"))
|
|
<br>
|
|
(("Terry Gray" NIL "gray" "cac.washington.edu"))
|
|
<br>
|
|
(("Terry Gray" NIL "gray" "cac.washington.edu"))
|
|
<br>
|
|
((NIL NIL "imap" "cac.washington.edu"))
|
|
<br>
|
|
((NIL NIL "minutes" "CNRI.Reston.VA.US")
|
|
<br>
|
|
("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
|
|
<br>
|
|
"<B27397-0100000@cac.washington.edu>")
|
|
<br>
|
|
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
|
|
92))
|
|
<br>
|
|
</dd><dt>S: a003 OK FETCH completed</dt><dd>
|
|
</dd><dt>C: a004 fetch 12 body[header]</dt><dd>
|
|
</dd><dt>S: * 12 FETCH (BODY[HEADER] {342}</dt><dd>
|
|
</dd><dt>S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)</dt><dd>
|
|
</dd><dt>S: From: Terry Gray <gray@cac.washington.edu></dt><dd>
|
|
</dd><dt>S: Subject: IMAP4rev1 WG mtg summary and minutes</dt><dd>
|
|
</dd><dt>S: To: imap@cac.washington.edu</dt><dd>
|
|
</dd><dt>S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU></dt><dd>
|
|
</dd><dt>S: Message-Id: <B27397-0100000@cac.washington.edu></dt><dd>
|
|
</dd><dt>S: MIME-Version: 1.0</dt><dd>
|
|
</dd><dt>S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII</dt><dd>
|
|
</dd><dt>S:</dt><dd>
|
|
</dd><dt>S: )</dt><dd>
|
|
</dd><dt>S: a004 OK FETCH completed</dt><dd>
|
|
</dd><dt>C: a005 store 12 +flags \deleted</dt><dd>
|
|
</dd><dt>S: * 12 FETCH (FLAGS (\Seen \Deleted))</dt><dd>
|
|
</dd><dt>S: a005 OK +FLAGS completed</dt><dd>
|
|
</dd><dt>C: a006 logout</dt><dd>
|
|
</dd><dt>S: * BYE IMAP4rev1 server terminating connection</dt><dd>
|
|
</dd><dt>S: a006 OK LOGOUT completed</dt><dd>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-81">Page 81</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-9">9</a> Formal Syntax</strong></dt><dd>
|
|
<p>
|
|
The following syntax specification uses the Augmented Backus-Naur
|
|
Form (ABNF) notation as specified in [ABNF].
|
|
</p><p>
|
|
In the case of alternative or optional rules in which a later rule
|
|
overlaps an earlier rule, the rule which is listed earlier <strong>MUST</strong> take
|
|
priority. For example, "\Seen" when parsed as a flag is the \Seen
|
|
flag name and not a flag-extension, even though "\Seen" can be parsed
|
|
as a flag-extension. Some, but not all, instances of this rule are
|
|
noted below.
|
|
</p><p>
|
|
Note: [ABNF] rules <strong>MUST</strong> be followed strictly; in
|
|
<br>
|
|
particular:
|
|
</p><p>
|
|
(1) 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 <strong>MUST</strong> accept these strings in a
|
|
case-insensitive fashion.
|
|
</p><p>
|
|
(2) In all cases, SP refers to exactly one space. It is
|
|
NOT permitted to substitute TAB, insert additional spaces,
|
|
or otherwise treat SP as being equivalent to LWSP.
|
|
</p><p>
|
|
(3) The ASCII NUL character, %x00, <strong>MUST NOT</strong> be used at any
|
|
time.
|
|
</p><p>
|
|
</p><pre>address = "(" addr-name SP addr-adl SP addr-mailbox SP
|
|
addr-host ")"
|
|
|
|
addr-adl = nstring
|
|
; Holds route from [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] route-addr if
|
|
; non-NIL
|
|
|
|
addr-host = nstring
|
|
; NIL indicates [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] group syntax.
|
|
; Otherwise, holds [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] domain name
|
|
|
|
addr-mailbox = nstring
|
|
; NIL indicates end of [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] group; if
|
|
; non-NIL and addr-host is NIL, holds
|
|
; [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] group name.
|
|
; Otherwise, holds [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] local-part
|
|
; after removing [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] quoting
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-82">Page 82</a></em></dt><dd><p>
|
|
</p><pre>addr-name = nstring
|
|
; If non-NIL, holds phrase from [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>]
|
|
; mailbox after removing [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] quoting
|
|
|
|
append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP
|
|
literal
|
|
|
|
astring = 1*ASTRING-CHAR / string
|
|
|
|
ASTRING-CHAR = ATOM-CHAR / resp-specials
|
|
|
|
atom = 1*ATOM-CHAR
|
|
|
|
ATOM-CHAR = <any CHAR except atom-specials>
|
|
|
|
atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
|
|
quoted-specials / resp-specials
|
|
|
|
authenticate = "AUTHENTICATE" SP auth-type *(CRLF base64)
|
|
|
|
auth-type = atom
|
|
; Defined by [SASL]
|
|
|
|
base64 = *(4base64-char) [base64-terminal]
|
|
|
|
base64-char = ALPHA / DIGIT / "+" / "/"
|
|
; Case-sensitive
|
|
|
|
base64-terminal = (2base64-char "==") / (3base64-char "=")
|
|
|
|
body = "(" (body-type-1part / body-type-mpart) ")"
|
|
|
|
body-extension = nstring / number /
|
|
"(" body-extension *(SP body-extension) ")"
|
|
; Future expansion. Client implementations
|
|
; <strong>MUST</strong> accept body-extension fields. Server
|
|
; implementations <strong>MUST NOT</strong> generate
|
|
; body-extension fields except as defined by
|
|
; future standard or standards-track
|
|
; revisions of this specification.
|
|
|
|
body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
|
|
[SP body-fld-loc *(SP body-extension)]]]
|
|
; <strong>MUST NOT</strong> be returned on non-extensible
|
|
; "BODY" fetch
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-83">Page 83</a></em></dt><dd><p>
|
|
</p><pre>body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang
|
|
[SP body-fld-loc *(SP body-extension)]]]
|
|
; <strong>MUST NOT</strong> be returned on non-extensible
|
|
; "BODY" fetch
|
|
|
|
body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP
|
|
body-fld-enc SP body-fld-octets
|
|
|
|
body-fld-desc = nstring
|
|
|
|
body-fld-dsp = "(" string SP body-fld-param ")" / nil
|
|
|
|
body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
|
|
"QUOTED-PRINTABLE") DQUOTE) / string
|
|
|
|
body-fld-id = nstring
|
|
|
|
body-fld-lang = nstring / "(" string *(SP string) ")"
|
|
|
|
body-fld-loc = nstring
|
|
|
|
body-fld-lines = number
|
|
|
|
body-fld-md5 = nstring
|
|
|
|
body-fld-octets = number
|
|
|
|
body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
|
|
|
|
body-type-1part = (body-type-basic / body-type-msg / body-type-text)
|
|
[SP body-ext-1part]
|
|
|
|
body-type-basic = media-basic SP body-fields
|
|
; MESSAGE subtype <strong>MUST NOT</strong> be "<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>"
|
|
|
|
body-type-mpart = 1*body SP media-subtype
|
|
[SP body-ext-mpart]
|
|
|
|
body-type-msg = media-message SP body-fields SP envelope
|
|
SP body SP body-fld-lines
|
|
|
|
body-type-text = media-text SP body-fields SP body-fld-lines
|
|
|
|
capability = ("AUTH=" auth-type) / atom
|
|
; New capabilities <strong>MUST</strong> begin with "X" or be
|
|
; registered with IANA as standard or
|
|
; standards-track
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-84">Page 84</a></em></dt><dd><p>
|
|
</p><pre>capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
|
|
*(SP capability)
|
|
; Servers <strong>MUST</strong> implement the STARTTLS, AUTH=PLAIN,
|
|
; and LOGINDISABLED capabilities
|
|
; Servers which offer <a href="http://www.apps.ietf.org/rfc/rfc1730.html">RFC 1730</a> compatibility <strong>MUST</strong>
|
|
; list "IMAP4" as the first capability.
|
|
|
|
CHAR8 = %x01-ff
|
|
; any OCTET except NUL, %x00
|
|
|
|
command = tag SP (command-any / command-auth / command-nonauth /
|
|
command-select) CRLF
|
|
; Modal based on state
|
|
|
|
command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
|
|
; Valid in all states
|
|
|
|
command-auth = append / create / delete / examine / list / lsub /
|
|
rename / select / status / subscribe / unsubscribe
|
|
; Valid only in Authenticated or Selected state
|
|
|
|
command-nonauth = login / authenticate / "STARTTLS"
|
|
; Valid only when in Not Authenticated state
|
|
|
|
command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
|
|
uid / search
|
|
; Valid only when in Selected state
|
|
|
|
continue-req = "+" SP (resp-text / base64) CRLF
|
|
|
|
copy = "COPY" SP sequence-set SP mailbox
|
|
|
|
create = "CREATE" SP mailbox
|
|
; Use of INBOX gives a NO error
|
|
|
|
date = date-text / DQUOTE date-text DQUOTE
|
|
|
|
date-day = 1*2DIGIT
|
|
; Day of month
|
|
|
|
date-day-fixed = (SP DIGIT) / 2DIGIT
|
|
; Fixed-format version of date-day
|
|
|
|
date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
|
|
"Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
|
|
|
|
date-text = date-day "-" date-month "-" date-year
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-85">Page 85</a></em></dt><dd><p>
|
|
</p><pre>date-year = 4DIGIT
|
|
|
|
date-time = DQUOTE date-day-fixed "-" date-month "-" date-year
|
|
SP time SP zone DQUOTE
|
|
|
|
delete = "DELETE" SP mailbox
|
|
; Use of INBOX gives a NO error
|
|
|
|
digit-nz = %x31-39
|
|
; 1-9
|
|
|
|
envelope = "(" env-date SP env-subject SP env-from SP
|
|
env-sender SP env-reply-to SP env-to SP env-cc SP
|
|
env-bcc SP env-in-reply-to SP env-message-id ")"
|
|
|
|
env-bcc = "(" 1*address ")" / nil
|
|
|
|
env-cc = "(" 1*address ")" / nil
|
|
|
|
env-date = nstring
|
|
|
|
env-from = "(" 1*address ")" / nil
|
|
|
|
env-in-reply-to = nstring
|
|
|
|
env-message-id = nstring
|
|
|
|
env-reply-to = "(" 1*address ")" / nil
|
|
|
|
env-sender = "(" 1*address ")" / nil
|
|
|
|
env-subject = nstring
|
|
|
|
env-to = "(" 1*address ")" / nil
|
|
|
|
examine = "EXAMINE" SP mailbox
|
|
|
|
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
|
|
fetch-att / "(" fetch-att *(SP fetch-att) ")")
|
|
|
|
fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
|
|
"<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>" [".HEADER" / ".SIZE" / ".TEXT"] /
|
|
"BODY" ["STRUCTURE"] / "UID" /
|
|
"BODY" section ["<" number "." nz-number ">"] /
|
|
"BODY.PEEK" section ["<" number "." nz-number ">"]
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-86">Page 86</a></em></dt><dd><p>
|
|
</p><pre>flag = "\Answered" / "\Flagged" / "\Deleted" /
|
|
"\Seen" / "\Draft" / flag-keyword / flag-extension
|
|
; Does not include "\Recent"
|
|
|
|
flag-extension = "\" atom
|
|
; Future expansion. Client implementations
|
|
; <strong>MUST</strong> accept flag-extension flags. Server
|
|
; implementations <strong>MUST NOT</strong> generate
|
|
; flag-extension flags except as defined by
|
|
; future standard or standards-track
|
|
; revisions of this specification.
|
|
|
|
flag-fetch = flag / "\Recent"
|
|
|
|
flag-keyword = atom
|
|
|
|
flag-list = "(" [flag *(SP flag)] ")"
|
|
|
|
flag-perm = flag / "\*"
|
|
|
|
greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
|
|
|
|
header-fld-name = astring
|
|
|
|
header-list = "(" header-fld-name *(SP header-fld-name) ")"
|
|
|
|
list = "LIST" SP mailbox SP list-mailbox
|
|
|
|
list-mailbox = 1*list-char / string
|
|
|
|
list-char = ATOM-CHAR / list-wildcards / resp-specials
|
|
|
|
list-wildcards = "%" / "*"
|
|
|
|
literal = "{" number "}" CRLF *CHAR8
|
|
; Number represents the number of CHAR8s
|
|
|
|
login = "LOGIN" SP userid SP password
|
|
|
|
lsub = "LSUB" SP mailbox SP list-mailbox
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-87">Page 87</a></em></dt><dd><p>
|
|
</p><pre>mailbox = "INBOX" / astring
|
|
; INBOX is case-insensitive. All case variants of
|
|
; INBOX (e.g., "iNbOx") <strong>MUST</strong> be interpreted as INBOX
|
|
; not as an astring. An astring which consists of
|
|
; the case-insensitive sequence "I" "N" "B" "O" "X"
|
|
; is considered to be INBOX and not an astring.
|
|
; Refer to <a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-5.1">section 5.1</a> for further
|
|
; semantic details of mailbox names.
|
|
|
|
mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
|
|
"LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
|
|
"STATUS" SP mailbox SP "(" [status-att-list] ")" /
|
|
number SP "EXISTS" / number SP "RECENT"
|
|
|
|
mailbox-list = "(" [mbx-list-flags] ")" SP
|
|
(DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
|
|
|
|
mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
|
|
*(SP mbx-list-oflag) /
|
|
mbx-list-oflag *(SP mbx-list-oflag)
|
|
|
|
mbx-list-oflag = "\Noinferiors" / flag-extension
|
|
; Other flags; multiple possible per LIST response
|
|
|
|
mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
|
|
; Selectability flags; only one per LIST response
|
|
|
|
media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
|
|
"MESSAGE" / "VIDEO") DQUOTE) / string) SP
|
|
media-subtype
|
|
; Defined in [MIME-IMT]
|
|
|
|
media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE
|
|
; Defined in [MIME-IMT]
|
|
|
|
media-subtype = string
|
|
; Defined in [MIME-IMT]
|
|
|
|
media-text = DQUOTE "TEXT" DQUOTE SP media-subtype
|
|
; Defined in [MIME-IMT]
|
|
|
|
message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
|
|
|
|
msg-att = "(" (msg-att-dynamic / msg-att-static)
|
|
*(SP (msg-att-dynamic / msg-att-static)) ")"
|
|
|
|
msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
|
|
; <strong>MAY</strong> change for a message
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-88">Page 88</a></em></dt><dd><p>
|
|
</p><pre>msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
|
|
"<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>" [".HEADER" / ".TEXT"] SP nstring /
|
|
"<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.SIZE" SP number /
|
|
"BODY" ["STRUCTURE"] SP body /
|
|
"BODY" section ["<" number ">"] SP nstring /
|
|
"UID" SP uniqueid
|
|
; <strong>MUST NOT</strong> change for a message
|
|
|
|
nil = "NIL"
|
|
|
|
nstring = string / nil
|
|
|
|
number = 1*DIGIT
|
|
; Unsigned 32-bit integer
|
|
; (0 <= n < 4,294,967,296)
|
|
|
|
nz-number = digit-nz *DIGIT
|
|
; Non-zero unsigned 32-bit integer
|
|
; (0 < n < 4,294,967,296)
|
|
|
|
password = astring
|
|
|
|
quoted = DQUOTE *QUOTED-CHAR DQUOTE
|
|
|
|
QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
|
|
"\" quoted-specials
|
|
|
|
quoted-specials = DQUOTE / "\"
|
|
|
|
rename = "RENAME" SP mailbox SP mailbox
|
|
; Use of INBOX as a destination gives a NO error
|
|
|
|
response = *(continue-req / response-data) response-done
|
|
|
|
response-data = "*" SP (resp-cond-state / resp-cond-bye /
|
|
mailbox-data / message-data / capability-data) CRLF
|
|
|
|
response-done = response-tagged / response-fatal
|
|
|
|
response-fatal = "*" SP resp-cond-bye CRLF
|
|
; Server closes connection immediately
|
|
|
|
response-tagged = tag SP resp-cond-state CRLF
|
|
|
|
resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
|
|
; Authentication condition
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-89">Page 89</a></em></dt><dd><p>
|
|
</p><pre>resp-cond-bye = "BYE" SP resp-text
|
|
|
|
resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
|
|
; Status condition
|
|
|
|
resp-specials = "]"
|
|
|
|
resp-text = ["[" resp-text-code "]" SP] text
|
|
|
|
resp-text-code = "ALERT" /
|
|
"BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
|
|
capability-data / "PARSE" /
|
|
"PERMANENTFLAGS" SP "("
|
|
[flag-perm *(SP flag-perm)] ")" /
|
|
"READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
|
|
"UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
|
|
"UNSEEN" SP nz-number /
|
|
atom [SP 1*<any TEXT-CHAR except "]">]
|
|
|
|
search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
|
|
; CHARSET argument to <strong>MUST</strong> be registered with IANA
|
|
|
|
search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
|
|
"BEFORE" SP date / "BODY" SP astring /
|
|
"CC" SP astring / "DELETED" / "FLAGGED" /
|
|
"FROM" SP astring / "KEYWORD" SP flag-keyword /
|
|
"NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
|
|
"SINCE" SP date / "SUBJECT" SP astring /
|
|
"TEXT" SP astring / "TO" SP astring /
|
|
"UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
|
|
"UNKEYWORD" SP flag-keyword / "UNSEEN" /
|
|
; Above this line were in [IMAP2]
|
|
"DRAFT" / "HEADER" SP header-fld-name SP astring /
|
|
"LARGER" SP number / "NOT" SP search-key /
|
|
"OR" SP search-key SP search-key /
|
|
"SENTBEFORE" SP date / "SENTON" SP date /
|
|
"SENTSINCE" SP date / "SMALLER" SP number /
|
|
"UID" SP sequence-set / "UNDRAFT" / sequence-set /
|
|
"(" search-key *(SP search-key) ")"
|
|
|
|
section = "[" [section-spec] "]"
|
|
|
|
section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
|
|
"TEXT"
|
|
; top-level or MESSAGE/<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a> part
|
|
|
|
section-part = nz-number *("." nz-number)
|
|
; body part nesting
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-90">Page 90</a></em></dt><dd><p>
|
|
</p><pre>section-spec = section-msgtext / (section-part ["." section-text])
|
|
|
|
section-text = section-msgtext / "MIME"
|
|
; text other than actual body part (headers, etc.)
|
|
|
|
select = "SELECT" SP mailbox
|
|
|
|
seq-number = nz-number / "*"
|
|
; message sequence number (COPY, FETCH, STORE
|
|
; commands) or unique identifier (UID COPY,
|
|
; UID FETCH, UID STORE commands).
|
|
; * represents the largest number in use. In
|
|
; the case of message sequence numbers, it is
|
|
; the number of messages in a non-empty mailbox.
|
|
; In the case of unique identifiers, it is the
|
|
; unique identifier of the last message in the
|
|
; mailbox or, if the mailbox is empty, the
|
|
; mailbox's current UIDNEXT value.
|
|
; The server should respond with a tagged BAD
|
|
; response to a command that uses a message
|
|
; sequence number greater than the number of
|
|
; messages in the selected mailbox. This
|
|
; includes "*" if the selected mailbox is empty.
|
|
|
|
seq-range = seq-number ":" seq-number
|
|
; two seq-number values and all values between
|
|
; these two regardless of order.
|
|
; Example: 2:4 and 4:2 are equivalent and indicate
|
|
; values 2, 3, and 4.
|
|
; Example: a unique identifier sequence range of
|
|
; 3291:* includes the UID of the last message in
|
|
; the mailbox, even if that value is less than 3291.
|
|
|
|
sequence-set = (seq-number / seq-range) *("," sequence-set)
|
|
; set of seq-number values, regardless of order.
|
|
; Servers <strong>MAY</strong> coalesce overlaps and/or execute the
|
|
; sequence in any order.
|
|
; Example: a message sequence number set of
|
|
; 2,4:7,9,12:* for a mailbox with 15 messages is
|
|
; equivalent to 2,4,5,6,7,9,12,13,14,15
|
|
; Example: a message sequence number set of *:4,5:7
|
|
; for a mailbox with 10 messages is equivalent to
|
|
; 10,9,8,7,6,5,4,5,6,7 and <strong>MAY</strong> be reordered and
|
|
; overlap coalesced to be 4,5,6,7,8,9,10.
|
|
|
|
status = "STATUS" SP mailbox SP
|
|
"(" status-att *(SP status-att) ")"
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-91">Page 91</a></em></dt><dd><p>
|
|
</p><pre>status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
|
|
"UNSEEN"
|
|
|
|
status-att-list = status-att SP number *(SP status-att SP number)
|
|
|
|
store = "STORE" SP sequence-set SP store-att-flags
|
|
|
|
store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
|
|
(flag-list / (flag *(SP flag)))
|
|
|
|
string = quoted / literal
|
|
|
|
subscribe = "SUBSCRIBE" SP mailbox
|
|
|
|
tag = 1*<any ASTRING-CHAR except "+">
|
|
|
|
text = 1*TEXT-CHAR
|
|
|
|
TEXT-CHAR = <any CHAR except CR and LF>
|
|
|
|
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
|
|
; Hours minutes seconds
|
|
|
|
uid = "UID" SP (copy / fetch / search / store)
|
|
; Unique identifiers used instead of message
|
|
; sequence numbers
|
|
|
|
uniqueid = nz-number
|
|
; Strictly ascending
|
|
|
|
unsubscribe = "UNSUBSCRIBE" SP mailbox
|
|
|
|
userid = astring
|
|
|
|
x-command = "X" atom <experimental command arguments>
|
|
|
|
zone = ("+" / "-") 4DIGIT
|
|
; Signed four-digit value of hhmm representing
|
|
; hours and minutes east of Greenwich (that is,
|
|
; the amount that the given time differs from
|
|
; Universal Time). Subtracting the timezone
|
|
; from the given time will give the UT form.
|
|
; The Universal Time zone is "+0000".
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-92">Page 92</a></em></dt><dd><p>
|
|
</p></dd><dt><strong><a name="sec-10">10</a> Author's Note</strong></dt><dd>
|
|
<p>
|
|
This document is a revision or rewrite of earlier documents, and
|
|
supercedes the protocol specification in those documents: <a href="http://www.apps.ietf.org/rfc/rfc2060.html">RFC 2060</a>,
|
|
<a href="http://www.apps.ietf.org/rfc/rfc1730.html">RFC 1730</a>, unpublished IMAP2bis.TXT document, <a href="http://www.apps.ietf.org/rfc/rfc1176.html">RFC 1176</a>, and <a href="http://www.apps.ietf.org/rfc/rfc1064.html">RFC 1064</a>.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-11">11</a> Security Considerations</strong></dt><dd>
|
|
<p>
|
|
IMAP4rev1 protocol transactions, including electronic mail data, are
|
|
sent in the clear over the network unless protection from snooping is
|
|
negotiated. This can be accomplished either by the use of STARTTLS,
|
|
negotiated privacy protection in the AUTHENTICATE command, or some
|
|
other protection mechanism.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-11.1">11.1</a> STARTTLS Security Considerations</strong></dt><dd>
|
|
<p>
|
|
The specification of the STARTTLS command and LOGINDISABLED
|
|
capability in this document replaces that in [IMAP-TLS]. [IMAP-TLS]
|
|
remains normative for the PLAIN [SASL] authenticator.
|
|
</p><p>
|
|
IMAP client and server implementations <strong>MUST</strong> implement the
|
|
TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and <strong>SHOULD</strong> implement the
|
|
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is
|
|
important as it assures that any two compliant implementations can be
|
|
configured to interoperate. All other cipher suites are <strong>OPTIONAL</strong>.
|
|
Note that this is a change from section 2.1 of [IMAP-TLS].
|
|
</p><p>
|
|
During the [TLS] negotiation, the client <strong>MUST</strong> check its understanding
|
|
of the server hostname against the server's identity as presented in
|
|
the server Certificate message, in order to prevent man-in-the-middle
|
|
attacks. If the match fails, the client <strong>SHOULD</strong> either ask for
|
|
explicit user confirmation, or terminate the connection and indicate
|
|
that the server's identity is suspect. Matching is performed
|
|
according to these rules:
|
|
</p><p>
|
|
The client <strong>MUST</strong> use the server hostname it used to open the
|
|
connection as the value to compare against the server name
|
|
as expressed in the server certificate. The client <strong>MUST</strong>
|
|
NOT use any form of the server hostname derived from an
|
|
insecure remote source (e.g., insecure DNS lookup). CNAME
|
|
canonicalization is not done.
|
|
</p><p>
|
|
If a subjectAltName extension of type dNSName is present in
|
|
the certificate, it <strong>SHOULD</strong> be used as the source of the
|
|
server's identity.
|
|
</p><p>
|
|
Matching is case-insensitive.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-93">Page 93</a></em></dt><dd><p>
|
|
A "*" wildcard character <strong>MAY</strong> be used as the left-most name
|
|
component in the certificate. For example, *.example.com
|
|
would match a.example.com, foo.example.com, etc. but would
|
|
not match example.com.
|
|
</p><p>
|
|
If the certificate contains multiple names (e.g., more than
|
|
one dNSName field), then a match with any one of the fields
|
|
is considered acceptable.
|
|
</p><p>
|
|
Both the client and server <strong>MUST</strong> check the result of the STARTTLS
|
|
command and subsequent [TLS] negotiation to see whether acceptable
|
|
authentication or privacy was achieved.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-11.2">11.2</a> Other Security Considerations</strong></dt><dd>
|
|
<p>
|
|
A server error message for an AUTHENTICATE command which fails due to
|
|
invalid credentials <strong>SHOULD NOT</strong> detail why the credentials are
|
|
invalid.
|
|
</p><p>
|
|
Use of the LOGIN command sends passwords in the clear. This can be
|
|
avoided by using the AUTHENTICATE command with a [SASL] mechanism
|
|
that does not use plaintext passwords, by first negotiating
|
|
encryption via STARTTLS or some other protection mechanism.
|
|
</p><p>
|
|
A server implementation <strong>MUST</strong> implement a configuration that, at the
|
|
time of authentication, requires:
|
|
<br>
|
|
(1) The STARTTLS command has been negotiated.
|
|
<br>
|
|
OR
|
|
<br>
|
|
(2) Some other mechanism that protects the session from password
|
|
snooping has been provided.
|
|
<br>
|
|
OR
|
|
<br>
|
|
(3) The following measures are in place:
|
|
<br>
|
|
(a) The LOGINDISABLED capability is advertised, and [SASL]
|
|
mechanisms (such as PLAIN) using plaintext passwords are NOT
|
|
advertised in the CAPABILITY list.
|
|
<br>
|
|
AND
|
|
<br>
|
|
(b) The LOGIN command returns an error even if the password is
|
|
correct.
|
|
<br>
|
|
AND
|
|
<br>
|
|
(c) The AUTHENTICATE command returns an error with all [SASL]
|
|
mechanisms that use plaintext passwords, even if the password
|
|
is correct.
|
|
</p><p>
|
|
A server error message for a failing LOGIN command <strong>SHOULD NOT</strong> specify
|
|
that the user name, as opposed to the password, is invalid.
|
|
</p><p>
|
|
A server <strong>SHOULD</strong> have mechanisms in place to limit or delay failed
|
|
AUTHENTICATE/LOGIN attempts.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-94">Page 94</a></em></dt><dd><p>
|
|
Additional security considerations are discussed in the section
|
|
discussing the AUTHENTICATE and LOGIN commands.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-12">12</a> IANA Considerations</strong></dt><dd>
|
|
<p>
|
|
IMAP4 capabilities are registered by publishing a standards track or
|
|
IESG approved experimental RFC. The registry is currently located
|
|
at:
|
|
</p><p>
|
|
<a href="http://www.iana.org/assignments/imap4-capabilities">http://www.iana.org/assignments/imap4-capabilities</a>
|
|
</p><p>
|
|
As this specification revises the STARTTLS and LOGINDISABLED
|
|
extensions previously defined in [IMAP-TLS], the registry will be
|
|
updated accordingly.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-95">Page 95</a></em></dt><dd><p>
|
|
</p></dd><dt>Appendices</dt><dd>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-A">A</a> Normative References</strong></dt><dd>
|
|
<p>
|
|
The following documents contain definitions or specifications that
|
|
are necessary to understand this document properly:
|
|
</p><pre> [ABNF] Crocker, D. and P. Overell, "Augmented BNF for
|
|
Syntax Specifications: ABNF", <a href="http://www.apps.ietf.org/rfc/rfc2234.html">RFC 2234</a>,
|
|
November 1997.
|
|
|
|
[ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC
|
|
2245, November 1997.
|
|
|
|
[CHARSET] Freed, N. and J. Postel, "IANA Character Set
|
|
Registration Procedures", <a href="http://www.apps.ietf.org/rfc/rfc2978.html">RFC 2978</a>, October
|
|
2000.
|
|
|
|
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest
|
|
Authentication as a SASL Mechanism", <a href="http://www.apps.ietf.org/rfc/rfc2831.html">RFC 2831</a>,
|
|
May 2000.
|
|
|
|
[DISPOSITION] Troost, R., Dorner, S. and K. Moore,
|
|
"Communicating Presentation Information in
|
|
Internet Messages: The Content-Disposition
|
|
Header", <a href="http://www.apps.ietf.org/rfc/rfc2183.html">RFC 2183</a>, August 1997.
|
|
|
|
[IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and
|
|
ACAP", <a href="http://www.apps.ietf.org/rfc/rfc2595.html">RFC 2595</a>, June 1999.
|
|
|
|
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
|
|
Indicate Requirement Levels", BCP 14, <a href="http://www.apps.ietf.org/rfc/rfc2119.html">RFC 2119</a>,
|
|
March 1997.
|
|
|
|
[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
|
|
Languages", BCP 47, <a href="http://www.apps.ietf.org/rfc/rfc3066.html">RFC 3066</a>, January 2001.
|
|
|
|
[LOCATION] Palme, J., Hopmann, A. and N. Shelness, "MIME
|
|
Encapsulation of Aggregate Documents, such as
|
|
HTML (MHTML)", <a href="http://www.apps.ietf.org/rfc/rfc2557.html">RFC 2557</a>, March 1999.
|
|
|
|
[MD5] Myers, J. and M. Rose, "The Content-MD5 Header
|
|
Field", <a href="http://www.apps.ietf.org/rfc/rfc1864.html">RFC 1864</a>, October 1995.
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-96">Page 96</a></em></dt><dd><p>
|
|
</p><pre> [MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail
|
|
Extensions) Part Three: Message Header
|
|
Extensions for Non-ASCII Text", <a href="http://www.apps.ietf.org/rfc/rfc2047.html">RFC 2047</a>,
|
|
November 1996.
|
|
|
|
[MIME-IMB] Freed, N. and N. Borenstein, "MIME
|
|
(Multipurpose Internet Mail Extensions) Part
|
|
One: Format of Internet Message Bodies", RFC
|
|
2045, November 1996.
|
|
|
|
[MIME-IMT] Freed, N. and N. Borenstein, "MIME
|
|
(Multipurpose Internet Mail Extensions) Part
|
|
Two: Media Types", <a href="http://www.apps.ietf.org/rfc/rfc2046.html">RFC 2046</a>, November 1996.
|
|
|
|
[<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] Resnick, P., "Internet Message Format", RFC
|
|
2822, April 2001.
|
|
|
|
[SASL] Myers, J., "Simple Authentication and Security
|
|
Layer (SASL)", <a href="http://www.apps.ietf.org/rfc/rfc2222.html">RFC 2222</a>, October 1997.
|
|
|
|
[TLS] Dierks, T. and C. Allen, "The TLS Protocol
|
|
Version 1.0", <a href="http://www.apps.ietf.org/rfc/rfc2246.html">RFC 2246</a>, January 1999.
|
|
|
|
[UTF-7] Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe
|
|
Transformation Format of Unicode", <a href="http://www.apps.ietf.org/rfc/rfc2152.html">RFC 2152</a>,
|
|
May 1997.
|
|
</pre>
|
|
<p>
|
|
The following documents describe quality-of-implementation issues
|
|
that should be carefully considered when implementing this protocol:
|
|
</p><p>
|
|
[IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation
|
|
<br>
|
|
Recommendations", <a href="http://www.apps.ietf.org/rfc/rfc2683.html">RFC 2683</a>, September 1999.
|
|
</p><p>
|
|
</p><pre> [IMAP-MULTIACCESS] Gahrns, M., "IMAP4 Multi-Accessed Mailbox
|
|
Practice", <a href="http://www.apps.ietf.org/rfc/rfc2180.html">RFC 2180</a>, July 1997.
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-A.1">A.1</a> Informative References</strong></dt><dd>
|
|
<p>
|
|
The following documents describe related protocols:
|
|
</p><p>
|
|
</p><pre> [IMAP-DISC] Austein, R., "Synchronization Operations for
|
|
Disconnected IMAP4 Clients", Work in Progress.
|
|
|
|
[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail
|
|
Models in IMAP4", <a href="http://www.apps.ietf.org/rfc/rfc1733.html">RFC 1733</a>, December 1994.
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-97">Page 97</a></em></dt><dd><p>
|
|
</p><pre> [ACAP] Newman, C. and J. Myers, "ACAP -- Application
|
|
Configuration Access Protocol", <a href="http://www.apps.ietf.org/rfc/rfc2244.html">RFC 2244</a>,
|
|
November 1997.
|
|
|
|
[SMTP] Klensin, J., "Simple Mail Transfer Protocol",
|
|
<a href="http://www.apps.ietf.org/rfc/stdlist.html#s10">STD 10</a>, <a href="http://www.apps.ietf.org/rfc/rfc2821.html">RFC 2821</a>, April 2001.
|
|
</pre>
|
|
<p>
|
|
The following documents are historical or describe historical aspects
|
|
of this protocol:
|
|
</p><p>
|
|
</p><pre> [IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with
|
|
IMAP2bis", <a href="http://www.apps.ietf.org/rfc/rfc2061.html">RFC 2061</a>, December 1996.
|
|
|
|
[IMAP-HISTORICAL] Crispin, M., "IMAP4 Compatibility with IMAP2
|
|
and IMAP2bis", <a href="http://www.apps.ietf.org/rfc/rfc1732.html">RFC 1732</a>, December 1994.
|
|
|
|
[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol
|
|
- Obsolete Syntax", <a href="http://www.apps.ietf.org/rfc/rfc2062.html">RFC 2062</a>, December 1996.
|
|
|
|
[IMAP2] Crispin, M., "Interactive Mail Access Protocol
|
|
- Version 2", <a href="http://www.apps.ietf.org/rfc/rfc1176.html">RFC 1176</a>, August 1990.
|
|
|
|
[<a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC-822</a>] Crocker, D., "Standard for the Format of ARPA
|
|
Internet Text Messages", <a href="http://www.apps.ietf.org/rfc/stdlist.html#s11">STD 11</a>, <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC 822</a>,
|
|
August 1982.
|
|
|
|
[<a href="http://www.apps.ietf.org/rfc/rfc821.html">RFC-821</a>] Postel, J., "Simple Mail Transfer Protocol",
|
|
<a href="http://www.apps.ietf.org/rfc/stdlist.html#s10">STD 10</a>, <a href="http://www.apps.ietf.org/rfc/rfc821.html">RFC 821</a>, August 1982.
|
|
</pre>
|
|
<p>
|
|
</p></dd><dt><strong><a name="sec-B">B</a> Changes from <a href="http://www.apps.ietf.org/rfc/rfc2060.html">RFC 2060</a></strong></dt><dd>
|
|
<p>
|
|
1) Clarify description of unique identifiers and their semantics.
|
|
</p><p>
|
|
2) Fix the SELECT description to clarify that UIDVALIDITY is required
|
|
in the SELECT and EXAMINE responses.
|
|
</p><p>
|
|
3) Added an example of a failing search.
|
|
</p><p>
|
|
4) Correct store-att-flags: "#flag" should be "1#flag".
|
|
</p><p>
|
|
5) Made search and section rules clearer.
|
|
</p><p>
|
|
6) Correct the STORE example.
|
|
</p><p>
|
|
7) Correct "BASE645" misspelling.
|
|
</p><p>
|
|
8) Remove extraneous close parenthesis in example of two-part message
|
|
with text and BASE64 attachment.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-98">Page 98</a></em></dt><dd><p>
|
|
9) Remove obsolete "MAILBOX" response from mailbox-data.
|
|
</p><p>
|
|
10) A spurious "<" in the rule for mailbox-data was removed.
|
|
</p><p>
|
|
11) Add CRLF to continue-req.
|
|
</p><p>
|
|
12) Specifically exclude "]" from the atom in resp-text-code.
|
|
</p><p>
|
|
13) Clarify that clients and servers should adhere strictly to the
|
|
protocol syntax.
|
|
</p><p>
|
|
14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
|
|
</p><p>
|
|
15) Add NEWNAME to resp-text-code.
|
|
</p><p>
|
|
16) Clarify that the empty string, not NIL, is used as arguments to
|
|
LIST.
|
|
</p><p>
|
|
17) Clarify that NIL can be returned as a hierarchy delimiter for the
|
|
empty string mailbox name argument if the mailbox namespace is flat.
|
|
</p><p>
|
|
18) Clarify that addr-mailbox and addr-name have <a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a> quoting
|
|
removed.
|
|
</p><p>
|
|
19) Update UTF-7 reference.
|
|
</p><p>
|
|
20) Fix example in 6.3.11.
|
|
</p><p>
|
|
21) Clarify that non-existent UIDs are ignored.
|
|
</p><p>
|
|
22) Update DISPOSITION reference.
|
|
</p><p>
|
|
23) Expand state diagram.
|
|
</p><p>
|
|
24) Clarify that partial fetch responses are only returned in
|
|
response to a partial fetch command.
|
|
</p><p>
|
|
25) Add UIDNEXT response code. Correct UIDVALIDITY definition
|
|
reference.
|
|
</p><p>
|
|
26) Further clarification of "can" vs. "<strong>MAY</strong>".
|
|
</p><p>
|
|
27) Reference <a href="http://www.apps.ietf.org/rfc/rfc2119.html">RFC-2119</a>.
|
|
</p><p>
|
|
28) Clarify that superfluous shifts are not permitted in modified
|
|
UTF-7.
|
|
</p><p>
|
|
29) Clarify that there are no implicit shifts in modified UTF-7.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-99">Page 99</a></em></dt><dd><p>
|
|
30) Clarify that "INBOX" in a mailbox name is always INBOX, even if
|
|
it is given as a string.
|
|
</p><p>
|
|
31) Add missing open parenthesis in media-basic grammar rule.
|
|
</p><p>
|
|
32) Correct attribute syntax in mailbox-data.
|
|
</p><p>
|
|
33) Add UIDNEXT to EXAMINE responses.
|
|
</p><p>
|
|
34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
|
|
responses in SELECT and EXAMINE. They are required now, but weren't
|
|
in older versions.
|
|
</p><p>
|
|
35) Update references with RFC numbers.
|
|
</p><p>
|
|
36) Flush text-mime2.
|
|
</p><p>
|
|
37) Clarify that modified UTF-7 names must be case-sensitive and that
|
|
violating the convention should be avoided.
|
|
</p><p>
|
|
38) Correct UID FETCH example.
|
|
</p><p>
|
|
39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE
|
|
responses.
|
|
</p><p>
|
|
40) Clarify the use of the word "convention".
|
|
</p><p>
|
|
41) Clarify that a command is not "in progress" until it has been
|
|
fully received (specifically, that a command is not "in progress"
|
|
during command continuation negotiation).
|
|
</p><p>
|
|
42) Clarify envelope defaulting.
|
|
</p><p>
|
|
43) Clarify that SP means one and only one space character.
|
|
</p><p>
|
|
44) Forbid silly states in LIST response.
|
|
</p><p>
|
|
45) Clarify that the ENVELOPE, INTERNALDATE, <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>*, BODY*, and UID
|
|
for a message is static.
|
|
</p><p>
|
|
46) Add BADCHARSET response code.
|
|
</p><p>
|
|
47) Update formal syntax to [ABNF] conventions.
|
|
</p><p>
|
|
48) Clarify trailing hierarchy delimiter in CREATE semantics.
|
|
</p><p>
|
|
49) Clarify that the "blank line" is the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] delimiting blank
|
|
line.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-100">Page 100</a></em></dt><dd><p>
|
|
50) Clarify that RENAME should also create hierarchy as needed for
|
|
the command to complete.
|
|
</p><p>
|
|
51) Fix body-ext-mpart to not require language if disposition
|
|
present.
|
|
</p><p>
|
|
52) Clarify the <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.HEADER response.
|
|
</p><p>
|
|
53) Correct missing space after charset astring in search.
|
|
</p><p>
|
|
54) Correct missing quote for BADCHARSET in resp-text-code.
|
|
</p><p>
|
|
55) Clarify that ALL, FAST, and FULL preclude any other data items
|
|
appearing.
|
|
</p><p>
|
|
56) Clarify semantics of reference argument in LIST.
|
|
</p><p>
|
|
57) Clarify that a null string for SEARCH HEADER X-FOO means any
|
|
message with a header line with a field-name of X-FOO regardless of
|
|
the text of the header.
|
|
</p><p>
|
|
58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
|
|
</p><p>
|
|
59) It is not an error for the client to store a flag that is not in
|
|
the PERMANENTFLAGS list; however, the server will either ignore the
|
|
change or make the change in the session only.
|
|
</p><p>
|
|
60) Correct/clarify the text regarding superfluous shifts.
|
|
</p><p>
|
|
61) Correct typographic errors in the "Changes" section.
|
|
</p><p>
|
|
62) Clarify that STATUS must not be used to check for new messages in
|
|
the selected mailbox
|
|
</p><p>
|
|
63) Clarify LSUB behavior with "%" wildcard.
|
|
</p><p>
|
|
64) Change AUTHORIZATION to AUTHENTICATE in <a href="http://www.apps.ietf.org/rfc/rfc3501.html#sec-7.5">section 7.5</a>.
|
|
</p><p>
|
|
65) Clarify description of multipart body type.
|
|
</p><p>
|
|
66) Clarify that STORE FLAGS does not affect \Recent.
|
|
</p><p>
|
|
67) Change "west" to "east" in description of timezone.
|
|
</p><p>
|
|
68) Clarify that commands which break command pipelining must wait
|
|
for a completion result response.
|
|
</p><p>
|
|
69) Clarify that EXAMINE does not affect \Recent.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-101">Page 101</a></em></dt><dd><p>
|
|
70) Make description of MIME structure consistent.
|
|
</p><p>
|
|
71) Clarify that date searches disregard the time and timezone of the
|
|
INTERNALDATE or Date: header. In other words, "ON 13-APR-2000" means
|
|
messages with an INTERNALDATE text which starts with "13-APR-2000",
|
|
even if timezone differential from the local timezone is sufficient
|
|
to move that INTERNALDATE into the previous or next day.
|
|
</p><p>
|
|
72) Clarify that the header fetches don't add a blank line if one
|
|
isn't in the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] message.
|
|
</p><p>
|
|
73) Clarify (in discussion of UIDs) that messages are immutable.
|
|
</p><p>
|
|
74) Add an example of CHARSET searching.
|
|
</p><p>
|
|
75) Clarify in SEARCH that keywords are a type of flag.
|
|
</p><p>
|
|
76) Clarify the mandatory nature of the SELECT data responses.
|
|
</p><p>
|
|
77) Add optional CAPABILITY response code in the initial OK or
|
|
PREAUTH.
|
|
</p><p>
|
|
78) Add note that server can send an untagged CAPABILITY command as
|
|
part of the responses to AUTHENTICATE and LOGIN.
|
|
</p><p>
|
|
79) Remove statement about it being unnecessary to issue a CAPABILITY
|
|
command more than once in a connection. That statement is no longer
|
|
true.
|
|
</p><p>
|
|
80) Clarify that untagged EXPUNGE decrements the number of messages
|
|
in the mailbox.
|
|
</p><p>
|
|
81) Fix definition of "body" (concatenation has tighter binding than
|
|
alternation).
|
|
</p><p>
|
|
82) Add a new "Special Notes to Implementors" section with reference
|
|
to [IMAP-IMPLEMENTATION].
|
|
</p><p>
|
|
83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
|
|
command should only be done if a security layer was not negotiated.
|
|
</p><p>
|
|
84) Change the definition of atom to exclude "]". Update astring to
|
|
include "]" for compatibility with the past. Remove resp-text-atom.
|
|
</p><p>
|
|
85) Remove NEWNAME. It can't work because mailbox names can be
|
|
literals and can include "]". Functionality can be addressed via
|
|
referrals.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-102">Page 102</a></em></dt><dd><p>
|
|
86) Move modified UTF-7 rationale in order to have more logical
|
|
paragraph flow.
|
|
</p><p>
|
|
87) Clarify UID uniqueness guarantees with the use of <strong>MUST</strong>.
|
|
</p><p>
|
|
88) Note that clients should read response data until the connection
|
|
is closed instead of immediately closing on a BYE.
|
|
</p><p>
|
|
89) Change <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC-822</a> references to <a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>.
|
|
</p><p>
|
|
90) Clarify that <a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a> should be followed instead of <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC-822</a>.
|
|
</p><p>
|
|
91) Change recommendation of optional automatic capabilities in LOGIN
|
|
and AUTHENTICATE to use the CAPABILITY response code in the tagged
|
|
OK. This is more interoperable than an unsolicited untagged
|
|
CAPABILITY response.
|
|
</p><p>
|
|
92) STARTTLS and AUTH=PLAIN are mandatory to implement; add
|
|
recommendations for other [SASL] mechanisms.
|
|
</p><p>
|
|
93) Clarify that a "connection" (as opposed to "server" or "command")
|
|
is in one of the four states.
|
|
</p><p>
|
|
94) Clarify that a failed or rejected command does not change state.
|
|
</p><p>
|
|
95) Split references between normative and informative.
|
|
</p><p>
|
|
96) Discuss authentication failure issues in security section.
|
|
</p><p>
|
|
97) Clarify that a data item is not necessarily of only one data
|
|
type.
|
|
</p><p>
|
|
98) Clarify that sequence ranges are independent of order.
|
|
</p><p>
|
|
99) Change an example to clarify that superfluous shifts in
|
|
Modified-UTF7 can not be fixed just by omitting the shift. The
|
|
entire string must be recalculated.
|
|
</p><p>
|
|
100) Change Envelope Structure definition since [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] uses
|
|
"envelope" to refer to the [SMTP] envelope and not the envelope data
|
|
that appears in the [<a href="http://www.apps.ietf.org/rfc/rfc2822.html">RFC-2822</a>] header.
|
|
</p><p>
|
|
101) Expand on <a href="http://www.apps.ietf.org/rfc/rfc822.html">RFC822</a>.HEADER response data vs. BODY[HEADER].
|
|
</p><p>
|
|
102) Clarify Logout state semantics, change ASCII art.
|
|
</p><p>
|
|
103) Security changes to comply with IESG requirements.
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-103">Page 103</a></em></dt><dd><p>
|
|
104) Add definition for body URI.
|
|
</p><p>
|
|
105) Break sequence range definition into three rules, with rewritten
|
|
descriptions for each.
|
|
</p><p>
|
|
106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
|
|
</p><p>
|
|
107) Add IANA Considerations section.
|
|
</p><p>
|
|
108) Clarify valid client assumptions for new message UIDs vs.
|
|
UIDNEXT.
|
|
</p><p>
|
|
109) Clarify that changes to permanentflags affect concurrent
|
|
sessions as well as subsequent sessions.
|
|
</p><p>
|
|
110) Clarify that authenticated state can be entered by the CLOSE
|
|
command.
|
|
</p><p>
|
|
111) Emphasize that SELECT and EXAMINE are the exceptions to the rule
|
|
that a failing command does not change state.
|
|
</p><p>
|
|
112) Clarify that newly-appended messages have the Recent flag set.
|
|
</p><p>
|
|
113) Clarify that newly-copied messages <strong>SHOULD</strong> have the Recent flag
|
|
set.
|
|
</p><p>
|
|
114) Clarify that UID commands always return the UID in FETCH
|
|
responses.
|
|
</p><p>
|
|
</p></dd><dt><strong><a name="sec-C">C</a> Key Word Index</strong></dt><dd>
|
|
<p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-59">
|
|
+FLAGS <flag list> (store command data item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-59">
|
|
+FLAGS.SILENT <flag list> (store command data item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-59">
|
|
-FLAGS <flag list> (store command data item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-59">
|
|
-FLAGS.SILENT <flag list> (store command data item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-64">
|
|
ALERT (response code)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-55">
|
|
ALL (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-50">
|
|
ALL (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-50">
|
|
ANSWERED (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-45">
|
|
APPEND (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-27">
|
|
AUTHENTICATE (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-66">
|
|
BAD (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-64">
|
|
BADCHARSET (response code)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
BCC <string> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
BEFORE <date> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-55">
|
|
BODY (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-73">
|
|
BODY (fetch result)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
BODY <string> (search key)
|
|
</a>
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-104">Page 104</a></em></dt><dd><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-57">
|
|
BODY.PEEK[<section>]<<partial>> (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-57">
|
|
BODYSTRUCTURE (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-74">
|
|
BODYSTRUCTURE (fetch result)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-74">
|
|
BODY[<section>]<<origin octet>> (fetch result)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-55">
|
|
BODY[<section>]<<partial>> (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-67">
|
|
BYE (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-12">
|
|
Body Structure (message attribute)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-24">
|
|
CAPABILITY (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-64">
|
|
CAPABILITY (response code)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-68">
|
|
CAPABILITY (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
CC <string> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-47">
|
|
CHECK (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-48">
|
|
CLOSE (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-59">
|
|
COPY (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-34">
|
|
CREATE (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-35">
|
|
DELETE (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
DELETED (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
DRAFT (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-57">
|
|
ENVELOPE (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-77">
|
|
ENVELOPE (fetch result)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-33">
|
|
EXAMINE (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-71">
|
|
EXISTS (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-48">
|
|
EXPUNGE (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-72">
|
|
EXPUNGE (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-12">
|
|
Envelope Structure (message attribute)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-55">
|
|
FAST (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-54">
|
|
FETCH (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-73">
|
|
FETCH (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
FLAGGED (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-57">
|
|
FLAGS (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-78">
|
|
FLAGS (fetch result)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-71">
|
|
FLAGS (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-59">
|
|
FLAGS <flag list> (store command data item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-59">
|
|
FLAGS.SILENT <flag list> (store command data item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
FROM <string> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-55">
|
|
FULL (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-11">
|
|
Flags (message attribute)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-55">
|
|
HEADER (part specifier)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
HEADER <field-name> <string> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-55">
|
|
HEADER.FIELDS <header-list> (part specifier)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-55">
|
|
HEADER.FIELDS.NOT <header-list> (part specifier)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-57">
|
|
INTERNALDATE (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-78">
|
|
INTERNALDATE (fetch result)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-12">
|
|
Internal Date (message attribute)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
KEYWORD <flag> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-11">
|
|
Keyword (type of flag)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
LARGER <n> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-40">
|
|
LIST (command)
|
|
</a><br>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-105">Page 105</a></em></dt><dd><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-69">
|
|
LIST (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-30">
|
|
LOGIN (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-25">
|
|
LOGOUT (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-43">
|
|
LSUB (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-70">
|
|
LSUB (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-4">
|
|
<strong>MAY</strong> (specification requirement term)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-45">
|
|
MESSAGES (status item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-56">
|
|
MIME (part specifier)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-4">
|
|
<strong>MUST</strong> (specification requirement term)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-4">
|
|
<strong>MUST NOT</strong> (specification requirement term)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-10">
|
|
Message Sequence Number (message attribute)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-51">
|
|
NEW (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-66">
|
|
NO (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-25">
|
|
NOOP (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-52">
|
|
NOT <search-key> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-65">
|
|
OK (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-52">
|
|
OLD (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-52">
|
|
ON <date> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-4">
|
|
<strong>OPTIONAL</strong> (specification requirement term)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-52">
|
|
OR <search-key1> <search-key2> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-64">
|
|
PARSE (response code)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-64">
|
|
PERMANENTFLAGS (response code)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-67">
|
|
PREAUTH (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-12">
|
|
Permanent Flag (class of flag)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-65">
|
|
READ-ONLY (response code)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-65">
|
|
READ-WRITE (response code)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-72">
|
|
RECENT (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-52">
|
|
RECENT (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-45">
|
|
RECENT (status item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-37">
|
|
RENAME (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-4">
|
|
<strong>REQUIRED</strong> (specification requirement term)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-57">
|
|
RFC822 (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-78">
|
|
RFC822 (fetch result)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-57">
|
|
RFC822.HEADER (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-78">
|
|
RFC822.HEADER (fetch result)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-57">
|
|
RFC822.SIZE (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-78">
|
|
RFC822.SIZE (fetch result)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-58">
|
|
RFC822.TEXT (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-79">
|
|
RFC822.TEXT (fetch result)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-49">
|
|
SEARCH (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-71">
|
|
SEARCH (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-52">
|
|
SEEN (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-31">
|
|
SELECT (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-52">
|
|
SENTBEFORE <date> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-52">
|
|
SENTON <date> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-52">
|
|
SENTSINCE <date> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-4">
|
|
<strong>SHOULD</strong> (specification requirement term)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-4">
|
|
<strong>SHOULD NOT</strong> (specification requirement term)
|
|
</a><br>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-106">Page 106</a></em></dt><dd><p>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-52">
|
|
SINCE <date> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-52">
|
|
SMALLER <n> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-27">
|
|
STARTTLS (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-44">
|
|
STATUS (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-70">
|
|
STATUS (response)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-58">
|
|
STORE (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-53">
|
|
SUBJECT <string> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-38">
|
|
SUBSCRIBE (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-12">
|
|
Session Flag (class of flag)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-11">
|
|
System Flag (type of flag)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-56">
|
|
TEXT (part specifier)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-53">
|
|
TEXT <string> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-53">
|
|
TO <string> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-65">
|
|
TRYCREATE (response code)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-60">
|
|
UID (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-58">
|
|
UID (fetch item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-79">
|
|
UID (fetch result)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-53">
|
|
UID <sequence set> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-65">
|
|
UIDNEXT (response code)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-45">
|
|
UIDNEXT (status item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-65">
|
|
UIDVALIDITY (response code)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-45">
|
|
UIDVALIDITY (status item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-53">
|
|
UNANSWERED (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-53">
|
|
UNDELETED (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-53">
|
|
UNDRAFT (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-53">
|
|
UNFLAGGED (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-53">
|
|
UNKEYWORD <flag> (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-65">
|
|
UNSEEN (response code)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-53">
|
|
UNSEEN (search key)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-45">
|
|
UNSEEN (status item)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-39">
|
|
UNSUBSCRIBE (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-8">
|
|
Unique Identifier (UID) (message attribute)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-62">
|
|
X<atom> (command)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-12">
|
|
[RFC-2822] Size (message attribute)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-11">
|
|
\Answered (system flag)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-11">
|
|
\Deleted (system flag)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-11">
|
|
\Draft (system flag)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-11">
|
|
\Flagged (system flag)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-69">
|
|
\Marked (mailbox name attribute)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-69">
|
|
\Noinferiors (mailbox name attribute)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-69">
|
|
\Noselect (mailbox name attribute)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-11">
|
|
\Recent (system flag)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-11">
|
|
\Seen (system flag)
|
|
</a><br>
|
|
<a href="http://www.apps.ietf.org/rfc/rfc3501.html#page-69">
|
|
\Unmarked (mailbox name attribute)
|
|
</a><br>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-107">Page 107</a></em></dt><dd><p>
|
|
</p></dd><dt>Author's Address</dt><dd>
|
|
<p>
|
|
Mark R. Crispin
|
|
<br>
|
|
Networks and Distributed Computing
|
|
<br>
|
|
University of Washington
|
|
<br>
|
|
4545 15th Avenue NE
|
|
<br>
|
|
Seattle, WA 98105-4527
|
|
</p><p>
|
|
Phone: (206) 543-5762
|
|
</p><p>
|
|
EMail: MRC@CAC.Washington.EDU
|
|
</p><p>
|
|
</p></dd><dt><hr>
|
|
<em><a name="page-108">Page 108</a></em></dt><dd><p>
|
|
</p></dd><dt>Full Copyright Statement</dt><dd>
|
|
<p>
|
|
Copyright © The Internet Society (2003). All Rights Reserved.
|
|
</p><p>
|
|
This document and translations of it may be copied and furnished to
|
|
others, and derivative works that comment on or otherwise explain it
|
|
or assist in its implementation may be prepared, copied, published
|
|
and distributed, in whole or in part, without restriction of any
|
|
kind, provided that the above copyright notice and this paragraph are
|
|
included on all such copies and derivative works. However, this
|
|
document itself may not be modified in any way, such as by removing
|
|
the copyright notice or references to the Internet Society or other
|
|
Internet organizations, except as needed for the purpose of
|
|
developing Internet standards in which case the procedures for
|
|
copyrights defined in the Internet Standards process must be
|
|
followed, or as required to translate it into languages other than
|
|
English.
|
|
</p><p>
|
|
The limited permissions granted above are perpetual and will not be
|
|
revoked by the Internet Society or its successors or assigns. v This
|
|
document and the information contained herein is provided on an "AS
|
|
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
|
|
FORCE DISCLAIMS 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.
|
|
</p><p>
|
|
</p></dd><dt>Acknowledgement</dt><dd>
|
|
<p>
|
|
Funding for the RFC Editor function is currently provided by the
|
|
Internet Society.
|
|
</p><p>
|
|
</p></dd><dt><hr></dt><dd>
|
|
</dd></dl>
|
|
|
|
</body><style type="text/css">/*This block of style rules is inserted by AdBlock*/#RadAd_Skyscraper,#bbccom_leaderboard,#center_banner,#footer_adcode,#hbBHeaderSpon,#hiddenHeaderSpon,#navbar_adcode,#rightAds,#rightcolumn_adcode,#top-advertising,#topMPU,#tracker_advertorial,.ad-now,.dfpad,.prWrap,[id^="ad_block"],[id^="adbrite"],[id^="dclkAds"],[id^="ew"][id$="_bannerDiv"],[id^="konaLayer"],a.kLink span[id^="preLoadWrap"].preLoadWrap,a[href^="http://ad."][href*=".doubleclick.net/"],a[href^="http://adserver.adpredictive.com"],div#adxLeaderboard,div#dir_ads_site,div#FFN_Banner_Holder,div#FFN_imBox_Container,div#p360-format-box,div#rhs div#rhs_block table#mbEnd,div#rm_container,div#tads table[align="center"][width="100%"],div#tooltipbox[class^="itxt"],div[class^="dms_ad_IDS"],div[id^="adKontekst_"],div[id^="google_ads_div"],div[id^="kona_"][id$="_wrapper"],div[id^="sponsorads"],div[id^="y5_direct"],iframe.chitikaAdBlock,iframe[id^="dapIfM"],iframe[id^="etarget"][id$="banner"],iframe[name^="AdBrite"],iframe[name^="google_ads_"],img[src^="http://cdn.adnxs.com"],ispan#ab_pointer,object#flashad,object#ve_threesixty_swf[name="ve_threesixty_swf"],table[cellpadding="0"][width="100%"] > * > * > * > div[id^="tpa"],#A9AdsMiddleBoxTop,#A9AdsOutOfStockWidgetTop,#A9AdsServicesWidgetTop,#ADSLOT_1,#ADSLOT_2,#ADSLOT_3,#ADSLOT_4,#AD_CONTROL_22,#ADsmallWrapper,#Ad160x600,#Ad2,#Ad300x250,#Ad3Left,#Ad3Right,#Ad3TextAd,#AdA,#AdArea,#AdBanner_F1,#AdBar,#AdBar1,#AdC,#AdContainer,#AdContainerTop,#AdContentModule_F,#AdDetails_GoogleLinksBottom,#AdDetails_InsureWith,#AdE,#AdF,#AdFrame4,#AdG,#AdH,#AdI,#AdJ,#AdLeaderboardBottom,#AdLeaderboardTop,#AdMiddle,#AdMobileLink,#AdRectangle,#AdSenseDiv,#AdServer,#AdShowcase_F1,#AdSky23,#AdSkyscraper,#AdSponsor_SF,#AdSubsectionShowcase_F1,#AdTargetControl1_iframe,#AdText,#AdTop,#AdTopLeader,#Ad_BelowContent,#Ad_Block,#Ad_Center1,#Ad_Right1,#Ad_RightBottom,#Ad_RightTop,#Ad_Top,#Adrectangle,#Ads,#AdsContent,#AdsRight,#AdsWrap,#Ads_BA_CAD,#Ads_BA_CAD2,#Ads_BA_CAD_box,#Ads_BA_SKY,#Ads_CAD,#Ads_OV_BS,#Ads_Special,#AdvertMPU23b,#AdvertPanel,#Advertorial,#Advertorials,#BannerAd,#BannerAdvert,#BigBoxAd,#BodyAd,#BotAd,#Bottom468x60AD,#ButtonAd,#CompanyDetailsNarrowGoogleAdsPresentationControl,#CompanyDetailsWideGoogleAdsPresentationControl,#ContentAd,#ContentAd1,#ContentAd2,#ContentAdPlaceHolder1,#ContentAdPlaceHolder2,#ContentAdXXL,#ContentPolepositionAds_Result,#DivAdEggHeadCafeTopBanner,#FooterAd,#FooterAdContainer,#GoogleAd1,#GoogleAd2,#GoogleAd3,#GoogleAdsPresentationControl,#GoogleAdsense,#Google_Adsense_Main,#HEADERAD,#HOME_TOP_RIGHT_BOXAD,#HeaderAD,#HeaderAdsBlock,#HeaderAdsBlockFront,#HeaderBannerAdSpacer,#HeaderTextAd,#HeroAd,#HomeAd1,#HouseAd,#ID_Ad_Sky,#JobsearchResultsAds,#Journal_Ad_125,#Journal_Ad_300,#KH-contentAd,#LargeRectangleAd,#LeftAd,#LeftAdF1,#LeftAdF2,#LftAd,#LoungeAdsDiv,#LowerContentAd,#MainSponsoredLinks,#Nightly_adContainer,#NormalAdModule,#OverrideAdArea,#PREFOOTER_LEFT_BOXAD,#PREFOOTER_RIGHT_BOXAD,#PageLeaderAd,#RelevantAds,#RgtAd1,#RightAd,#RightBottom300x250AD,#RightNavTopAdSpot,#RightSponsoredAd,#SectionAd300-250,#SectionSponsorAd,#SideAdMpu,#SidebarAdContainer,#SkyAd,#SpecialAds,#SponsoredAd,#SponsoredLinks,#TOP_ADROW,#TOP_RIGHT_BOXAD,#Tadspacefoot,#Tadspacemrec,#Top468x60AD,#TopAdBox,#TopAdContainer,#TopAdDiv,#TopAdPos,#VM-MPU-adspace,#VM-footer-adspace,#VM-header-adspace,#VM-header-adwrap,#XEadLeaderboard,#XEadSkyscraper,#YahooAdParentContainer,#_ads,#about_adsbottom,#abovepostads,#ad-120x600-sidebar,#ad-120x60Div,#ad-160x600,#ad-160x600-sidebar,#ad-250,#ad-250x300,#ad-300,#ad-300x250,#ad-300x250-sidebar,#ad-300x250Div,#ad-300x60-1,#ad-376x280,#ad-728,#ad-728x90-leaderboard-top,#ad-728x90-top0,#ad-ads,#ad-article,#ad-banner,#ad-banner-1,#ad-billboard-bottom,#ad-block-125,#ad-bottom,#ad-bottom-wrapper,#ad-box-first,#ad-box-second,#ad-boxes,#ad-bs,#ad-buttons,#ad-colB-1,#ad-column,#ad-content,#ad-contentad,#ad-flex-first,#ad-footer,#ad-footprint-160x600,#ad-frame,#ad-front-footer,#ad-front-sponsoredlinks,#ad-halfpage,#ad-header-728x90,#ad-horizontal-header,#ad-img,#ad-inner,#ad-label,#ad-leaderboard,#ad-leaderboard-bottom,#ad-leaderboard-container,#ad-leaderboard-spot,#ad-leaderboard-top,#ad-left,#ad-links-content,#ad-list-row,#ad-lrec,#ad-medium,#ad-medium-rectangle,#ad-medrec,#ad-middlethree,#ad-middletwo,#ad-module,#ad-mpu,#ad-mpu1-spot,#ad-mpu2,#ad-mpu2-spot,#ad-north,#ad-one,#ad-placard,#ad-placeholder,#ad-rectangle,#ad-right,#ad-righttop,#ad-row,#ad-side-text,#ad-sidebar,#ad-sky,#ad-skyscraper,#ad-slug-wrapper,#ad-small-banner,#ad-space,#ad-special,#ad-splash,#ad-sponsors,#ad-spot,#ad-squares,#ad-target,#ad-target-Leaderbord,#ad-teaser,#ad-text,#ad-top-banner,#ad-top-text-low,#ad-top-wrap,#ad-tower,#ad-trailerboard-spot,#ad-two,#ad-typ1,#ad-unit,#ad-west,#ad-wrap,#ad-wrap-right,#ad-wrapper1,#ad-yahoo-simple,#ad1006,#ad11,#ad125BL,#ad125BR,#ad125TL,#ad125TR,#ad125x125,#ad160x600,#ad160x600right,#ad1Sp,#ad2,#ad2Sp,#ad300,#ad300-250,#ad300X250,#ad300_x_250,#ad300x100Middle,#ad300x150,#ad300x250,#ad300x250Module,#ad300x60,#ad300x600,#ad300x600_callout,#ad336,#ad336x280,#ad375x85,#ad4,#ad468,#ad468x60,#ad468x60_top,#ad526x250,#ad600,#ad7,#ad728,#ad728Mid,#ad728Top,#ad728Wrapper,#ad728top,#ad728x90_1,#ad90,#adBadges,#adBanner120x600,#adBanner160x600,#adBanner336x280,#adBanner728,#adBannerTable,#adBannerTop,#adBar,#adBelt,#adBlock125,#adBlockTop,#adBlocks,#adBox,#adBox350,#adBox390,#adCirc300X200,#adCirc_620_100,#adColumn,#adContainer_1,#adContainer_2,#adContainer_3,#adDiv300,#adDiv728,#adFiller,#adFps,#adFtofrs,#adGallery,#adGroup1,#adHeaderTop,#adIsland,#adL,#adLB,#adLabel,#adLayer,#adLeader,#adLeaderTop,#adLeaderboard,#adMPU,#adMediumRectangle,#adMiddle0Frontpage,#adMiniPremiere,#adP,#adPlaceHolderRight,#adPlacer,#adRight,#adSPLITCOLUMNTOPRIGHT,#adSenseModule,#adSenseWrapper,#adServer_marginal,#adSidebar,#adSidebarSq,#adSky,#adSkyscraper,#adSlider,#adSpace,#adSpace3,#adSpace300_ifrMain,#adSpace4,#adSpace5,#adSpace6,#adSpace7,#adSpace_footer,#adSpace_right,#adSpace_top,#adSpacer,#adSpecial,#adSplotlightEm,#adSpot-Leader,#adSpot-banner,#adSpot-island,#adSpot-mrec1,#adSpot-sponsoredlinks,#adSpot-textbox1,#adSpot-widestrip,#adSpotAdvertorial,#adSpotIsland,#adSpotSponsoredLinks,#adSquare,#adStaticA,#adStrip,#adSuperAd,#adSuperPremiere,#adSuperSkyscraper,#adSuperbanner,#adTableCell,#adTag1,#adTag2,#adText,#adTextLink,#adText_container,#adTile,#adTopContent,#adTopboxright,#adTower,#adUnit,#adZoneTop,#ad_1,#ad_130x250_inhouse,#ad_160x160,#ad_160x600,#ad_190x90,#ad_2,#ad_3,#ad_300,#ad_300_250,#ad_300_250_1,#ad_300x250,#ad_300x250_content_column,#ad_300x90,#ad_4,#ad_468_60,#ad_5,#ad_728_foot,#ad_728x90,#ad_728x90_container,#ad_940,#ad_984,#ad_A,#ad_B,#ad_Banner,#ad_C,#ad_C2,#ad_D,#ad_E,#ad_F,#ad_G,#ad_H,#ad_I,#ad_J,#ad_K,#ad_L,#ad_M,#ad_N,#ad_O,#ad_P,#ad_YieldManager-300x250,#ad_anchor,#ad_banner,#ad_banner_top,#ad_bar,#ad_bellow_post,#ad_bigsize_wrapper,#ad_block_1,#ad_block_2,#ad_bottom,#ad_box,#ad_box_colspan,#ad_box_top,#ad_branding,#ad_bs_area,#ad_buttons,#ad_center_monster,#ad_cna2,#ad_cont,#ad_container_marginal,#ad_container_side,#ad_container_top,#ad_content_top,#ad_content_wrap,#ad_feature,#ad_firstpost,#ad_footer,#ad_front_three,#ad_fullbanner,#ad_global_header,#ad_haha_1,#ad_haha_4,#ad_halfpage,#ad_head,#ad_header,#ad_holder,#ad_horizontal,#ad_horseshoe_left,#ad_horseshoe_right,#ad_horseshoe_spacer,#ad_horseshoe_top,#ad_hotpots,#ad_in_arti,#ad_island,#ad_label,#ad_large_rectangular,#ad_lastpost,#ad_layer2,#ad_leaderBoard,#ad_leaderboard,#ad_leaderboard728x90,#ad_leaderboard_top,#ad_left,#ad_lrec,#ad_lwr_square,#ad_main,#ad_medium_rectangle,#ad_medium_rectangular,#ad_mediumrectangle,#ad_menu_header,#ad_message,#ad_middle,#ad_most_pop_234x60_req_wrapper,#ad_mpu,#ad_mpu300x250,#ad_mpuav,#ad_mrcontent,#ad_overlay,#ad_play_300,#ad_rect,#ad_rect_body,#ad_rect_bottom,#ad_rectangle,#ad_rectangle_medium,#ad_related_links_div,#ad_related_links_div_program,#ad_replace_div_0,#ad_replace_div_1,#ad_report_leaderboard,#ad_report_rectangle,#ad_right,#ad_right_main,#ad_ros_tower,#ad_rr_1,#ad_sec,#ad_sec_div,#ad_sgd,#ad_sidebar,#ad_sidebar1,#ad_sidebar2,#ad_sidebar3,#ad_skyscraper,#ad_skyscraper160x600,#ad_skyscraper_text,#ad_slot_leaderboard,#ad_slot_livesky,#ad_slot_sky_top,#ad_ss,#ad_term_bottom_place,#ad_text:not(textarea),#ad_thread_first_post_content,#ad_top,#ad_top_holder,#ad_tp_banner_1,#ad_tp_banner_2,#ad_unit,#ad_vertical,#ad_wide,#ad_wide_box,#ad_widget,#ad_window,#ad_wrap,#adbForum,#adbanner,#adbig,#adbnr,#adboard,#adbottom,#adbox1,#adbox2,#adclear,#adcode,#adcode1,#adcode2,#adcode3,#adcode4,#adcolumnwrapper,#adcontainer,#adcontainerRight,#adcontainsm,#adcontent,#adcontent1,#adcontrolPushSite,#add_ciao2,#addbottomleft,#addiv-bottom,#addiv-top,#adfooter,#adfooter_728x90,#adframe:not(frameset),#adhead,#adhead_g,#adheader,#adhome,#adiframe1_iframe,#adiframe2_iframe,#adiframe3_iframe,#adimg,#adition_content_ad,#adlabel,#adlabelFooter,#adlayerad,#adleaderboard,#adleaderboard_flex,#adleaderboardb,#adleaderboardb_flex,#adleft,#adlinks,#adlinkws,#adlrec,#admid,#admiddle3center,#admiddle3left,#adposition,#adposition-C,#adposition-FPMM,#adposition1,#adposition2,#adposition4,#adrectangle,#adrectanglea,#adrectanglea_flex,#adrectangleb,#adrectangleb_flex,#adrig,#adright,#adright2,#adrighthome,#ads-468,#ads-area,#ads-block,#ads-bot,#ads-bottom,#ads-col,#ads-dell,#ads-horizontal,#ads-indextext,#ads-leaderboard1,#ads-lrec,#ads-menu,#ads-middle,#ads-prices,#ads-rhs,#ads-right,#ads-sponsored-boxes,#ads-top,#ads-vers7,#ads-wrapper,#ads120,#ads160left,#ads2,#ads300,#ads300-250,#ads300Bottom,#ads300Top,#ads336x280,#ads7,#ads728bottom,#ads728top,#ads790,#adsDisplay,#adsID,#ads_160,#ads_300,#ads_728,#ads_banner,#ads_belowforumlist,#ads_belownav,#ads_bottom_inner,#ads_bottom_outer,#ads_box,#ads_button,#ads_catDiv,#ads_footer,#ads_fullsize,#ads_html1,#ads_html2,#ads_medrect,#ads_notice,#ads_right,#ads_right_sidebar,#ads_sidebar_roadblock,#ads_space,#ads_top,#ads_watch_top_square,#ads_zone27,#adsbottom,#adsbox,#adscolumn,#adsd_contentad_r1,#adsd_contentad_r2,#adsd_contentad_r3,#adsd_topbanner,#adsd_txt_sky,#adsdiv,#adsense-2,#adsense-header,#adsense-tag,#adsense-text,#adsenseLeft,#adsenseOne,#adsenseWrap,#adsense_article_left,#adsense_box,#adsense_leaderboard,#adsense_overlay,#adsense_placeholder_2,#adsenseheader,#adsensetopplay,#adsensewidget-3,#adserv,#adsimage,#adsky,#adskyscraper,#adslot,#adsonar,#adspace-300x250,#adspace300x250,#adspaceBox,#adspaceBox300,#adspace_header,#adspot,#adspot-1,#adspot-149x170,#adspot-1x4,#adspot-2,#adspot-295x60,#adspot-2a,#adspot-2b,#adspot-300x250-pos-1,#adspot-300x250-pos-2,#adspot-468x60-pos-2,#adspot-a,#adspot300x250,#adspot_220x90,#adspot_300x250,#adspot_468x60,#adspot_728x90,#adsquare,#adsright,#adst,#adstop,#adt,#adtab,#adtag_right_side,#adtaily-widget-light,#adtech_googleslot_03c,#adtech_takeover,#adtop,#adtophp,#adtxt,#adv-masthead,#adv_google_300,#adv_google_728,#adv_top_banner_wrapper,#adver1,#adver2,#adver3,#adver4,#adver5,#adver6,#adver7,#advert-1,#advert-120,#advert-boomer,#advert-display,#advert-header,#advert-leaderboard,#advert-links-bottom,#advert-skyscraper,#advert-top,#advert1,#advertBanner,#advertContainer,#advertDB,#advertRight,#advert_125x125,#advert_250x250,#advert_box,#advert_home01,#advert_leaderboard,#advert_lrec_format,#advert_mid,#advert_mpu,#advert_mpu_1,#advert_right_skyscraper,#advert_sky,#advertbox,#advertbox2,#advertbox3,#advertbox4,#adverthome,#advertise-here-sidebar,#advertise-now,#advertise1,#advertiseHere,#advertisement160x600,#advertisement728x90,#advertisementLigatus,#advertisementPrio2,#advertisementsarticle,#advertiser-container,#advertiserLinks,#advertisers,#advertising-banner,#advertising-caption,#advertising-container,#advertising-control,#advertising-skyscraper,#advertising2,#advertisingModule160x600,#advertisingModule728x90,#advertising_btm,#advertising_horiz_cont,#advertisment,#advertismentElementInUniversalbox,#advertorial,#adverts-top-container,#adverts-top-left,#adverts-top-middle,#adverts-top-right,#advertsingle,#advt,#adwhitepaperwidget,#adwin_rec,#adwith,#adwords-4-container,#adxBigAd,#adxMiddle5,#adxSponLink,#adxSponLinkA,#adxtop,#adz,#adzbanner,#adzerk,#adzerk1,#adzoneBANNER,#affinityBannerAd,#agi-ad300x250,#agi-ad300x250overlay,#agi-sponsored,#alert_ads,#anchorAd,#annoying_ad,#ap_adframe,#apiBackgroundAd,#apiTopAdWrap,#apmNADiv,#araHealthSponsorAd,#area-adcenter,#area1ads,#article-ad-container,#article-box-ad,#articleAdReplacement,#articleLeftAdColumn,#articleSideAd,#article_ad,#article_ad_container,#article_box_ad,#asinglead,#atlasAdDivGame,#awds-nt1-ad,#banner-300x250,#banner-ad,#banner-ad-container,#banner-ads,#banner250x250,#banner468x60,#banner728x90,#bannerAd,#bannerAdTop,#bannerAd_ctr,#banner_ad,#banner_ad_footer,#banner_ad_module,#banner_admicro,#banner_ads,#banner_content_ad,#banner_topad,#bannerad2,#baseAdvertising,#bbccom_mpu,#bbccom_storyprintsponsorship,#bbo_ad1,#bg-footer-ads,#bg-footer-ads2,#bg_YieldManager-160x600,#bg_YieldManager-300x250,#bg_YieldManager-728x90,#bigAd,#bigBoxAd,#bigad300outer,#bigadbox,#bigadframe,#bigadspot,#billboard_ad,#block-ad_cube-1,#block-openads-0,#block-openads-1,#block-openads-2,#block-openads-3,#block-openads-4,#block-openads-5,#block-thewrap_ads_250x300-0,#blog-ad,#blog_ad_content,#blog_ad_opa,#blox-big-ad,#blox-big-ad-bottom,#blox-big-ad-top,#blox-halfpage-ad,#blox-tile-ad,#blox-tower-ad,#body_728_ad,#book-ad,#botad,#bott_ad2,#bott_ad2_300,#bottom-ad,#bottom-ad-container,#bottom-ad-wrapper,#bottom-ads,#bottomAd,#bottomAdCCBucket,#bottomAdContainer,#bottomAdSense,#bottomAdSenseDiv,#bottomAds,#bottomRightAd,#bottomRightAdSpace,#bottom_ad,#bottom_ad_area,#bottom_ad_unit,#bottom_ads,#bottom_banner_ad,#bottom_overture,#bottom_sponsor_ads,#bottom_sponsored_links,#bottom_text_ad,#bottomad,#bottomads,#bottomadsense,#bottomadwrapper,#bottomleaderboardad,#box-content-ad,#box-googleadsense-1,#box-googleadsense-r,#box1ad,#boxAd300,#boxAdContainer,#box_ad,#box_advertisment,#box_mod_googleadsense,#boxad1,#boxad2,#boxad3,#boxad4,#boxad5,#bpAd,#bps-header-ad-container,#btr_horiz_ad,#burn_header_ad,#button-ads-horizontal,#button-ads-vertical,#buttonAdWrapper1,#buttonAdWrapper2,#buttonAds,#buttonAdsContainer { visibility:hidden !important; display:none !important; } #button_ad_container,#button_ad_wrap,#buttonad,#buy-sell-ads,#c4ad-Middle1,#c_ad_sb,#c_ad_sky,#caAdLarger,#catad,#category-ad,#cellAd,#channel_ad,#channel_ads,#ciHomeRHSAdslot,#circ_ad,#cnnRR336ad,#cnnTopAd,#cnnVPAd,#col3_advertising,#colAd,#colRightAd,#collapseobj_adsection,#column4-google-ads,#comments-ad-container,#commercial_ads,#common_right_ad_wrapper,#common_right_lower_ad_wrapper,#common_right_lower_adspace,#common_right_lower_player_ad_wrapper,#common_right_lower_player_adspace,#common_right_player_ad_wrapper,#common_right_player_adspace,#common_right_right_adspace,#common_top_adspace,#companion-ad,#companionAdDiv,#companionad,#containerLocalAds,#containerLocalAdsInner,#containerMrecAd,#containerSqAd,#content-ad-header,#content-header-ad,#content-left-ad,#content-right-ad,#contentBoxad,#contentTopAds2,#content_ad_square,#content_ad_top,#content_ads_content,#content_box_300body_sponsoredoffers,#content_box_adright300_google,#content_mpu,#contentad,#contentad_imtext,#contentad_right,#contentads,#contentinlineAd,#contextad,#contextual-ads,#contextual-ads-block,#contextualad,#coverads,#ctl00_Adspace_Top_Height,#ctl00_BottomAd,#ctl00_ContentMain_BanManAd468_BanManAd,#ctl00_ContentPlaceHolder1_blockAdd_divAdvert,#ctl00_ContentRightColumn_RightColumn_Ad1_BanManAd,#ctl00_ContentRightColumn_RightColumn_Ad2_BanManAd,#ctl00_ContentRightColumn_RightColumn_PremiumAd1_ucBanMan_BanManAd,#ctl00_LHTowerAd,#ctl00_LeftHandAd,#ctl00_MasterHolder_IBanner_adHolder,#ctl00_TopAd,#ctl00_TowerAd,#ctl00_VBanner_adHolder,#ctl00__Content__RepeaterReplies_ctl03__AdReply,#ctl00_abot_bb,#ctl00_adFooter,#ctl00_advert_LargeMPU_div_AdPlaceHolder,#ctl00_atop_bt,#ctl00_cphMain_hlAd1,#ctl00_cphMain_hlAd2,#ctl00_cphMain_hlAd3,#ctl00_ctl00_MainPlaceHolder_itvAdSkyscraper,#ctl00_ctl00_ctl00_Main_Main_PlaceHolderGoogleTopBanner_MPTopBannerAd,#ctl00_ctl00_ctl00_Main_Main_SideBar_MPSideAd,#ctl00_dlTilesAds,#ctl00_m_skinTracker_m_adLBL,#ctl00_phCrackerMain_ucAffiliateAdvertDisplayMiddle_pnlAffiliateAdvert,#ctl00_phCrackerMain_ucAffiliateAdvertDisplayRight_pnlAffiliateAdvert,#ctrlsponsored,#cubeAd,#cube_ads,#cube_ads_inner,#cubead,#cubead-2,#dItemBox_ads,#dart_160x600,#dc-display-right-ad-1,#dcol-sponsored,#defer-adright,#detail_page_vid_topads,#div-gpt-ad-1,#div-gpt-ad-2,#div-gpt-ad-3,#div-gpt-ad-4,#divAdBox,#divAdWrapper,#divDoubleAd,#divLeftAd12,#divLeftRecAd,#divMenuAds,#divWNAdHeader,#divWrapper_Ad,#div_ad_leaderboard,#div_video_ads,#dlads,#dni-header-ad,#dnn_adLeaderBoard2008,#dnn_ad_banner,#download_ads,#dp_ads1,#ds-mpu,#editorsmpu,#embedded-ad,#evotopTen_advert,#ex-ligatus,#exads,#featured-advertisements,#featuredAdContainer2,#featuredAds,#feed_links_ad_container,#first-300-ad,#first-adlayer,#first_ad_unit,#firstad,#fl_hdrAd,#flash_ads_1,#flexiad,#footad,#footer-ad,#footer-advert,#footer-adverts,#footer-sponsored,#footerAd,#footerAdDiv,#footerAds,#footerAdvertisement,#footerAdverts,#footer_ad_01,#footer_ad_block,#footer_ad_container,#footer_ad_modules,#footer_adspace,#footer_text_ad,#footerad,#footerads,#footeradsbox,#forum_top_ad,#fpad1,#fpad2,#fpv_companionad,#fr_ad_center,#frame_admain,#frnAdSky,#frnBannerAd,#frnContentAd,#from_our_sponsors,#front_advert,#front_mpu,#ft-ad,#ft-ad-1,#ft-ad-container,#ft_mpu,#fusionad,#fw-advertisement,#g_ad,#g_adsense,#ga_300x250,#gad,#gad2,#gad3,#gad5,#galleries-tower-ad,#gallery-ad-m0,#gallery_ads,#game-info-ad,#gasense,#gglads,#global_header_ad_area,#gmi-ResourcePageAd,#gmi-ResourcePageLowerAd,#goads,#gooadtop,#google-ad,#google-ad-art,#google-ad-table-right,#google-ad-tower,#google-ads,#google-ads-bottom,#google-ads-header,#google-ads-left-side,#google-adsense-mpusize,#googleAd,#googleAds,#googleAdsSml,#googleAdsense,#googleAdsenseBanner,#googleAdsenseBannerBlog,#googleAdwordsModule,#googleAfcContainer,#googleSearchAds,#googleShoppingAdsRight,#googleShoppingAdsTop,#googleSubAds,#google_ad,#google_ad_container,#google_ad_inline,#google_ad_test,#google_ads,#google_ads_aCol,#google_ads_frame1,#google_ads_frame1_anchor,#google_ads_frame2,#google_ads_frame2_anchor,#google_ads_frame3,#google_ads_frame3_anchor,#google_ads_test,#google_ads_top,#google_adsense_home_468x60_1,#googlead2,#googleadbox,#googleads,#googleadsense,#googlesponsor,#gpt-ad-halfpage,#gpt-ad-rectangle1,#gpt-ad-rectangle2,#gpt-ad-skyscraper,#gpt-ad-story_rectangle3,#grid_ad,#gsyadrectangleload,#gsyadrightload,#gsyadtop,#gsyadtopload,#gtopadvts,#half-page-ad,#halfPageAd,#halfe-page-ad-box,#hd-ads,#hd-banner-ad,#hdtv_ad_ss,#headAd,#head_advert,#headad,#header-ad,#header-ad-rectangle-container,#header-ads,#header-adspace,#header-advert,#header-advertisement,#header-advertising,#header-adverts,#headerAd,#headerAdBackground,#headerAdContainer,#headerAdWrap,#headerAds,#headerAdsWrapper,#headerTopAd,#header_ad_728_90,#header_ad_container,#header_adcode,#header_ads,#header_advertisement_top,#header_leaderboard_ad_container,#header_publicidad,#headerad,#headeradbox,#headerads,#headeradsbox,#headeradwrap,#headline_ad,#headlinesAdBlock,#hiddenadAC,#hideads,#hl-sponsored-results,#hly_ad_side_bar_tower_left,#home-advert-module,#home-rectangle-ad,#home-sponsors-module,#homeMPU,#homeTopRightAd,#home_ad,#home_bottom_ad,#home_contentad,#home_feature_ad,#home_mpu,#home_spensoredlinks,#homepage-ad,#homepageAdsTop,#homepageFooterAd,#homepage_right_ad,#homepage_right_ad_container,#homepage_top_ads,#hometop_234x60ad,#hor_ad,#horizontal-banner-ad,#horizontal_ad,#horizontal_ad_top,#horizontalads,#houseAd,#hp-header-ad,#hp-right-ad,#hp-store-ad,#hpV2_300x250Ad,#hpV2_googAds,#hp_ad300x250,#icePage_SearchLinks_AdRightDiv,#icePage_SearchLinks_DownloadToolbarAdRightDiv,#icePage_SearchResults_ads0_SponsoredLink,#icePage_SearchResults_ads1_SponsoredLink,#icePage_SearchResults_ads2_SponsoredLink,#icePage_SearchResults_ads3_SponsoredLink,#icePage_SearchResults_ads4_SponsoredLink,#imu_ad_module,#in_serp_ad,#inadspace,#indexad,#inline-story-ad,#inlineAd,#inlinead,#inlinegoogleads,#inlist-ad-block,#inner-advert-row,#innerpage-ad,#inside-page-ad,#insider_ad_wrapper,#instoryad,#instoryadtext,#instoryadwrap,#int-ad,#interstitial_ad_wrapper,#islandAd,#j_ad,#ji_medShowAdBox,#jmp-ad-buttons,#joead,#joead2,#ka_adRightSkyscraperWide,#kdz_ad1,#kdz_ad2,#landing-adserver,#lapho-top-ad-1,#largead,#lateAd,#layerAds_layerDiv,#layerTLDADSERV,#lb-sponsor-left,#lb-sponsor-right,#leader-board-ad,#leader-sponsor,#leaderAd,#leaderAdContainer,#leader_board_ad,#leaderad,#leaderad_section,#leaderboard-ad,#leaderboard-bottom-ad,#leaderboard_ad,#left-ad-skin,#left-lower-adverts,#left-lower-adverts-container,#leftAdContainer,#leftAd_rdr,#leftAdvert,#leftSectionAd300-100,#left_ad,#left_adspace,#leftad,#leftads,#leftcolAd,#lg-banner-ad,#ligatus,#linkAds,#linkads,#live-ad,#logoAd,#longAdSpace,#lowerAdvertisementImg,#lowerads,#lowerthirdad,#lowertop-adverts,#lowertop-adverts-container,#lpAdPanel,#lrecad,#lsadvert-left_menu_1,#lsadvert-left_menu_2,#lsadvert-top,#mBannerAd,#main-ad,#main-ad160x600,#main-ad160x600-img,#main-ad728x90,#main-bottom-ad,#mainAdUnit,#mainAdvert,#main_ad,#main_rec_ad,#main_top_ad_container,#marketing-promo,#mastAd,#mastAdvert,#mastad,#mastercardAd,#masthead_ad,#masthead_topad,#medRecAd,#media_ad,#mediaplayer_adburner,#mediumAdvertisement,#medrectad,#menuAds,#mi_story_assets_ad,#mid-ad300x250,#mid-table-ad,#midRightTextAds,#mid_ad_div,#mid_ad_title,#mid_mpu,#midadd,#midadspace,#middle-ad,#middlead,#midrect_ad,#midstrip_ad,#mini-ad,#mochila-column-right-ad-300x250,#mochila-column-right-ad-300x250-1,#module-google_ads,#module_ad,#module_box_ad,#module_sky_scraper,#monsterAd,#moogleAd,#most_popular_ad,#motionAd,#mpu,#mpu-advert,#mpu300250,#mpuAd,#mpuDiv,#mpuSlot,#mpuWrapper,#mpuWrapperAd,#mpu_banner,#mpu_holder,#mpu_text_ad,#mpuad,#mr_banner_topad,#mrecAdContainer,#msAds,#ms_ad,#msad,#multiLinkAdContainer,#multi_ad,#myads_HeaderButton,#n_sponsor_ads,#namecom_ad_hosting_main,#narrow_ad_unit,#natadad300x250,#national_microlink_ads,#nationalad,#navi_banner_ad_780,#nba160PromoAd,#nba300Ad,#nbaHouseAnd600Ad,#nbaLeft600Ad,#nbaMidAds,#nbaVid300Ad,#nbcAd300x250,#new_topad,#newads,#ng_rtcol_ad,#noresults_ad_container,#noresultsads,#northad,#ns_ad1,#ns_ad2,#ns_ad3,#oanda_ads,#onespot-ads,#online_ad,#p-googleadsense,#page-header-ad,#page-top-ad,#pageAds,#pageAdsDiv,#pageBannerAd,#page_content_top_ad,#pagelet_adbox,#pagelet_netego_ads,#pagelet_search_ads2,#panelAd,#pb_report_ad,#pcworldAdBottom,#pcworldAdTop,#pinball_ad,#player-below-advert,#player_ad,#player_ads,#pod-ad-video-page,#populate_ad_bottom,#populate_ad_left,#portlet-advertisement-left,#portlet-advertisement-right,#post-promo-ad,#post5_adbox,#post_ad,#premium_ad,#priceGrabberAd,#prime-ad-space,#print_ads,#product-adsense,#promoAds,#ps-vertical-ads,#pub468x60,#publicidad,#pushdown_ad,#qm-ad-big-box,#qm-ad-sky,#qm-dvdad,#r1SoftAd,#rail_ad1,#rail_ad2,#realEstateAds,#rectAd,#rect_ad,#rectangle-ad,#rectangle_ad,#refine-300-ad,#region-node-advert,#region-top-ad,#rh-ad-container,#rh_tower_ad,#rhapsodyAd,#rhs_ads,#rhsadvert,#right-ad,#right-ad-skin,#right-ad-title,#right-ad1,#right-ads-3,#right-box-ad,#right-featured-ad,#right-mpu-1-ad-container,#right-uppder-adverts,#right-uppder-adverts-container,#rightAd,#rightAd300x250,#rightAdBar,#rightAdColumn,#rightAd_rdr,#rightAdsDiv,#rightColAd,#rightColumnMpuAd,#rightColumnSkyAd,#rightTopSponsor,#right_ad_wrapper,#right_ads,#right_advertisement,#right_advertising,#right_column_ad_container,#right_column_ads,#right_column_internal_ad_container,#right_column_top_ad_unit,#rightad,#rightadContainer,#rightadvertbar-doubleclickads,#rightbar-ad,#rightcolumn_300x250ad,#rightside-ads,#rightside_ad,#righttop-adverts,#righttop-adverts-container,#rm_ad_text,#ros_ad,#rotatingads,#row2AdContainer,#rr_MSads,#rt-ad,#rt-ad-top,#rt-ad468,#rtMod_ad,#rtmod_ad,#sAdsBox,#sb-ad-sq,#sb_ad_links,#sb_advert,#sb_sponsors,#search-google-ads,#search-sponsored-links,#search-sponsored-links-top,#searchAdSenseBox,#searchAdSenseBoxAd,#searchAdSkyscraperBox,#search_ads,#search_result_ad,#sec_adspace,#second-adlayer,#secondBoxAdContainer,#secondrowads,#section-ad-1-728,#section-ad-300-250,#section-ad-4-160,#section-blog-ad,#section-container-ddc_ads,#section-sponsors,#section_advertorial_feature,#servfail-ads,#sew-ad1,#shoppingads,#show-ad,#showAd,#showad,#side-ad,#side-ad-container,#sideAd,#sideAdSub,#sideBarAd,#side_ad,#side_ad_wrapper,#side_ads_by_google,#side_sky_ad,#sidead,#sideads,#sideadtop-to,#sidebar-125x125-ads,#sidebar-125x125-ads-below-index,#sidebar-ad,#sidebar-ad-boxes,#sidebar-ad-space,#sidebar-ad-wrap,#sidebar-ad3,#sidebar2ads,#sidebar_ad,#sidebar_ad_widget,#sidebar_ads_180,#sidebar_sponsoredresult_body,#sidebar_txt_ad_links,#sidebarad,#sidebaradver_advertistxt,#sideline-ad,#single-mpu,#singlead,#site-leaderboard-ads,#site_top_ad,#sitead,#sky-ad,#skyAd,#skyAdContainer,#skyScrapperAd,#skyWrapperAds,#sky_ad,#sky_advert,#skyads,#skyadwrap,#skyline_ad,#skyscraper-ad,#skyscraperAd,#skyscraperAdContainer,#skyscraper_ad,#skyscraper_advert,#skyscraperad,#slide_ad,#sliderAdHolder,#slideshow_ad_300x250,#sm-banner-ad,#small_ad,#small_ads,#smallerAd,#some-ads,#some-more-ads,#specialAd_one,#specialAd_two,#specialadvertisingreport_container,#specials_ads,#speeds_ads,#speeds_ads_fstitem,#speedtest_mrec_ad,#sphereAd,#sponLinkDiv_1,#sponlink,#sponlinks,#sponsAds,#sponsLinks,#spons_left,#sponseredlinks,#sponsor-search,#sponsorAd1,#sponsorAd2,#sponsorAdDiv,#sponsorLinks,#sponsorTextLink,#sponsor_banderole,#sponsor_box,#sponsor_deals,#sponsor_panSponsor,#sponsor_recommendations,#sponsorbar,#sponsorbox,#sponsored-ads,#sponsored-features,#sponsored-links,#sponsored-resources,#sponsored1,#sponsoredBox1,#sponsoredBox2,#sponsoredLinks,#sponsoredList,#sponsoredResults,#sponsoredResultsWide,#sponsoredSiteMainline,#sponsoredSiteSidebar,#sponsored_ads_v4,#sponsored_content,#sponsored_game_row_listing,#sponsored_links,#sponsored_v12,#sponsoredads,#sponsoredlinks,#sponsoredlinks_cntr,#sponsoredlinkslabel,#sponsoredresults_top,#sponsoredwellcontainerbottom,#sponsoredwellcontainertop,#sponsorfull,#sponsoring_bar,#sponsorlink,#sponsors,#sponsors_top_container,#sponsorshipBadge,#spotlightAds,#spotlightad,#sqAd,#square-sponsors,#squareAd,#squareAdSpace,#squareAds,#square_ad,#start_middle_container_advertisment,#sticky-ad,#stickyBottomAd,#story-90-728-area,#story-ad-a,#story-ad-b,#story-leaderboard-ad,#story-sponsoredlinks,#storyAd,#storyAdWrap,#storyad2,#subpage-ad-right,#subpage-ad-top,#swads,#synch-ad,#systemad_background,#tabAdvertising,#takeoverad,#tblAd,#tbl_googlead,#tcwAd,#td-GblHdrAds,#template_ad_leaderboard,#tertiary_advertising,#text-ad,#text-ads,#text-link-ads,#textAd,#textAds,#text_ad,#text_ads,#text_advert,#textad,#textad3,#the-last-ad-standing,#thefooterad,#themis-ads,#tile-ad,#tmglBannerAd,#tmp2_promo_ad,#toolbarSlideUpAd,#top-ad,#top-ad-container,#top-ad-menu,#top-ads,#top-ads-tabs,#top-advertisement,#top-banner-ad,#top-search-ad-wrapper,#topAd728x90,#topAdBanner,#topAdBox,#topAdContainer,#topAdSenseDiv,#topAdcontainer,#topAds,#topAdsContainer,#topAdvert,#topBannerAdContainer,#topContentAdTeaser,#topNavLeaderboardAdHolder,#topRightBlockAdSense,#top_ad_area,#top_ad_banner,#top_ad_game,#top_ad_unit,#top_ad_wrapper,#top_ad_zone,#top_ads,#top_advertise,#top_advertising,#top_rectangle_ad,#top_right_ad,#top_wide_ad,#topad1,#topad2,#topad_left,#topad_right,#topadbar,#topadblock,#topaddwide,#topadsense,#topadspace,#topadzone,#topbanner_ad,#topbar-ad,#topcustomad,#topleaderboardad,#topnav-ad-shell,#topnavad,#toprightAdvert,#toprightad,#topsponsored,#toptextad,#tour300Ad,#tourSponsoredLinksContainer,#towerad,#ts-ad_module,#ttp_ad_slot1,#ttp_ad_slot2,#twogamesAd,#txt_link_ads,#undergameAd,#upperAdvertisementImg,#upperMpu,#upperad,#urban_contentad_1,#urban_contentad_2,#urban_contentad_article,#v_ad,#vert_ad,#vert_ad_placeholder,#vertical_ad,#vertical_ads,#videoAd,#video_ads_overdiv,#video_cnv_ad,#video_overlay_ad,#videoadlogo,#viewportAds,#viewvid_ad300x250,#walltopad,#weblink_ads_container,#welcomeAdsContainer,#welcome_ad_mrec,#welcome_advertisement,#wf_ContentAd,#wf_FrontSingleAd,#wf_SingleAd,#wf_bottomContentAd,#wgtAd,#whatsnews_top_ad,#whitepaper-ad,#whoisRightAdContainer,#wide_ad_unit_top,#widget_advertisement,#wrapAdRight,#wrapAdTop,#wrapperAdsTopLeft,#wrapperAdsTopRight,#xColAds,#y-ad-units,#y708-ad-expedia,#y708-ad-lrec,#y708-ad-partners,#y708-ad-ysm,#y708-advertorial-marketplace,#yahoo-ads,#yahoo-sponsors,#yahooSponsored,#yahoo_ads,#yahoo_ads_2010,#yahoo_text_ad,#yahooad-tbl,#yan-sponsored,#yatadsky,#ybf-ads,#yfi_fp_ad_mort,#yfi_fp_ad_nns,#yfi_pf_ad_mort,#ygrp-sponsored-links,#ymap_adbanner,#yn-gmy-ad-lrec,#yreSponsoredLinks,#ysm_ad_iframe,#zoneAdserverMrec,#zoneAdserverSuper,.ADBAR,.ADPod,.AD_ALBUM_ITEMLIST,.AD_MOVIE_ITEM,.AD_MOVIE_ITEMLIST,.AD_MOVIE_ITEMROW,.Ad-Header,.Ad-MPU,.Ad1,.Ad120x600,.Ad160x600,.Ad160x600left,.Ad160x600right,.Ad2,.Ad247x90,.Ad300x,.Ad300x250,.Ad300x250L,.Ad728x90,.AdBorder,.AdBox7,.AdContainerBox308,.AdHeader,.AdHere,.AdMedium,.AdPlaceHolder,.AdProduct,.AdRingtone,.AdSenseLeft,.AdSlot,.AdSpace,.AdTextSmallFont,.AdUnit,.AdUnit300,.Ad_C,.Ad_D_Wrapper,.Ad_E_Wrapper,.Ad_Right,.AdsBoxBottom,.AdsBoxSection,.AdsBoxTop,.AdsLinks1,.AdsLinks2,.AdsRec,.AdvertMidPage,.AdvertiseWithUs,.AdvertisementTextTag,.ArticleAd,.ArticleInlineAd,.BannerAd,.BigBoxAd,.BlockAd,.BlueTxtAdvert,.BottomAdContainer,.BottomAffiliate,.BoxAd,.CG_adkit_leaderboard,.CG_details_ad_dropzone,.CWReviewsProdInfoAd,.ComAread,.CommentAd,.ContentAd,.ContentAds,.DAWRadvertisement,.DeptAd,.DisplayAd,.FT_Ad,.FlatAds,.GOOGLE_AD,.GoogleAd,.GoogleAdSenseBottomModule,.GoogleAdSenseRightModule,.HPG_Ad_B,.HPNewAdsBannerDiv,.HPRoundedAd,.HomeContentAd,.IABAdSpace,.InArticleAd,.IndexRightAd,.LazyLoadAd,.LeftAd,.LeftButtonAdSlot { visibility:hidden !important; display:none !important; } .LeftTowerAd,.M2Advertisement,.MD_adZone,.MOS-ad-hack,.MPU,.MPUHolder,.MPUTitleWrapperClass,.MREC_ads,.MiddleAd,.MiddleAdContainer,.NewsAds,.OAS,.OpaqueAdBanner,.OpenXad,.PU_DoubleClickAdsContent,.Post5ad,.Post9ad,.RBboxAd,.RW_ad300,.RectangleAd,.RelatedAds,.Right300x250AD,.RightAd1,.RightAdvertiseArea,.RightGoogleAFC,.RightRailTop300x250Ad,.RightSponsoredAdTitle,.RightTowerAd,.STR_AdBlock,.SideAdCol,.SidebarAd,.SidebarAdvert,.SitesGoogleAdsModule,.SkyAdContainer,.SponsorCFrame,.SponsoredAdTitle,.SponsoredContent,.SponsoredLinkItemTD,.SponsoredLinks,.SponsoredLinksGrayBox,.SponsoredLinksModule,.SponsoredLinksPadding,.SponsorshipText,.SquareAd,.StandardAdLeft,.StandardAdRight,.TRU-onsite-ads-leaderboard,.TextAd,.TheEagleGoogleAdSense300x250,.TopAd,.TopAdContainer,.TopAdL,.TopAdR,.TopBannerAd,.UIWashFrame_SidebarAds,.UnderAd,.VerticalAd,.Video-Ad,.VideoAd,.WidgetAdvertiser,.a160x600,.a728x90,.ad-120x600,.ad-160,.ad-160x600,.ad-250,.ad-300,.ad-300-block,.ad-300-blog,.ad-300x100,.ad-300x250,.ad-300x250-right0,.ad-350,.ad-355x75,.ad-600,.ad-635x40,.ad-728,.ad-728x90,.ad-728x90-1,.ad-728x90_forum,.ad-90x600,.ad-above-header,.ad-adlink-bottom,.ad-adlink-side,.ad-area,.ad-background,.ad-banner,.ad-bigsize,.ad-block,.ad-blog2biz,.ad-body,.ad-bottom,.ad-break,.ad-btn,.ad-btn-heading,.ad-cell,.ad-container-300x250,.ad-container-728x90,.ad-context,.ad-disclaimer,.ad-div,.ad-enabled,.ad-feedback,.ad-filler,.ad-flex,.ad-footer,.ad-footer-leaderboard,.ad-google,.ad-graphic-large,.ad-gray,.ad-hdr,.ad-head,.ad-header,.ad-heading,.ad-homeleaderboard,.ad-img,.ad-in-post,.ad-index-main,.ad-inline,.ad-island,.ad-label,.ad-leaderboard,.ad-links,.ad-lrec,.ad-medium,.ad-medium-two,.ad-mpu,.ad-msn,.ad-note,.ad-notice,.ad-other,.ad-permalink,.ad-placeholder,.ad-postText,.ad-poster,.ad-priority,.ad-rect,.ad-rectangle,.ad-rectangle-text,.ad-related,.ad-rh,.ad-ri,.ad-right,.ad-right-header,.ad-right-txt,.ad-row,.ad-section,.ad-show-label,.ad-side,.ad-sidebar-outer,.ad-sidebar300,.ad-sky,.ad-slot,.ad-slot-234-60,.ad-slot-300-250,.ad-slot-728-90,.ad-space,.ad-space-mpu-box,.ad-space-topbanner,.ad-spot,.ad-square,.ad-square300,.ad-squares,.ad-statement,.ad-story-inject,.ad-tabs,.ad-text-links,.ad-tile,.ad-title,.ad-top,.ad-top-left,.ad-unit,.ad-unit-300,.ad-unit-300-wrapper,.ad-unit-anchor,.ad-vert,.ad-vtu,.ad-wrap,.ad-wrapper,.ad-zone-s-q-l,.ad.super,.ad0,.ad08,.ad08sky,.ad10,.ad120,.ad120x240backgroundGray,.ad120x600,.ad125,.ad140,.ad160,.ad160x600,.ad160x600GrayBorder,.ad18,.ad19,.ad21,.ad230,.ad250,.ad250c,.ad3,.ad300,.ad300250,.ad300_250,.ad300x100,.ad300x250,.ad300x250-hp-features,.ad300x250Top,.ad300x250_container,.ad300x250box,.ad300x50-right,.ad300x600,.ad310,.ad336x280,.ad343x290,.ad4,.ad400right,.ad450,.ad468_60,.ad468x60,.ad6,.ad620x70,.ad626X35,.ad7,.ad728,.ad728_90,.ad728x90,.ad728x90_container,.ad8,.ad90x780,.adAgate,.adArea674x60,.adBanner,.adBanner300x250,.adBanner728x90,.adBannerTyp1,.adBannerTypSortableList,.adBannerTypW300,.adBar,.adBgBottom,.adBgMId,.adBgTop,.adBlock,.adBottomboxright,.adBoxBody,.adBoxBorder,.adBoxContainer,.adBoxContent,.adBoxInBignews,.adBoxSidebar,.adBoxSingle,.adBwrap,.adCMRight,.adCell,.adColumn,.adCont,.adContTop,.adContour,.adCreative,.adCube,.adFender3,.adFrame,.adFtr,.adFullWidthMiddle,.adGoogle,.adHeader,.adHeadline,.adHome300x250,.adHorisontal,.adInNews,.adLabel,.adLeader,.adLeaderForum,.adLeaderboard,.adLeft,.adLoaded,.adLocal,.adMPU,.adMarker,.adMastheadLeft,.adMastheadRight,.adMegaBoard,.adMkt2Colw,.adModuleAd,.adMpu,.adNewsChannel,.adNoOutline,.adNotice,.adNoticeOut,.adObj,.adPageBorderL,.adPageBorderR,.adPanel,.adRect,.adRight,.adSKY,.adSelfServiceAdvertiseLink,.adServer,.adSky,.adSky600,.adSkyscraperHolder,.adSlot,.adSpBelow,.adSpacer,.adSplash,.adSponsor,.adSpot,.adSpot-searchAd,.adSpot-textBox,.adSpot-twin,.adSpotIsland,.adSquare,.adSubColPod,.adSuperboard,.adSupertower,.adTD,.adTab,.adTag,.adTileWrap,.adTiler,.adTopboxright,.adTout,.adTxt,.adUnit,.adUnitHorz,.adUnitVert,.adUnitVert_noImage,.adWebBoard,.adWidget,.adWithTab,.adWrap,.adWrapper,.ad_0,.ad_1,.ad_120x90,.ad_125,.ad_130x90,.ad_160,.ad_160x600,.ad_2,.ad_200,.ad_200x200,.ad_250x250,.ad_250x250_w,.ad_3,.ad_300,.ad_300_250,.ad_300x250,.ad_300x250_box_right,.ad_336,.ad_336x280,.ad_350x100,.ad_350x250,.ad_400x200,.ad_468,.ad_468x60,.ad_600,.ad_728,.ad_728_90b,.ad_728x90,.ad_Left,.ad_amazon,.ad_banner,.ad_banner_border,.ad_bar,.ad_bg,.ad_bigbox,.ad_biz,.ad_block,.ad_block_338,.ad_body,.ad_border,.ad_botbanner,.ad_bottom,.ad_bottom_leaderboard,.ad_bottom_left,.ad_box,.ad_box2,.ad_box_ad,.ad_box_div,.ad_callout,.ad_caption,.ad_column,.ad_column_box,.ad_column_hl,.ad_contain,.ad_container,.ad_content,.ad_content_wide,.ad_contents,.ad_descriptor,.ad_disclaimer,.ad_eyebrow,.ad_footer,.ad_frame,.ad_framed,.ad_front_promo,.ad_head,.ad_heading,.ad_headline,.ad_hpm,.ad_info_block,.ad_inline,.ad_island,.ad_label,.ad_launchpad,.ad_leader,.ad_leaderboard,.ad_left,.ad_line,.ad_link,.ad_linkunit,.ad_loc,.ad_lrec,.ad_main,.ad_medrec,.ad_medrect,.ad_middle,.ad_mod,.ad_mpu,.ad_mr,.ad_mrec,.ad_mrec_title_article,.ad_mrect,.ad_news,.ad_note,.ad_notice,.ad_one,.ad_p360,.ad_partner,.ad_partners,.ad_plus,.ad_post,.ad_power,.ad_promo,.ad_rectangle,.ad_right_col,.ad_row,.ad_sidebar,.ad_skyscraper,.ad_slug,.ad_slug_table,.ad_space_300_250,.ad_sponsor,.ad_sponsoredsection,.ad_spot_b,.ad_spot_c,.ad_square_r,.ad_square_top,.ad_tag_middle,.ad_text_w,.ad_title,.ad_top,.ad_top_leaderboard,.ad_top_left,.ad_topright,.ad_tower,.ad_unit,.ad_unit_rail,.ad_url,.ad_warning,.ad_wid300,.ad_wide,.ad_wrap,.ad_wrapper,.ad_wrapper_fixed,.ad_wrapper_top,.ad_zone,.adarea,.adarea-long,.adbannerbox,.adbannerright,.adbar,.adboard,.adborder,.adbot,.adbottom,.adbottomright,.adbox-outer,.adbox-wrapper,.adbox_300x600,.adbox_366x280,.adbox_468X60,.adbox_bottom,.adboxclass,.adbreak,.adbug,.adbuttons,.adcode,.adcolumn,.adcolumn_wrapper,.adcopy,.add_300x250,.adfieldbg,.adfoot,.adfootbox,.adhead,.adhead_h,.adhead_h_wide,.adheader,.adheader100,.adhere,.adhered,.adhi,.adhint,.adhoriz,.adi,.adiframe,.adinside,.adintro,.adjlink,.adkicker,.adkit,.adkit-advert,.adkit-lb-footer,.adlabel-horz,.adlabel-vert,.adleader,.adleaderboard,.adleft1,.adline,.adlinks,.adlnklst,.admarker,.admedrec,.admessage,.admodule,.admpu,.admpu-small,.adnation-banner,.adnotice,.adops,.adp-AdPrefix,.adpadding,.adpane,.adprice,.adproxy,.adrec,.adroot,.adrotate_widget,.adrow,.adrow-post,.adrule,.ads-125,.ads-728x90-wrap,.ads-banner,.ads-below-content,.ads-categories-bsa,.ads-favicon,.ads-links-general,.ads-mpu,.ads-outer,.ads-profile,.ads-right,.ads-sidebar,.ads-sky,.ads-stripe,.ads-text,.ads-top,.ads-widget,.ads-widget-partner-gallery,.ads160,.ads1_250,.ads2,.ads3,.ads300,.ads460,.ads460_home,.ads468,.ads728,.ads728x90,.adsArea,.adsBelowHeadingNormal,.adsBox,.adsCell,.adsCont,.adsDiv,.adsFull,.adsImages,.adsMPU,.adsRight,.adsTextHouse,.adsTop,.adsTower2,.adsTowerWrap,.adsWithUs,.ads_125_square,.ads_180,.ads_300,.ads_300x250,.ads_320,.ads_337x280,.ads_728x90,.ads_big,.ads_big-half,.ads_box,.ads_brace,.ads_catDiv,.ads_container,.ads_disc_anchor,.ads_disc_leader,.ads_disc_lwr_square,.ads_disc_skyscraper,.ads_disc_square,.ads_div,.ads_footer,.ads_header,.ads_leaderboard,.ads_medrect,.ads_mpu,.ads_outer,.ads_rectangle,.ads_right,.ads_sc_bl_i,.ads_sc_tb,.ads_sc_tl_i,.ads_show_if,.ads_side,.ads_sidebar,.ads_singlepost,.ads_spacer,.ads_takeover,.ads_title,.ads_top,.ads_top_promo,.ads_tr,.ads_verticalSpace,.ads_vtlLink,.ads_widesky,.ads_wrapperads_top,.adsbg300,.adsblockvert,.adsborder,.adsbottom,.adsbox,.adsboxitem,.adsbyyahoo,.adsc,.adscaleAdvert,.adsclick,.adscontainer,.adscreen,.adsd_shift100,.adsection_a2,.adsection_c2,.adsense-ad,.adsense-category,.adsense-category-bottom,.adsense-googleAds,.adsense-heading,.adsense-overlay,.adsense-post,.adsense-right,.adsense-title,.adsense3,.adsense300,.adsenseAds,.adsenseBlock,.adsenseContainer,.adsenseGreenBox,.adsenseList,.adsense_bdc_v2,.adsense_mpu,.adsensebig,.adsenseblock,.adsenseblock_bottom,.adsenseblock_top,.adsenselr,.adsensem_widget,.adsensesq,.adsenvelope,.adset,.adsforums,.adsghori,.adsgvert,.adside,.adsidebox,.adsider,.adsingle,.adsleft,.adslink,.adslogan,.adsmalltext,.adsmessage,.adsnippet_widget,.adspace-MR,.adspace-widget,.adspace180,.adspace_bottom,.adspace_buysell,.adspace_rotate,.adspace_skyscraper,.adspacer,.adspot,.adspot728x90,.adstextpad,.adstitle,.adstop,.adstory,.adstrip,.adtag,.adtech,.adtext_gray,.adtext_horizontal,.adtext_onwhite,.adtext_vertical,.adtile,.adtips,.adtips1,.adtop,.adtravel,.adtxt,.adtxtlinks,.adunit,.adv-mpu,.adver,.adverTag,.adver_cont_below,.advert-300-side,.advert-300x100-side,.advert-728x90,.advert-article-bottom,.advert-bannerad,.advert-bg-250,.advert-box,.advert-head,.advert-iab-300-250,.advert-iab-468-60,.advert-mpu,.advert-skyscraper,.advert-text,.advert-txt,.advert300,.advert300x250,.advert300x440,.advert4,.advert5,.advert8,.advertColumn,.advertCont,.advertContainer,.advertHeadline,.advertRight,.advertText,.advertTitleSky,.advert_336,.advert_468x60,.advert_box,.advert_cont,.advert_djad,.advert_label,.advert_leaderboard,.advert_note,.advert_surr,.advert_top,.advertheader-red,.advertise-here,.advertise-homestrip,.advertise-horz,.advertise-inquiry,.advertise-leaderboard,.advertise-top,.advertise-vert,.advertiseContainer,.advertiseText,.advertise_ads,.advertise_here,.advertise_link,.advertise_link_sidebar,.advertisement-728x90,.advertisement-block,.advertisement-sidebar,.advertisement-space,.advertisement-sponsor,.advertisement-text,.advertisement-top,.advertisement468,.advertisementBox,.advertisementColumnGroup,.advertisementContainer,.advertisementHeader,.advertisementLabel,.advertisementPanel,.advertisement_btm,.advertisement_caption,.advertisement_g,.advertisement_header,.advertisement_horizontal,.advertisement_top,.advertiser-links,.advertisespace_div,.advertising-banner,.advertising-header,.advertising-local-links,.advertising2,.advertisingTable,.advertising_images,.advertisment_two,.advertize,.advertorial,.advertorial-2,.advertorial-promo-box,.advertorialtitle,.adverts-125,.advt,.advt-banner-3,.advt-block,.advt-sec,.advt300,.advt720,.adwordListings,.adwords,.adwordsHeader,.adwrap,.adwrapper-lrec,.adwrapper948,.adzone-footer,.adzone-sidebar,.affiliate-link,.affiliate-sidebar,.affiliateAdvertText,.affinityAdHeader,.afsAdvertising,.after_ad,.agi-adsaleslinks,.alb-content-ad,.alignads,.alt_ad,.anchorAd,.another_text_ad,.answer_ad_content,.aolSponsoredLinks,.aopsadvert,.apiAdMarkerAbove,.apiAds,.archive-ads,.art_ads,.article-ads,.articleAd,.articleAds,.articleAdsL,.articleEmbeddedAdBox,.article_ad,.article_adbox,.article_mpu_box,.article_page_ads_bottom,.articleads,.aseadn,.aux-ad-widget-1,.aux-ad-widget-2,.b-astro-sponsored-links_horizontal,.b-astro-sponsored-links_vertical,.banner-ad,.banner-ads,.banner-adverts,.banner300x100,.banner300x250,.banner468,.bannerAd,.bannerAdWrapper300x250,.bannerAdWrapper730x86,.bannerRightAd,.banner_300x250,.banner_ad,.banner_ad_footer,.banner_ad_leaderboard,.bannerad,.barkerAd,.base-ad-mpu,.base_ad,.base_printer_widgets_AdBreak,.bg-ad-link,.bgnavad,.big-ads,.bigAd,.big_ad,.big_ads,.bigad,.bigad2,.bigbox_ad,.bigboxad,.billboard_ad,.blk_advert,.block-ad,.block-ad300,.block-admanager,.block-ads-bottom,.block-ads-top,.block-adsense,.block-openads,.block-openadstream,.block-openx,.block-thirdage-ads,.block-wtg_adtech,.blockAd,.blockAds,.block_ad_sb_text,.block_ad_sponsored_links,.block_ad_sponsored_links-wrapper,.blockad,.blocked-ads,.blocsponsor,.blog-ad-leader-inner,.blog-ads-container,.blogAd,.blogAdvertisement,.blogArtAd,.blogBigAd,.blog_ad,.blogads,.blox3featuredAd,.body_ad,.body_sponsoredresults_bottom,.body_sponsoredresults_middle,.body_sponsoredresults_top,.bodyads,.bodyads2,.bookseller-header-advt,.bottom-ad,.bottomAd,.bottomAds,.bottom_ad,.bottom_ads,.bottom_adsense,.bottom_sponsor,.bottomad,.bottomadvert,.bottomrightrailAd,.bottomvidad,.box-ad,.box-ad-grey,.box-ads,.box-adsense,.boxAd,.boxAds,.box_ad,.box_ad_container,.box_ad_content,.box_ad_spacer,.box_ad_wrap,.box_ads,.box_advertising,.box_advertisment_62_border,.box_content_ad,.box_content_ads,.boxad,.boxyads,.bps-ad-wrapper,.bps-advertisement,.bps-advertisement-inline-ads,.br-ad,.breakad_container,.brokerad,.bsa_ads,.btm_ad,.btn-ad,.bullet-sponsored-links,.bullet-sponsored-links-gray,.burstContentAdIndex,.busrep_poll_and_ad_container,.buttonAd,.buttonAds,.buttonadbox,.bx_ad,.bx_ad_right,.cA-adStrap,.cColumn-TextAdsBox,.calloutAd,.care2_adspace,.catalog_ads,.category-ad,.category__big_game_container_body_games_advertising,.cb-ad-container,.cb_ads,.cb_footer_sponsor,.cb_navigation_ad,.cbstv_ad_label,.cbzadvert,.cbzadvert_block,.cdAdTitle,.cdmainlineSearchAdParent,.cdsidebarSearchAdParent,.centerAd,.center_ad,.centerad,.centered-ad,.chitikaAdCopy,.cinemabotad,.classifiedAdThree,.clearerad,.cm_ads,.cms-Advert,.cnbc_badge_banner_ad_area,.cnbc_banner_ad_area,.cnn160AdFooter,.cnnAd,.cnnMosaic160Container,.cnnSearchSponsorBox,.cnnStoreAd,.cnnStoryElementBoxAd,.cnnWCAdBox { visibility:hidden !important; display:none !important; } .cnnWireAdLtgBox,.cnn_728adbin,.cnn_adcntr300x100,.cnn_adcntr728x90,.cnn_adspc336cntr,.cnn_adtitle,.column2-ad,.columnRightAdvert,.com-ad-server,.comment-advertisement,.comment_ad_box,.common_advertisement_title,.communityAd,.conTSponsored,.conductor_ad,.confirm_ad_left,.confirm_ad_right,.confirm_leader_ad,.consoleAd,.container-adwords,.containerSqAd,.container_serendipity_plugin_google_adsense,.content-ad,.content-advert,.contentAdFoot,.contentAdsWrapper,.content_ad,.content_ad_728,.content_adsq,.contentad300x250,.contentad_right_col,.contentadcontainer,.contentadleft,.contentads,.contentadstartpage,.contenttextad,.contest_ad,.cp_ad,.cpmstarHeadline,.cpmstarText,.create_ad,.cs-mpu,.cscTextAd,.cse_ads,.cspAd,.ct_ad,.cube-ad,.cubeAd,.cube_ads,.currency_ad,.custom_ads,.cwAdvert,.darla_ad,.dartAdImage,.dart_ad,.dart_tag,.dartadvert,.dartiframe,.dc-ad,.dcAdvertHeader,.deckAd,.deckads,.detailMpu,.detail_ad,.detail_top_advert,.displayAdSlot,.divAd,.divAdright,.divad1,.divad2,.divad3,.divads,.divider_ad,.dmco_advert_iabrighttitle,.downloadAds,.download_ad,.downloadad,.dualAds,.dynamic-ads,.dynamic_ad,.e-ad,.ec-ads,.ec-ads-remove-if-empty,.em-ad,.embed-ad,.entry-body-ad,.entry_sidebar_ads,.entryad,.ez-clientAd,.f_Ads,.feature_ad,.featuredAds,.featuredadvertising,.firstpost_advert_container,.flagads,.flash-advertisement,.flash_ad,.flash_advert,.flashad,.flexiad,.flipbook_v2_sponsor_ad,.floatad,.floated_right_ad,.floatingAds,.fm-badge-ad,.footad,.footer-ad,.footerAd,.footerAdModule,.footerAdslot,.footerTextAd,.footer_ad,.footer_ads,.footer_block_ad,.footer_bottomad,.footer_line_ad,.footer_text_ad,.footerad,.forumtopad,.frn_adbox,.frn_cont_adbox,.frontads,.ft-ad,.ftdAdBar,.ftdContentAd,.full_ad_box,.fullbannerad,.g3rtn-ad-site,.gAdRows,.gAdSky,.gAdvertising,.g_ggl_ad,.ga-ads,.ga-textads-bottom,.ga-textads-top,.gaTeaserAdsBox,.gads,.gads_cb,.gads_container,.gallery_ad,.gam_ad_slot,.gameAd,.gamesPage_ad_content,.gbl_advertisement,.gen_side_ad,.gglAds,.global_banner_ad,.googad,.googads,.google-ad,.google-ad-container,.google-ads,.google-ads-boxout,.google-ads-slim,.google-right-ad,.google-sponsored-ads,.google-sponsored-link,.google468,.google468_60,.googleAd,.googleAd-content,.googleAd-list,.googleAd300x250_wrapper,.googleAdBox,.googleAdSense,.googleAdSenseModule,.googleAd_body,.googleAds,.googleAds_article_page_above_comments,.googleAdsense,.googleContentAds,.googleProfileAd,.googleSearchAd_content,.googleSearchAd_sidebar,.google_ad,.google_ad_wide,.google_add_container,.google_ads,.google_ads_bom_title,.google_ads_content,.googlead,.googleaddiv,.googleaddiv2,.googleads,.googleads_300x250,.googleads_title,.googleafc,.googley_ads,.gpAdBox,.gpAds,.gradientAd,.grey-ad-line,.group_ad,.gsAd,.gsfAd,.gt_ad,.gt_ad_300x250,.gt_ad_728x90,.gt_adlabel,.gutter-ad-left,.gutter-ad-right,.h-ad-728x90-bottom,.h_Ads,.h_ad,.half-ad,.half_ad_box,.hcf-ad-rectangle,.hcf-cms-ad,.hd_advert,.hdr-ads,.header-advert,.headerAds,.headerAdvert,.headerTextAd,.header_ad,.header_ad_div,.header_advertisement,.header_advertisment,.headerad,.headerad-720,.hi5-ad,.highlightsAd,.hm_advertisment,.hn-ads,.home-ad-links,.homeAd,.homeAd1,.homeAd2,.homeAdBoxA,.homeAdBoxBetweenBlocks,.homeAdBoxInBignews,.homeAdSection,.homeMediumAdGroup,.home_ad_bottom,.home_advertisement,.home_mrec_ad,.homead,.homepage-ad,.homepage300ad,.homepageFlexAdOuter,.homepageMPU,.homepage_middle_right_ad,.hor_ad,.horiz_adspace,.horizontalAd,.horizontal_ads,.horizontaltextadbox,.horizsponsoredlinks,.hortad,.houseAd1,.houseAdsStyle,.housead,.hp-col4-ads,.hp2-adtag,.hp_ad_cont,.hp_ad_text,.hp_t_ad,.hp_w_ad,.hpa-ad1,.html-advertisement,.ic-ads,.ico-adv,.idMultiAd,.image-advertisement,.imageads,.imgad,.in-page-ad,.in-story-ads,.in-story-text-ad,.indEntrySquareAd,.indie-sidead,.indy_googleads,.inhousead,.inline-ad,.inline-mpu,.inline-mpu-left,.inlineSideAd,.inline_ad,.inline_ad_title,.inlinead,.inlineadsense,.inlineadtitle,.inlist-ad,.inlistAd,.inner-advt-banner-3,.innerAds,.innerad,.inpostad,.insert_advertisement,.insertad,.insideStoryAd,.inteliusAd_image,.interest-based-ad,.internalAdsContainer,.is24-adplace,.isAd,.islandAd,.islandAdvert,.islandad,.jimdoAdDisclaimer,.jp-advertisment-promotional,.js-advert,.kw_advert,.kw_advert_pair,.l_ad_sub,.l_banner.ads_show_if,.labelads,.largeRecAdNewsContainerRight,.largeRectangleAd,.largeUnitAd,.lastRowAd,.lcontentbox_ad,.leaderAdSlot,.leaderAdTop,.leaderAdvert,.leaderBoardAdHolder,.leaderOverallAdArea,.leader_ad,.leaderboardAd,.leaderboardad,.leaderboardadtop,.left-ad,.leftAd,.leftAdColumn,.leftAds,.left_ad,.left_ad_box,.left_adlink,.left_ads,.left_adsense,.leftad,.leftadtag,.leftbar_ad_160_600,.leftbarads,.leftbottomads,.leftnavad,.lgRecAd,.lg_ad,.ligatus,.linead,.link_adslider,.link_advertise,.live-search-list-ad-container,.ljad,.local-ads,.log_ads,.logoAds,.logoad,.logoutAd,.longAd,.longAdBox,.lowerAds,.m-ad-tvguide-box,.m4-adsbygoogle,.m_banner_ads,.macAd,.macad,.main-ad,.main-advert,.main-tabs-ad-block,.main_ad,.main_ad_bg_div,.main_adbox,.main_intro_ad,.map_media_banner_ad,.marginadsthin,.marketing-ad,.masthead_topad,.matador_sidebar_ad_600,.mdl-ad,.media-advert,.mediaAd,.mediaAdContainer,.mediaResult_sponsoredSearch,.medium-rectangle-ad,.mediumRectangleAdvert,.medrect_ad,.menuItemBannerAd,.menueadimg,.messageBoardAd,.mf-ad300-container,.micro_ad,.mid_ad,.midad,.middleAds,.min_navi_ad,.mini-ad,.miniad,.mmcAd_Iframe,.mobile-sponsoring,.mod-ad-lrec,.mod-ad-n,.mod-adopenx,.mod-vertical-ad,.mod_admodule,.module-ad-small,.module-ads,.moduleAdvertContent,.module_ad,.module_box_ad,.modulegad,.moduletable-advert,.moduletable-googleads,.moduletablesquaread,.mpu-ad,.mpu-advert,.mpu-footer,.mpu-fp,.mpu-title,.mpu-top-left,.mpu-top-left-banner,.mpu-top-right,.mpu01,.mpuAd,.mpuAdSlot,.mpuAdvert,.mpuArea,.mpuBox,.mpuContainer,.mpuHolder,.mpuTextAd,.mpu_ad,.mpu_advert,.mpu_container,.mpu_gold,.mpu_holder,.mpu_platinum,.mpu_side,.mpu_text_ad,.mpuad,.mpuholderportalpage,.mrec_advert,.ms-ads-link,.msfg-shopping-mpu,.mvw_onPageAd1,.mwaads,.my-ad250x300,.nSponsoredLcContent,.nSponsoredLcTopic,.nadvt300,.narrow_ad_unit,.narrow_ads,.navAdsBanner,.navBads,.nav_ad,.navadbox,.navi_ad300,.naviad,.nba300Ad,.nbaT3Ad160,.nbaTVPodAd,.nbaTwo130Ads,.nbc_ad_carousel_wrp,.newTopAdContainer,.newad,.newsAd,.news_article_ad_google,.newsviewAdBoxInNews,.nf-adbox,.nn-mpu,.noAdForLead,.normalAds,.nrAds,.nsAdRow,.oas-ad,.oas-bottom-ads,.offer_sponsoredlinks,.oio-banner-zone,.oio-link-sidebar,.oio-zone-position,.on_single_ad_box,.onethirdadholder,.openads,.openadstext_after,.openx,.openx-ad,.osan-ads,.other_adv2,.outermainadtd1,.ovAdPromo,.ovAdSky,.ovAdartikel,.ov_spns,.pageGoogleAd,.pageGoogleAdFlat,.pageLeaderAd,.page_content_right_ad,.pagead,.pagenavindexcontentad,.paneladvert,.partner-ads-container,.partnersTextLinks,.pencil_ad,.player_ad_box,.player_hover_ad,.player_page_ad_box,.plista_inimg_box,.pnp_ad,.pod-ad-300,.podRelatedAdLinksWidget,.podSponsoredLink,.portalCenterContentAdBottom,.portalCenterContentAdMiddle,.portalCenterContentAdTop,.portalcontentad,.postAd,.post_ad,.post_ads,.post_sponsor_unit,.postbit_adbit_register,.postbit_adcode,.postgroup-ads,.postgroup-ads-middle,.prebodyads,.premium_ad_container,.promoAd,.promoAds,.promo_ad,.ps-ligatus_placeholder,.publication-ad,.publicidad,.puff-advertorials,.qa_ad_left,.qm-ad-content,.qm-ad-content-news,.quigo-ad,.qzvAdDiv,.r_ad_1,.r_ad_box,.r_ads,.rad_container,.rect_ad_module,.rectad,.rectangle-ad,.rectangleAd,.rectanglead,.redads_cont,.regular_728_ad,.regularad,.relatedAds,.related_post_google_ad,.remads,.resourceImagetAd,.result_ad,.results_sponsor,.results_sponsor_right,.reviewMidAdvertAlign,.rght300x250,.rhads,.rhs-ad,.rhs-ads-panel,.right-ad,.right-ad-holder,.right-ad2,.right-ads,.right-ads2,.right-sidebar-box-ad,.rightAdBox,.rightColAd,.rightColumnRectAd,.rightRailAd,.right_ad,.right_ad_160,.right_ad_box,.right_ad_common_block,.right_ad_text,.right_ad_top,.right_ads,.right_col_ad,.right_hand_advert_column,.right_side-partyad,.rightad_1,.rightad_2,.rightadbox1,.rightads,.rightadunit,.rightcol_boxad,.rightcoladvert,.rightcoltowerad,.rnav_ad,.rngtAd,.roundedCornersAd,.roundingrayboxads,.rt_ad1_300x90,.rt_ad_300x250,.rt_ad_call,.s2k_ad,.savvyad_unit,.sb-ad-sq-bg,.sbAd,.sbAdUnitContainer,.sb_ad_holder,.sb_adsN,.sb_adsNv2,.sb_adsW,.sb_adsWv2,.scanAd,.scc_advert,.sci-ad-main,.sci-ad-sub,.search-ad,.search-results-ad,.search-sponsor,.search-sponsored,.searchAd,.searchAds,.searchSponsoredResultsBox,.searchSponsoredResultsList,.search_column_results_sponsored,.search_results_sponsored_top,.section-ad2,.section-sponsor,.section_mpu_wrapper,.section_mpu_wrapper_wrapper,.selfServeAds,.sepContentAd,.serp_sponsored,.servsponserLinks,.shoppingGoogleAdSense,.showAd_No,.showAd_Yes,.showcaseAd,.sidbaread,.side-ad,.side-ads,.side-sky-banner-160,.sideAd,.sideBoxAd,.side_ad,.side_ad2,.side_ad_1,.side_ad_2,.side_ad_3,.sidead,.sideads,.sideadsbox,.sideadvert,.sidebar-ad,.sidebar-ads,.sidebar-text-ad,.sidebarAd,.sidebarAdUnit,.sidebarAdvert,.sidebar_ad,.sidebar_ad_300_250,.sidebar_ads,.sidebar_ads_336,.sidebar_adsense,.sidebar_box_ad,.sidebarad,.sidebarad_bottom,.sidebaradbox,.sidebarads,.sidebarboxad,.sideheadnarrowad,.sideheadsponsorsad,.singleAd,.singleAdsContainer,.singlead,.site_ad_120_600,.site_ad_300x250,.sitesponsor,.skinAd,.skin_ad_638,.sky-ad,.skyAd,.skyAdd,.skyAdvert,.sky_scraper_ad,.skyad,.skyjobsadtext,.skyscraper-ad,.skyscraper_ad,.skyscraper_bannerAdHome,.sleekadbubble,.slideshow-ad,.slpBigSlimAdUnit,.slpSquareAdUnit,.sm_ad,.smallSkyAd1,.smallSkyAd2,.small_ad,.small_ads,.smallad-left,.smallads,.smallsponsorad,.smart_ads_bom_title,.specialAd175x90,.speedyads,.sphereAdContainer,.spl-ads,.spl_ad,.spl_ad2,.spl_ad_plus,.splitAd,.sponlinkbox,.spons-link,.spons_links,.sponslink,.sponsor-ad,.sponsor-bottom,.sponsor-link,.sponsor-links,.sponsor-right,.sponsor-services,.sponsor-top,.sponsorArea,.sponsorBox,.sponsorPanel,.sponsorPost,.sponsorPostWrap,.sponsorStrip,.sponsorTop,.sponsor_ad_area,.sponsor_footer,.sponsor_horizontal,.sponsor_line,.sponsor_links,.sponsor_logo,.sponsor_top,.sponsor_units,.sponsoradtitle,.sponsorbox,.sponsored-ads,.sponsored-chunk,.sponsored-editorial,.sponsored-features,.sponsored-links,.sponsored-links-alt-b,.sponsored-links-holder,.sponsored-links-right,.sponsored-post,.sponsored-post_ad,.sponsored-results,.sponsored-right-border,.sponsored-text,.sponsoredBox,.sponsoredInfo,.sponsoredInner,.sponsoredLabel,.sponsoredLink,.sponsoredLinks,.sponsoredLinks2,.sponsoredLinksHeader,.sponsoredProduct,.sponsoredResults,.sponsoredSideInner,.sponsored_ads,.sponsored_box,.sponsored_box_search,.sponsored_by,.sponsored_links,.sponsored_links_title_container,.sponsored_links_title_container_top,.sponsored_links_top,.sponsored_results,.sponsored_well,.sponsoredibbox,.sponsoredlink,.sponsoredlinks,.sponsoredlinkscontainer,.sponsoredresults,.sponsoredtextlink_container_ovt,.sponsorlink,.sponsorlink2,.sponsormsg,.sponsors-box,.sponsors_bar,.sponsors_table,.sponsorshipbox,.sponsortable,.sponsortext,.sport-mpu-box,.spotlightAd,.squareAd,.square_ad,.square_banner_ad,.squared_ad,.ss-ad-mpu,.standard-ad,.start__newest__big_game_container_body_games_advertising,.staticAd,.stock-ticker-ad-tag,.stocks-ad-tag,.store-ads,.story_AD,.story_ad_div,.story_right_adv,.storyad,.storysponsorimage,.subad,.subcontent-ad,.subtitle-ad-container,.sugarad,.super-ad,.supercommentad_left,.supercommentad_right,.supp-ads,.supportAdItem,.surveyad,.t10ad,.tab_ad,.tab_ad_area,.tablebordersponsor,.tadsanzeige,.tadsbanner,.tadselement,.tallad,.tblTopAds,.tbl_ad,.tbox_ad,.td-Adholder,.teaser-sponsor,.teaserAdContainer,.teaser_adtiles,.text-ad-links,.text-advertisement,.text-g-advertisement,.text-g-group-short-rec-ad,.text-g-net-grp-google-ads-article-page,.textAd,.textAdBox,.textAds,.text_ad,.text_ads,.textad,.textadContainer,.textad_headline,.textadbox,.textadheadline,.textadlink,.textadsds,.textadsfoot,.textadtext,.textlink-ads,.tf_page_ad_search,.thisIsAd,.thisIsAnAd,.ticket-ad,.tileAds,.tips_advertisement,.title-ad,.title_adbig,.tncms-region-ads,.toolad,.toolbar-ad,.top-ad,.top-ad-space,.top-ads,.top-banner-ad,.top-menu-ads,.top-sponsors,.topAdWrap,.topAdvertisement,.topBannerAd,.topLeaderboardAd,.top_Ad,.top_ad,.top_ad_728,.top_ad_728_90,.top_ad_disclaimer,.top_ad_div,.top_ad_post,.top_ad_wrapper,.top_advert,.top_advertising_lb,.top_container_ad,.top_sponsor,.topad-bar,.topadbox,.topadspot,.topadvertisementsegment,.topcontentadvertisement,.topic_inad,.topstoriesad,.toptenAdBoxA,.tourFeatureAd,.tower-ad,.towerAd,.towerAdLeft,.towerAds,.tower_ad,.tower_ad_disclaimer,.towerad,.tribal-ad,.ts-ad_unit_bigbox,.ts-banner_ad,.ttlAdsensel,.tto-sponsored-element,.tucadtext,.tvs-mpu,.twoColumnAd,.twoadcoll,.twoadcolr,.tx_smartadserver_pi1,.txt-ads,.txtAd,.txtAds,.txt_ads,.txtadvertise,.type_adscontainer,.type_miniad,.type_promoads,.ukAds,.undertimyads,.unit-ad,.universalboxADVBOX01,.universalboxADVBOX03,.universalboxADVBOX04a,.usenext,.vertad,.vertical-adsense,.videoAd,.videoBoxAd,.video_ad,.view-promo-mpu-right,.view_rig_ad,.virgin-mpu,.wa_adsbottom,.wantads,.wide-ad,.wide-skyscraper-ad,.wideAd,.wideAdTable,.wide_ad,.wide_ad_unit_top,.wide_ads,.wide_google_ads,.widget-ad,.widget-ad300x250,.widget-entry-ads-160,.widgetYahooAds,.widget_ad,.widget_ad_rotator,.widget_island_ad,.widget_sdac_bottom_ad_widget,.widget_sdac_footer_ads_widget,.widget_sdac_skyscraper_ad_widget,.widget_sponsor,.wikia-ad,.wikia_ad_placeholder,.wingadblock,.withAds,.wl-ad,.wnMultiAd,.wp125_write_ads_widget,.wp125ad,.wp125ad_2,.wpn_ad_content,.wrap-ads,.wsSponsoredLinksRight,.wsTopSposoredLinks,.x03-adunit,.x04-adunit,.xads-blk2,.xads-ojedn,.y-ads,.y-ads-wide,.y7-advertisement,.yahoo-sponsored,.yahoo-sponsored-links,.yahooAds,.yahoo_ads,.yan-sponsored,.ygrp-ad,.yrail_ad_wrap,.yrail_ads,.ysmsponsor,.ysponsor,.yw-ad,a[href^="http://ad.doubleclick.net/"],a[href^="http://adserving.liveuniversenetwork.com/"],a[href^="http://galleries.pinballpublishernetwork.com/"],a[href^="http://galleries.securewebsiteaccess.com/"],a[href^="http://install.securewebsiteaccess.com/"],a[href^="http://latestdownloads.net/download.php?"],a[href^="http://secure.signup-page.com/"],a[href^="http://secure.signup-way.com/"],a[href^="http://www.FriendlyDuck.com/AF_"],a[href^="http://www.adbrite.com/mb/commerce/purchase_form.php?"],a[href^="http://www.friendlyduck.com/AF_"],a[href^="http://www.google.com/aclk?"],a[href^="http://www.liutilities.com/aff"],a[href^="http://www.liutilities.com/products/campaigns/adv/"],a[href^="http://www.my-dirty-hobby.com/?sub="],a[href^="http://www.ringtonematcher.com/"],#mclip_container:last-child,#tads.c,#tadsb.c,.ch[onclick="ga(this,event)"],.ra[align="left"][width="30%"],.ra[align="right"][width="30%"],#adv,.advblock,#advertblock,.advertblock,#AFF_popup,#cyberinfrm_18,#eropromo_icq,#floatyContent { visibility:hidden !important; display:none !important; } #fp_adv,#fp_banner,#im_popupDiv,#magnaInformer,#marketgid,#novem_billboard,#PopWin[onmousemove],#radeant,#zhlobam_net_informer_console,.adbckgrnd,.bc_adv_container,.bc-adv,.madv,.mc_cars_row,.modul-search,.module-one-search,.reklam,.sp_search_table,.sp_search2_table,.sp_search3_table,.surbis_banner,.topbaner,BODY[onload="popupInit();"] > #popUp,DIV[id^="DIV_NNN_"],DIV[id^="rtn4p"],DIV[id^="Teaser_Block"],DIV[id^="togetInformer_"],[class^="snBody"],.mediaget,A[href*="/download.php?sub_id="][href*="&q="],A[href*="/download.php?user_id="][href*="&q="],BODY > #flydiv,IMG[width="120"][height="600"],IMG[width="160"][height="600"],IMG[width="468"][height="60"],IMG[width="728"][height="90"],#adriver_middle,A[href*=".ru/fn.php?r="],A[href*=".ru/newfn/?go="],#yandex,[src*="sixsigmatraffic.com"],embed[flashvars*="AdID"],#Ad1,#AdHeader,#Adbanner,#AdvertiseFrame,#Advertisement,#Advertisements,#Tadspacehead,#TopAd,#ad-container,#ad-header,#ad-top,#ad-wrapper,#ad1,#ad3,#ad728x90,#adBanner,#adComponentWrapper,#adContainer,#adDiv,#adHeader,#adTop,#adWrapper,#ad_area,#ad_container,#ad_leader,#ad_space,#ad_square,#ad_table,#ad_wrapper,#adbody,#adbox,#adposition3,#adsense,#adsense_inline,#adspace,#advert,#advertise,#advertising,#adverts,#adwrapper,#bannerad,#block_advert,#contentAd,#content_ad,#divAd,#featuread,#footer_ad,#footer_ads,#googlead,#head-ad,#header_ad,#mainAd,#middleads,#printads,#promo-ad,#right_ad,#sidebar-ads,#sidebar_ads,#sponsored,#topAd,#topBannerAd,#top_ad,#topad,#topads,.AdBox,.AdInfo,.AdSense,.AdTitle,.Ads,.Advert,.ad-box,.ad-button,.ad-container,.ad-content,.ad-display,.ad-holder,.ad-sidebar,.ad-text,.ad-vertical-container,.ad1,.ad2,.ad468,.adBox,.adContainer,.adDiv,.adElement,.adHolder,.adModule,.adSpace,.adSummary,.adText,.adTitle,.ad_Right,.ad_header,.ad_links,.ad_right,.ad_space,.ad_text,.adbanner,.adbox,.adcol1,.adcol2,.adcont,.addiv,.adframe,.adholder,.adinfo,.adlink,.adlist,.adpic,.adright,.ads-section,.adsBlock,.adspace,.adtable,.adtext,.advert-horizontal,.advert_list,.advertise,.advertisement,.advertiser,.advertising,.advertising_block,.advertisment,.adverts,.adwrapper,.affiliate,.banner_728x90,.block_ad,.bottom_ad_block,.contentAd,.contentad,.detail-ads,.header-ad,.headerAd,.header_ad_center,.horizontal_ad,.middleads,.module-ad,.mpu,.post-ad,.rightAd,.right_ads_column,.rightad,.sky_ad,.sponsored,.sponsors,.textads,.topAd,.topAds,.top_ads,.topad,.topads,a[href^="http://ad-emea.doubleclick.net/"],#advblock,DIV[id^="MarketGid"] { visibility:hidden !important; display:none !important; }</style></html>
|