mirror of
https://github.com/uw-imap/imap.git
synced 2025-07-13 14:34:24 +02:00
Source from upstream; imap-2007f.tar.gz
MD5 2126fd125ea26b73b20f01fcd5940369
This commit is contained in:
Chris
70
docs/rfc/README
Normal file
70
docs/rfc/README
Normal file
@ -0,0 +1,70 @@
|
||||
The following documents are necessary to understand the syntax rules
|
||||
most of the remaining documents. Note that some documents refer to
|
||||
RFC 2234 which has been replaced by RFC 5234:
|
||||
rfc5234.txt Augmented BNF for Syntax Specifications - ABNF
|
||||
rfc4466.txt Collected Extensions to IMAP4 ABNF
|
||||
|
||||
|
||||
The following documents specify the IMAP protocol:
|
||||
rfc3501.txt Internet Message Access Protocol - Version 4rev1
|
||||
|
||||
|
||||
The following documents provide additional information which is useful
|
||||
in understanding the IMAP protocol:
|
||||
rfc1733.txt Distributed Electronic Mail Models in IMAP4
|
||||
rfc2180.txt IMAP4 Multi-Accessed Mailbox Practice
|
||||
rfc2683.txt IMAP4 Implementation Recommendations
|
||||
rfc4549.txt Synchronization Operations for Disconnected IMAP4 Clients
|
||||
|
||||
|
||||
The following documents describe extensions to the IMAP protocol.
|
||||
Items marked with "*" are supported in this distribution:
|
||||
rfc4314.txt ACL
|
||||
* rfc3516.txt BINARY
|
||||
rfc4469.txt CATENATE
|
||||
* rfc3348.txt CHILDREN
|
||||
rfc4978.txt COMPRESS
|
||||
rfc4551.txt CONDSTORE
|
||||
rfc5161.txt ENABLE
|
||||
* rfc4731.txt ESEARCH
|
||||
rfc2971.txt ID
|
||||
* rfc2177.txt IDLE
|
||||
* rfc2088.txt LITERAL+
|
||||
* rfc2221.txt LOGIN-REFERRALS
|
||||
* rfc2193.txt MAILBOX-REFERRALS
|
||||
* rfc3502.txt MULTIAPPEND
|
||||
* rfc2342.txt NAMESPACE
|
||||
rfc5162.txt QRESYNC
|
||||
rfc2087.txt QUOTA
|
||||
* rfc4959.txt SASL-IR
|
||||
* rfc4315.txt UIDPLUS
|
||||
* rfc3691.txt UNSELECT
|
||||
rfc4467.txt URLAUTH
|
||||
* rfc5032.txt WITHIN
|
||||
|
||||
|
||||
The following documents describe SASL:
|
||||
rfc4422.txt Simple Authentication and Security Layer (SASL)
|
||||
and the SASL mechanisms supported in this distribution:
|
||||
rfc4505.txt ANONYMOUS
|
||||
rfc2195.txt CRAM-MD5
|
||||
rfc4752.txt GSSAPI
|
||||
rfc4616.txt PLAIN
|
||||
|
||||
|
||||
The following documents relate to internationalization issues:
|
||||
rfc4790.txt Internet Application Protocol Collation Registry
|
||||
rfc5051.txt i;unicode-casemap - Simple Unicode Collation Algorithm
|
||||
|
||||
|
||||
The following documents are primarily of historic interest:
|
||||
rfc1732.txt IMAP4 Compatibility with IMAP2 and IMAP2bis
|
||||
rfc2061.txt IMAP4 Compatibility with IMAP2bis
|
||||
rfc2062.txt Internet Message Access Protocol - Obsolete Syntax
|
||||
|
||||
|
||||
The following documents discuss matters which are related to IMAP:
|
||||
rfc3503.txt MDN Profile for IMAP
|
||||
rfc3656.txt MUPDATE Distributed Mailbox Database Protocol
|
||||
rfc4468.txt Message Submission BURL Extension
|
||||
rfc5092.txt IMAP URL Scheme
|
||||
283
docs/rfc/rfc1732.txt
Normal file
283
docs/rfc/rfc1732.txt
Normal file
@ -0,0 +1,283 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Crispin
|
||||
Request for Comments: 1732 University of Washington
|
||||
Category: Informational December 1994
|
||||
|
||||
|
||||
IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS
|
||||
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This memo provides information for the Internet community. This memo
|
||||
does not specify an Internet standard of any kind. Distribution of
|
||||
this memo is unlimited.
|
||||
|
||||
Introduction
|
||||
|
||||
This is a summary of hints and recommendations to enable an IMAP4
|
||||
implementation to interoperate with implementations that conform to
|
||||
earlier specifications. None of these hints and recommendations are
|
||||
required by the IMAP4 specification; implementors must decide for
|
||||
themselves whether they want their implementation to fail if it
|
||||
encounters old software.
|
||||
|
||||
IMAP4 has been designed to be upwards compatible with earlier
|
||||
specifications. For the most part, IMAP4 facilities that were not in
|
||||
earlier specifications should be invisible to clients unless the
|
||||
client asks for the facility.
|
||||
|
||||
In some cases, older servers may support some of the capabilities
|
||||
listed as being "new in IMAP4" as experimental extensions to the
|
||||
IMAP2 protocol described in RFC 1176.
|
||||
|
||||
This information may not be complete; it reflects current knowledge
|
||||
of server and client implementations as well as "folklore" acquired
|
||||
in the evolution of the protocol.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin [Page 1]
|
||||
|
||||
RFC 1732 IMAP4 - Compatibility December 1994
|
||||
|
||||
|
||||
IMAP4 client interoperability with old servers
|
||||
|
||||
In general, a client should be able to discover whether an IMAP2
|
||||
server supports a facility by trial-and-error; if an attempt to use a
|
||||
facility generates a BAD response, the client can assume that the
|
||||
server does not support the facility.
|
||||
|
||||
A quick way to check whether a server implementation supports the
|
||||
IMAP4 specification is to try the CAPABILITY command. An OK response
|
||||
that includes the IMAP4 capability value indicates a server that
|
||||
supports IMAP4; a BAD response or one without the IMAP4 capability
|
||||
value indicates an older server.
|
||||
|
||||
The following is a list of facilities that are only in IMAP4, and
|
||||
suggestions for how new clients might interoperate with old servers:
|
||||
|
||||
CAPABILITY command
|
||||
A BAD response to this command indicates that the server
|
||||
implements IMAP2 (or IMAP2bis) and not IMAP4.
|
||||
|
||||
AUTHENTICATE command.
|
||||
Use the LOGIN command.
|
||||
|
||||
LSUB and LIST commands
|
||||
Try the RFC 1176 FIND command.
|
||||
|
||||
* in a sequence
|
||||
Use the number of messages in the mailbox from the EXISTS
|
||||
unsolicited response.
|
||||
|
||||
SEARCH extensions (character set, additional criteria)
|
||||
Reformulate the search request using only the searching
|
||||
options listed in search_old in the IMAP4 grammar. This may
|
||||
entail doing multiple searches to achieve the desired
|
||||
results.
|
||||
|
||||
BODYSTRUCTURE fetch data item
|
||||
Try to fetch the non-extensible BODY data item.
|
||||
|
||||
body section number 0
|
||||
Fetch the entire message and extract the header.
|
||||
|
||||
RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items
|
||||
Use RFC822.HEADER and remove the unwanted information.
|
||||
|
||||
BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data
|
||||
items Use the corresponding non-PEEK versions and manually
|
||||
clear the \Seen flag as necessary.
|
||||
|
||||
|
||||
|
||||
Crispin [Page 2]
|
||||
|
||||
RFC 1732 IMAP4 - Compatibility December 1994
|
||||
|
||||
|
||||
UID fetch data item and the UID commands
|
||||
No equivalent capabilitity exists in older servers.
|
||||
|
||||
FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
|
||||
Use the corresponding non-SILENT versions and ignore the
|
||||
untagged FETCH responses which com eback.
|
||||
|
||||
|
||||
The following IMAP4 facilities were introduced in the experimental
|
||||
IMAP2bis revisions to RFC-1176, and may be present in a server that
|
||||
does not support the CAPABILITY command:
|
||||
|
||||
CREATE, DELETE, and RENAME commands
|
||||
To test whether these commands are present, try a CREATE
|
||||
INBOX command. If the response is NO, these commands are
|
||||
supported by the server. If the response is BAD, they are
|
||||
not. Older servers without the CREATE capability may sup-
|
||||
port implicit creation of a mailbox by a COPY command with a
|
||||
non-existant name as the destination.
|
||||
|
||||
APPEND command
|
||||
To test whether this command is present, try to append a
|
||||
zero-length stream to a mailbox name that is known not to
|
||||
exist (or at least, highly unlikely to exist) on the remote
|
||||
system.
|
||||
|
||||
SUBSCRIBE and UNSUBSCRIBE commands
|
||||
Try the form of these commands with the optional MAILBOX
|
||||
keyword.
|
||||
|
||||
EXAMINE command
|
||||
Use the SELECT command instead.
|
||||
|
||||
flags and internal date argument to APPEND command
|
||||
Try the APPEND without any flag list and internal date argu-
|
||||
ments.
|
||||
|
||||
BODY, BODY[section], and FULL fetch data items
|
||||
Use RFC822.TEXT and ALL instead. Server does not support
|
||||
MIME.
|
||||
|
||||
PARTIAL command
|
||||
Use the appropriate FETCH command and ignore the unwanted
|
||||
data.
|
||||
|
||||
|
||||
IMAP4 client implementations must accept all responses and data for-
|
||||
mats documented in the IMAP4 specification, including those labeled
|
||||
|
||||
|
||||
|
||||
Crispin [Page 3]
|
||||
|
||||
RFC 1732 IMAP4 - Compatibility December 1994
|
||||
|
||||
|
||||
as obsolete. This includes the COPY and STORE unsolicited responses
|
||||
and the old format of dates and times. In particular, client imple-
|
||||
mentations must not treat a date/time as a fixed format string; nor
|
||||
may they assume that the time begins at a particular octet.
|
||||
|
||||
IMAP4 client implementations must not depend upon the presence of any
|
||||
server extensions that are not in the base IMAP4 specification.
|
||||
|
||||
The experimental IMAP2bis version specified that the TRYCREATE spe-
|
||||
cial information token is sent as a separate unsolicited OK response
|
||||
instead of inside the NO response.
|
||||
|
||||
The FIND BBOARDS, FIND ALL.BBOARDS, and BBOARD commands of RFC 1176
|
||||
are removed from IMAP4. There is no equivalent to the bboard com-
|
||||
mands, which provided a separate namespace with implicit restrictions
|
||||
on what may be done in that namespace.
|
||||
|
||||
Older server implementations may automatically create the destination
|
||||
mailbox on COPY if that mailbox does not already exist. This was how
|
||||
a new mailbox was created in older specifications. If the server
|
||||
does not support the CREATE command (see above for how to test for
|
||||
this), it will probably create a mailbox on COPY.
|
||||
|
||||
Older server implementations may not preserve flags or internal dates
|
||||
on COPY. Some server implementations may not permit the preservation
|
||||
of certain flags on COPY or their setting with APPEND as site policy.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin [Page 4]
|
||||
|
||||
RFC 1732 IMAP4 - Compatibility December 1994
|
||||
|
||||
|
||||
IMAP4 server interoperability with old clients
|
||||
|
||||
In general, there should be no interoperation problem between a
|
||||
server conforming to the IMAP4 specification and a well-written
|
||||
client that conforms to an earlier specification. Known problems are
|
||||
noted below:
|
||||
|
||||
Poor wording in the description of the CHECK command in earlier
|
||||
specifications implied that a CHECK command is the way to get the
|
||||
current number of messages in the mailbox. This is incorrect. A
|
||||
CHECK command does not necessarily result in an EXISTS response.
|
||||
Clients must remember the most recent EXISTS value sent from the
|
||||
server, and should not generate unnecessary CHECK commands.
|
||||
|
||||
An incompatibility exists with COPY in IMAP4. COPY in IMAP4
|
||||
servers does not automatically create the destination mailbox if
|
||||
that mailbox does not already exist. This may cause problems with
|
||||
old clients that expect automatic mailbox creation in COPY.
|
||||
|
||||
The PREAUTH unsolicited response is new in IMAP4. It is highly
|
||||
unlikely that an old client would ever see this response.
|
||||
|
||||
The format of dates and times has changed due to the impending end
|
||||
of the century. Clients that fail to accept a four-digit year or
|
||||
a signed four-digit timezone value will not work properly with
|
||||
IMAP4.
|
||||
|
||||
An incompatibility exists with the use of "\" in quoted strings.
|
||||
This is best avoided by using literals instead of quoted strings
|
||||
if "\" or <"> is embedded in the string.
|
||||
|
||||
Security Considerations
|
||||
|
||||
Security issues are not discussed in this memo.
|
||||
|
||||
Author's Address:
|
||||
|
||||
Mark R. Crispin
|
||||
Networks and Distributed Computing, JE-30
|
||||
University of Washington
|
||||
Seattle, WA 98195
|
||||
|
||||
Phone: (206) 543-5762
|
||||
|
||||
EMail: MRC@CAC.Washington.EDU
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin [Page 5]
|
||||
|
||||
171
docs/rfc/rfc1733.txt
Normal file
171
docs/rfc/rfc1733.txt
Normal file
@ -0,0 +1,171 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Crispin
|
||||
Request for Comments: 1733 University of Washington
|
||||
Category: Informational December 1994
|
||||
|
||||
|
||||
DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4
|
||||
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This memo provides information for the Internet community. This memo
|
||||
does not specify an Internet standard of any kind. Distribution of
|
||||
this memo is unlimited.
|
||||
|
||||
|
||||
Distributed Electronic Mail Models
|
||||
|
||||
There are three fundamental models of client/server email: offline,
|
||||
online, and disconnected use. IMAP4 can be used in any one of these
|
||||
three models.
|
||||
|
||||
The offline model is the most familiar form of client/server email
|
||||
today, and is used by protocols such as POP-3 (RFC 1225) and UUCP.
|
||||
In this model, a client application periodically connects to a
|
||||
server. It downloads all the pending messages to the client machine
|
||||
and deletes these from the server. Thereafter, all mail processing
|
||||
is local to the client. This model is store-and-forward; it moves
|
||||
mail on demand from an intermediate server (maildrop) to a single
|
||||
destination machine.
|
||||
|
||||
The online model is most commonly used with remote filesystem
|
||||
protocols such as NFS. In this model, a client application
|
||||
manipulates mailbox data on a server machine. A connection to the
|
||||
server is maintained throughout the session. No mailbox data are
|
||||
kept on the client; the client retrieves data from the server as is
|
||||
needed. IMAP4 introduces a form of the online model that requires
|
||||
considerably less network bandwidth than a remote filesystem
|
||||
protocol, and provides the opportunity for using the server for CPU
|
||||
or I/O intensive functions such as parsing and searching.
|
||||
|
||||
The disconnected use model is a hybrid of the offline and online
|
||||
models, and is used by protocols such as PCMAIL (RFC 1056). In this
|
||||
model, a client user downloads some set of messages from the server,
|
||||
manipulates them offline, then at some later time uploads the
|
||||
changes. The server remains the authoritative repository of the
|
||||
messages. The problems of synchronization (particularly when
|
||||
multiple clients are involved) are handled through the means of
|
||||
unique identifiers for each message.
|
||||
|
||||
|
||||
|
||||
Crispin [Page 1]
|
||||
|
||||
RFC 1733 IMAP4 - Model December 1994
|
||||
|
||||
|
||||
Each of these models have their own strengths and weaknesses:
|
||||
|
||||
Feature Offline Online Disc
|
||||
------- ------- ------ ----
|
||||
Can use multiple clients NO YES YES
|
||||
Minimum use of server connect time YES NO YES
|
||||
Minimum use of server resources YES NO NO
|
||||
Minimum use of client disk resources NO YES NO
|
||||
Multiple remote mailboxes NO YES YES
|
||||
Fast startup NO YES NO
|
||||
Mail processing when not online YES NO YES
|
||||
|
||||
Although IMAP4 has its origins as a protocol designed to accommodate
|
||||
the online model, it can support the other two models as well. This
|
||||
makes possible the creation of clients that can be used in any of the
|
||||
three models. For example, a user may wish to switch between the
|
||||
online and disconnected models on a regular basis (e.g. owing to
|
||||
travel).
|
||||
|
||||
IMAP4 is designed to transmit message data on demand, and to provide
|
||||
the facilities necessary for a client to decide what data it needs at
|
||||
any particular time. There is generally no need to do a wholesale
|
||||
transfer of an entire mailbox or even of the complete text of a
|
||||
message. This makes a difference in situations where the mailbox is
|
||||
large, or when the link to the server is slow.
|
||||
|
||||
More specifically, IMAP4 supports server-based RFC 822 and MIME
|
||||
processing. With this information, it is possible for a client to
|
||||
determine in advance whether it wishes to retrieve a particular
|
||||
message or part of a message. For example, a user connected to an
|
||||
IMAP4 server via a dialup link can determine that a message has a
|
||||
2000 byte text segment and a 40 megabyte video segment, and elect to
|
||||
fetch only the text segment.
|
||||
|
||||
In IMAP4, the client/server relationship lasts only for the duration
|
||||
of the TCP connection. There is no registration of clients. Except
|
||||
for any unique identifiers used in disconnected use operation, the
|
||||
client initially has no knowledge of mailbox state and learns it from
|
||||
the IMAP4 server when a mailbox is selected. This initial transfer
|
||||
is minimal; the client requests additional state data as it needs.
|
||||
|
||||
As noted above, the choice for the location of mailbox data depends
|
||||
upon the model chosen. The location of message state (e.g. whether
|
||||
or not a message has been read or answered) is also determined by the
|
||||
model, and is not necessarily the same as the location of the mailbox
|
||||
data. For example, in the online model message state can be co-
|
||||
located with mailbox data; it can also be located elsewhere (on the
|
||||
client or on a third agent) using unique identifiers to achieve
|
||||
|
||||
|
||||
|
||||
Crispin [Page 2]
|
||||
|
||||
RFC 1733 IMAP4 - Model December 1994
|
||||
|
||||
|
||||
common reference across sessions. The latter is particularly useful
|
||||
with a server that exports public data such as netnews and does not
|
||||
maintain per-user state.
|
||||
|
||||
The IMAP4 protocol provides the generality to implement these
|
||||
different models. This is done by means of server and (especially)
|
||||
client configuration, and not by requiring changes to the protocol or
|
||||
the implementation of the protocol.
|
||||
|
||||
|
||||
Security Considerations
|
||||
|
||||
Security issues are not discussed in this memo.
|
||||
|
||||
|
||||
Author's Address:
|
||||
|
||||
Mark R. Crispin
|
||||
Networks and Distributed Computing, JE-30
|
||||
University of Washington
|
||||
Seattle, WA 98195
|
||||
|
||||
Phone: (206) 543-5762
|
||||
|
||||
EMail: MRC@CAC.Washington.EDU
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin [Page 3]
|
||||
|
||||
171
docs/rfc/rfc2061.txt
Normal file
171
docs/rfc/rfc2061.txt
Normal file
@ -0,0 +1,171 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Crispin
|
||||
Request for Comments: 2061 University of Washington
|
||||
Category: Informational December 1996
|
||||
|
||||
|
||||
IMAP4 COMPATIBILITY WITH IMAP2BIS
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This memo provides information for the Internet community. This memo
|
||||
does not specify an Internet standard of any kind. Distribution of
|
||||
this memo is unlimited.
|
||||
|
||||
Introduction
|
||||
|
||||
The Internet Message Access Protocol (IMAP) has been through several
|
||||
revisions and variants in its 10-year history. Many of these are
|
||||
either extinct or extremely rare; in particular, several undocumented
|
||||
variants and the variants described in RFC 1064, RFC 1176, and RFC
|
||||
1203 fall into this category.
|
||||
|
||||
One variant, IMAP2bis, is at the time of this writing very common and
|
||||
has been widely distributed with the Pine mailer. Unfortunately,
|
||||
there is no definite document describing IMAP2bis. This document is
|
||||
intended to be read along with RFC 1176 and the most recent IMAP4
|
||||
specification (RFC 2060) to assist implementors in creating an IMAP4
|
||||
implementation to interoperate with implementations that conform to
|
||||
earlier specifications. Nothing in this document is required by the
|
||||
IMAP4 specification; implementors must decide for themselves whether
|
||||
they want their implementation to fail if it encounters old software.
|
||||
|
||||
At the time of this writing, IMAP4 has been updated from the version
|
||||
described in RFC 1730. An implementor who wishes to interoperate
|
||||
with both RFC 1730 and RFC 2060 should refer to both documents.
|
||||
|
||||
This information is not complete; it reflects current knowledge of
|
||||
server and client implementations as well as "folklore" acquired in
|
||||
the evolution of the protocol. It is NOT a description of how to
|
||||
interoperate with all variants of IMAP, but rather with the old
|
||||
variant that is most likely to be encountered. For detailed
|
||||
information on interoperating with other old variants, refer to RFC
|
||||
1732.
|
||||
|
||||
IMAP4 client interoperability with IMAP2bis servers
|
||||
|
||||
A quick way to check whether a server implementation supports the
|
||||
IMAP4 specification is to try the CAPABILITY command. An OK response
|
||||
will indicate which variant(s) of IMAP4 are supported by the server.
|
||||
|
||||
|
||||
|
||||
Crispin Informational [Page 1]
|
||||
|
||||
RFC 2061 IMAP4 Compatibility December 1996
|
||||
|
||||
|
||||
If the client does not find any of its known variant in the response,
|
||||
it should treat the server as IMAP2bis. A BAD response indicates an
|
||||
IMAP2bis or older server.
|
||||
|
||||
Most IMAP4 facilities are in IMAP2bis. The following exceptions
|
||||
exist:
|
||||
|
||||
CAPABILITY command
|
||||
The absense of this command indicates IMAP2bis (or older).
|
||||
|
||||
AUTHENTICATE command.
|
||||
Use the LOGIN command.
|
||||
|
||||
LSUB, SUBSCRIBE, and UNSUBSCRIBE commands
|
||||
No direct functional equivalent. IMAP2bis had a concept
|
||||
called "bboards" which is not in IMAP4. RFC 1176 supported
|
||||
these with the BBOARD and FIND BBOARDS commands. IMAP2bis
|
||||
augmented these with the FIND ALL.BBOARDS, SUBSCRIBE BBOARD,
|
||||
and UNSUBSCRIBE BBOARD commands. It is recommended that
|
||||
none of these commands be implemented in new software,
|
||||
including servers that support old clients.
|
||||
|
||||
LIST command
|
||||
Use the command FIND ALL.MAILBOXES, which has a similar syn-
|
||||
tax and response to the FIND MAILBOXES command described in
|
||||
RFC 1176. The FIND MAILBOXES command is unlikely to produce
|
||||
useful information.
|
||||
|
||||
* in a sequence
|
||||
Use the number of messages in the mailbox from the EXISTS
|
||||
unsolicited response.
|
||||
|
||||
SEARCH extensions (character set, additional criteria)
|
||||
Reformulate the search request using only the RFC 1176 syn-
|
||||
tax. This may entail doing multiple searches to achieve the
|
||||
desired results.
|
||||
|
||||
BODYSTRUCTURE fetch data item
|
||||
Use the non-extensible BODY data item.
|
||||
|
||||
body sections HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT
|
||||
Use body section numbers only.
|
||||
|
||||
BODY.PEEK[section]
|
||||
Use BODY[section] and manually clear the \Seen flag as
|
||||
necessary.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Informational [Page 2]
|
||||
|
||||
RFC 2061 IMAP4 Compatibility December 1996
|
||||
|
||||
|
||||
FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
|
||||
Use the corresponding non-SILENT versions and ignore the
|
||||
untagged FETCH responses which come back.
|
||||
|
||||
UID fetch data item and the UID commands
|
||||
No functional equivalent.
|
||||
|
||||
CLOSE command
|
||||
No functional equivalent.
|
||||
|
||||
|
||||
In IMAP2bis, the TRYCREATE special information token is sent as a
|
||||
separate unsolicited OK response instead of inside the NO response.
|
||||
|
||||
IMAP2bis is ambiguous about whether or not flags or internal dates
|
||||
are preserved on COPY. It is impossible to know what behavior is
|
||||
supported by the server.
|
||||
|
||||
IMAP4 server interoperability with IMAP2bis clients
|
||||
|
||||
The only interoperability problem between an IMAP4 server and a
|
||||
well-written IMAP2bis client is an incompatibility with the use of
|
||||
"\" in quoted strings. This is best avoided by using literals
|
||||
instead of quoted strings if "\" or <"> is embedded in the string.
|
||||
|
||||
Security Considerations
|
||||
|
||||
Security issues are not discussed in this memo.
|
||||
|
||||
Author's Address
|
||||
|
||||
Mark R. Crispin
|
||||
Networks and Distributed Computing
|
||||
University of Washington
|
||||
4545 15th Aveneue NE
|
||||
Seattle, WA 98105-4527
|
||||
|
||||
Phone: (206) 543-5762
|
||||
EMail: MRC@CAC.Washington.EDU
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Informational [Page 3]
|
||||
|
||||
451
docs/rfc/rfc2062.txt
Normal file
451
docs/rfc/rfc2062.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Crispin
|
||||
Request for Comments: 2062 University of Washington
|
||||
Category: Informational December 1996
|
||||
|
||||
|
||||
Internet Message Access Protocol - Obsolete Syntax
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This memo provides information for the Internet community. This memo
|
||||
does not specify an Internet standard of any kind. Distribution of
|
||||
this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes obsolete syntax which may be encountered by
|
||||
IMAP4 implementations which deal with older versions of the Internet
|
||||
Mail Access Protocol. IMAP4 implementations MAY implement this
|
||||
syntax in order to maximize interoperability with older
|
||||
implementations.
|
||||
|
||||
This document repeats information from earlier documents, most
|
||||
notably RFC 1176 and RFC 1730.
|
||||
|
||||
Obsolete Commands and Fetch Data Items
|
||||
|
||||
The following commands are OBSOLETE. It is NOT required to support
|
||||
any of these commands or fetch data items in new server
|
||||
implementations. These commands are documented here for the benefit
|
||||
of implementors who may wish to support them for compatibility with
|
||||
old client implementations.
|
||||
|
||||
The section headings of these commands are intended to correspond
|
||||
with where they would be located in the main document if they were
|
||||
not obsoleted.
|
||||
|
||||
6.3.OBS.1. FIND ALL.MAILBOXES Command
|
||||
|
||||
Arguments: mailbox name with possible wildcards
|
||||
|
||||
Data: untagged responses: MAILBOX
|
||||
|
||||
Result: OK - find completed
|
||||
NO - find failure: can't list that name
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Informational [Page 1]
|
||||
|
||||
RFC 2062 IMAP4 Obsolete December 1996
|
||||
|
||||
|
||||
The FIND ALL.MAILBOXES command returns a subset of names from the
|
||||
complete set of all names available to the user. It returns zero
|
||||
or more untagged MAILBOX replies. The mailbox argument to FIND
|
||||
ALL.MAILBOXES is similar to that for LIST with an empty reference,
|
||||
except that the characters "%" and "?" match a single character.
|
||||
|
||||
Example: C: A002 FIND ALL.MAILBOXES *
|
||||
S: * MAILBOX blurdybloop
|
||||
S: * MAILBOX INBOX
|
||||
S: A002 OK FIND ALL.MAILBOXES completed
|
||||
|
||||
6.3.OBS.2. FIND MAILBOXES Command
|
||||
|
||||
Arguments: mailbox name with possible wildcards
|
||||
|
||||
Data: untagged responses: MAILBOX
|
||||
|
||||
Result: OK - find completed
|
||||
NO - find failure: can't list that name
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The FIND MAILBOXES command returns a subset of names from the set
|
||||
of names that the user has declared as being "active" or
|
||||
"subscribed". It returns zero or more untagged MAILBOX replies.
|
||||
The mailbox argument to FIND MAILBOXES is similar to that for LSUB
|
||||
with an empty reference, except that the characters "%" and "?"
|
||||
match a single character.
|
||||
|
||||
Example: C: A002 FIND MAILBOXES *
|
||||
S: * MAILBOX blurdybloop
|
||||
S: * MAILBOX INBOX
|
||||
S: A002 OK FIND MAILBOXES completed
|
||||
|
||||
6.3.OBS.3. SUBSCRIBE MAILBOX Command
|
||||
|
||||
Arguments: mailbox name
|
||||
|
||||
Data: no specific data for this command
|
||||
|
||||
Result: OK - subscribe completed
|
||||
NO - subscribe failure: can't subscribe to that name
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The SUBSCRIBE MAILBOX command is identical in effect to the
|
||||
SUBSCRIBE command. A server which implements this command must be
|
||||
able to distinguish between a SUBSCRIBE MAILBOX command and a
|
||||
SUBSCRIBE command with a mailbox name argument of "MAILBOX".
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Informational [Page 2]
|
||||
|
||||
RFC 2062 IMAP4 Obsolete December 1996
|
||||
|
||||
|
||||
Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
|
||||
S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
|
||||
completed
|
||||
C: A003 SUBSCRIBE MAILBOX
|
||||
S: A003 OK SUBSCRIBE to MAILBOX completed
|
||||
|
||||
|
||||
6.3.OBS.4. UNSUBSCRIBE MAILBOX Command
|
||||
|
||||
Arguments: mailbox name
|
||||
|
||||
Data: no specific data for this command
|
||||
|
||||
Result: OK - unsubscribe completed
|
||||
NO - unsubscribe failure: can't unsubscribe that name
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The UNSUBSCRIBE MAILBOX command is identical in effect to the
|
||||
UNSUBSCRIBE command. A server which implements this command must
|
||||
be able to distinguish between a UNSUBSCRIBE MAILBOX command and
|
||||
an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
|
||||
|
||||
Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
|
||||
S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
|
||||
completed
|
||||
C: A003 UNSUBSCRIBE MAILBOX
|
||||
S: A003 OK UNSUBSCRIBE from MAILBOX completed
|
||||
|
||||
6.4.OBS.1 PARTIAL Command
|
||||
|
||||
Arguments: message sequence number
|
||||
message data item name
|
||||
position of first octet
|
||||
number of octets
|
||||
|
||||
Data: untagged responses: FETCH
|
||||
|
||||
Result: OK - partial completed
|
||||
NO - partial error: can't fetch that data
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The PARTIAL command is equivalent to the associated FETCH command,
|
||||
with the added functionality that only the specified number of
|
||||
octets, beginning at the specified starting octet, are returned.
|
||||
Only a single message can be fetched at a time. The first octet
|
||||
of a message, and hence the minimum for the starting octet, is
|
||||
octet 1.
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Informational [Page 3]
|
||||
|
||||
RFC 2062 IMAP4 Obsolete December 1996
|
||||
|
||||
|
||||
The following FETCH items are valid data for PARTIAL: RFC822,
|
||||
RFC822.HEADER, RFC822.TEXT, BODY[<section>], as well as any .PEEK
|
||||
forms of these.
|
||||
|
||||
Any partial fetch that attempts to read beyond the end of the text
|
||||
is truncated as appropriate. If the starting octet is beyond the
|
||||
end of the text, an empty string is returned.
|
||||
|
||||
The data are returned with the FETCH response. There is no
|
||||
indication of the range of the partial data in this response. It
|
||||
is not possible to stream multiple PARTIAL commands of the same
|
||||
data item without processing and synchronizing at each step, since
|
||||
streamed commands may be executed out of order.
|
||||
|
||||
There is no requirement that partial fetches follow any sequence.
|
||||
For example, if a partial fetch of octets 1 through 10000 breaks
|
||||
in an awkward place for BASE64 decoding, it is permitted to
|
||||
continue with a partial fetch of 9987 through 19987, etc.
|
||||
|
||||
The handling of the \Seen flag is the same as in the associated
|
||||
FETCH command.
|
||||
|
||||
Example: C: A005 PARTIAL 4 RFC822 1 1024
|
||||
S: * 1 FETCH (RFC822 {1024}
|
||||
S: Return-Path: <gray@cac.washington.edu>
|
||||
S: ...
|
||||
S: ......... FLAGS (\Seen))
|
||||
S: A005 OK PARTIAL completed
|
||||
|
||||
6.4.5.OBS.1 Obsolete FETCH Data Items
|
||||
|
||||
The following FETCH data items are obsolete:
|
||||
|
||||
BODY[<...>0] A body part number of 0 is the [RFC-822] header of
|
||||
the message. BODY[0] is functionally equivalent to
|
||||
BODY[HEADER], differing in the syntax of the
|
||||
resulting untagged FETCH data (BODY[0] is
|
||||
returned).
|
||||
|
||||
RFC822.HEADER.LINES <header_list>
|
||||
Functionally equivalent to BODY.PEEK[HEADER.LINES
|
||||
<header_list>], differing in the syntax of the
|
||||
resulting untagged FETCH data (RFC822.HEADER is
|
||||
returned).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Informational [Page 4]
|
||||
|
||||
RFC 2062 IMAP4 Obsolete December 1996
|
||||
|
||||
|
||||
RFC822.HEADER.LINES.NOT <header_list>
|
||||
Functionally equivalent to
|
||||
BODY.PEEK[HEADER.LINES.NOT <header_list>],
|
||||
differing in the syntax of the resulting untagged
|
||||
FETCH data (RFC822.HEADER is returned).
|
||||
|
||||
RFC822.PEEK Functionally equivalent to BODY.PEEK[], except for
|
||||
the syntax of the resulting untagged FETCH data
|
||||
(RFC822 is returned).
|
||||
|
||||
RFC822.TEXT.PEEK
|
||||
Functionally equivalent to BODY.PEEK[TEXT], except
|
||||
for the syntax of the resulting untagged FETCH data
|
||||
(RFC822.TEXT is returned).
|
||||
|
||||
Obsolete Responses
|
||||
|
||||
The following responses are OBSOLETE. Except as noted below, these
|
||||
responses MUST NOT be transmitted by new server implementations.
|
||||
Client implementations SHOULD accept these responses.
|
||||
|
||||
The section headings of these responses are intended to correspond
|
||||
with where they would be located in the main document if they were
|
||||
not obsoleted.
|
||||
|
||||
7.2.OBS.1. MAILBOX Response
|
||||
|
||||
Data: name
|
||||
|
||||
The MAILBOX response MUST NOT be transmitted by server
|
||||
implementations except in response to the obsolete FIND MAILBOXES
|
||||
and FIND ALL.MAILBOXES commands. Client implementations that do
|
||||
not use these commands MAY ignore this response. It is documented
|
||||
here for the benefit of implementors who may wish to support it
|
||||
for compatibility with old client implementations.
|
||||
|
||||
This response occurs as a result of the FIND MAILBOXES and FIND
|
||||
ALL.MAILBOXES commands. It returns a single name that matches the
|
||||
FIND specification. There are no attributes or hierarchy
|
||||
delimiter.
|
||||
|
||||
Example: S: * MAILBOX blurdybloop
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Informational [Page 5]
|
||||
|
||||
RFC 2062 IMAP4 Obsolete December 1996
|
||||
|
||||
|
||||
7.3.OBS.1. COPY Response
|
||||
|
||||
Data: none
|
||||
|
||||
The COPY response MUST NOT be transmitted by new server
|
||||
implementations. Client implementations MUST ignore the COPY
|
||||
response. It is documented here for the benefit of client
|
||||
implementors who may encounter this response from old server
|
||||
implementations.
|
||||
|
||||
In some experimental versions of this protocol, this response was
|
||||
returned in response to a COPY command to indicate on a
|
||||
per-message basis that the message was copied successfully.
|
||||
|
||||
Example: S: * 44 COPY
|
||||
|
||||
7.3.OBS.2. STORE Response
|
||||
|
||||
Data: message data
|
||||
|
||||
The STORE response MUST NOT be transmitted by new server
|
||||
implementations. Client implementations MUST treat the STORE
|
||||
response as equivalent to the FETCH response. It is documented
|
||||
here for the benefit of client implementors who may encounter this
|
||||
response from old server implementations.
|
||||
|
||||
In some experimental versions of this protocol, this response was
|
||||
returned instead of FETCH in response to a STORE command to report
|
||||
the new value of the flags.
|
||||
|
||||
Example: S: * 69 STORE (FLAGS (\Deleted))
|
||||
|
||||
Formal Syntax of Obsolete Commands and Responses
|
||||
|
||||
Each obsolete syntax rule that is suffixed with "_old" is added to
|
||||
the corresponding name in the formal syntax. For example,
|
||||
command_auth_old adds the FIND command to command_auth.
|
||||
|
||||
command_auth_old ::= find
|
||||
|
||||
command_select_old
|
||||
::= partial
|
||||
|
||||
date_year_old ::= 2digit
|
||||
;; (year - 1900)
|
||||
|
||||
date_time_old ::= <"> date_day_fixed "-" date_month "-" date_year
|
||||
SPACE time "-" zone_name <">
|
||||
|
||||
|
||||
|
||||
Crispin Informational [Page 6]
|
||||
|
||||
RFC 2062 IMAP4 Obsolete December 1996
|
||||
|
||||
|
||||
find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
|
||||
list_mailbox
|
||||
|
||||
fetch_att_old ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list /
|
||||
fetch_text_old
|
||||
|
||||
fetch_text_old ::= "BODY" [".PEEK"] section_old /
|
||||
"RFC822" [".HEADER" / ".TEXT" [".PEEK"]]
|
||||
|
||||
msg_data_old ::= "COPY" / ("STORE" SPACE msg_att)
|
||||
|
||||
partial ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old SPACE
|
||||
number SPACE number
|
||||
|
||||
section_old ::= "[" (number ["." number]) "]"
|
||||
|
||||
subscribe_old ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
|
||||
|
||||
unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
|
||||
|
||||
zone_name ::= "UT" / "GMT" / "Z" / ;; +0000
|
||||
"AST" / "EDT" / ;; -0400
|
||||
"EST" / "CDT" / ;; -0500
|
||||
"CST" / "MDT" / ;; -0600
|
||||
"MST" / "PDT" / ;; -0700
|
||||
"PST" / "YDT" / ;; -0800
|
||||
"YST" / "HDT" / ;; -0900
|
||||
"HST" / "BDT" / ;; -1000
|
||||
"BST" / ;; -1100
|
||||
"A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
|
||||
"G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
|
||||
"N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
|
||||
"T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12
|
||||
|
||||
Security Considerations
|
||||
|
||||
Security issues are not discussed in this memo.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Informational [Page 7]
|
||||
|
||||
RFC 2062 IMAP4 Obsolete December 1996
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Mark R. Crispin
|
||||
Networks and Distributed Computing
|
||||
University of Washington
|
||||
4545 15th Aveneue NE
|
||||
Seattle, WA 98105-4527
|
||||
|
||||
Phone: (206) 543-5762
|
||||
EMail: MRC@CAC.Washington.EDU
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Informational [Page 8]
|
||||
|
||||
283
docs/rfc/rfc2087.txt
Normal file
283
docs/rfc/rfc2087.txt
Normal file
@ -0,0 +1,283 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group J. Myers
|
||||
Request for Comments: 2087 Carnegie Mellon
|
||||
Category: Standards Track January 1997
|
||||
|
||||
|
||||
IMAP4 QUOTA extension
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
1. Abstract
|
||||
|
||||
The QUOTA extension of the Internet Message Access Protocol [IMAP4]
|
||||
permits administrative limits on resource usage (quotas) to be
|
||||
manipulated through the IMAP protocol.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Abstract........................................... 1
|
||||
2. Conventions Used in this Document.................. 1
|
||||
3. Introduction and Overview.......................... 2
|
||||
4. Commands........................................... 2
|
||||
4.1. SETQUOTA Command................................... 2
|
||||
4.2. GETQUOTA Command................................... 2
|
||||
4.3. GETQUOTAROOT Command............................... 3
|
||||
5. Responses.......................................... 3
|
||||
5.1. QUOTA Response..................................... 3
|
||||
5.2. QUOTAROOT Response................................. 4
|
||||
6. Formal syntax...................................... 4
|
||||
7. References......................................... 5
|
||||
8. Security Considerations............................ 5
|
||||
9. Author's Address................................... 5
|
||||
|
||||
|
||||
2. Conventions Used in this Document
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server respectively.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers Standards Track [Page 1]
|
||||
|
||||
RFC 2087 QUOTA January 1997
|
||||
|
||||
|
||||
3. Introduction and Overview
|
||||
|
||||
The QUOTA extension is present in any IMAP4 implementation which
|
||||
returns "QUOTA" as one of the supported capabilities to the
|
||||
CAPABILITY command.
|
||||
|
||||
An IMAP4 server which supports the QUOTA capability may support
|
||||
limits on any number of resources. Each resource has an atom name
|
||||
and an implementation-defined interpretation which evaluates to an
|
||||
integer. Examples of such resources are:
|
||||
|
||||
Name Interpretation
|
||||
|
||||
STORAGE Sum of messages' RFC822.SIZE, in units of 1024 octets
|
||||
MESSAGE Number of messages
|
||||
|
||||
|
||||
Each mailbox has zero or more implementation-defined named "quota
|
||||
roots". Each quota root has zero or more resource limits. All
|
||||
mailboxes that share the same named quota root share the resource
|
||||
limits of the quota root.
|
||||
|
||||
Quota root names do not necessarily have to match the names of
|
||||
existing mailboxes.
|
||||
|
||||
4. Commands
|
||||
|
||||
4.1. SETQUOTA Command
|
||||
|
||||
Arguments: quota root
|
||||
list of resource limits
|
||||
|
||||
Data: untagged responses: QUOTA
|
||||
|
||||
Result: OK - setquota completed
|
||||
NO - setquota error: can't set that data
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The SETQUOTA command takes the name of a mailbox quota root and a
|
||||
list of resource limits. The resource limits for the named quota root
|
||||
are changed to be the specified limits. Any previous resource limits
|
||||
for the named quota root are discarded.
|
||||
|
||||
If the named quota root did not previously exist, an implementation
|
||||
may optionally create it and change the quota roots for any number of
|
||||
existing mailboxes in an implementation-defined manner.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers Standards Track [Page 2]
|
||||
|
||||
RFC 2087 QUOTA January 1997
|
||||
|
||||
|
||||
Example: C: A001 SETQUOTA "" (STORAGE 512)
|
||||
S: * QUOTA "" (STORAGE 10 512)
|
||||
S: A001 OK Setquota completed
|
||||
|
||||
4.2. GETQUOTA Command
|
||||
|
||||
Arguments: quota root
|
||||
|
||||
Data: untagged responses: QUOTA
|
||||
|
||||
Result: OK - getquota completed
|
||||
NO - getquota error: no such quota root, permission
|
||||
denied
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The GETQUOTA command takes the name of a quota root and returns the
|
||||
quota root's resource usage and limits in an untagged QUOTA response.
|
||||
|
||||
Example: C: A003 GETQUOTA ""
|
||||
S: * QUOTA "" (STORAGE 10 512)
|
||||
S: A003 OK Getquota completed
|
||||
|
||||
4.3. GETQUOTAROOT Command
|
||||
|
||||
Arguments: mailbox name
|
||||
|
||||
Data: untagged responses: QUOTAROOT, QUOTA
|
||||
|
||||
Result: OK - getquota completed
|
||||
NO - getquota error: no such mailbox, permission denied
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The GETQUOTAROOT command takes the name of a mailbox and returns the
|
||||
list of quota roots for the mailbox in an untagged QUOTAROOT
|
||||
response. For each listed quota root, it also returns the quota
|
||||
root's resource usage and limits in an untagged QUOTA response.
|
||||
|
||||
Example: C: A003 GETQUOTAROOT INBOX
|
||||
S: * QUOTAROOT INBOX ""
|
||||
S: * QUOTA "" (STORAGE 10 512)
|
||||
S: A003 OK Getquota completed
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers Standards Track [Page 3]
|
||||
|
||||
RFC 2087 QUOTA January 1997
|
||||
|
||||
|
||||
5. Responses
|
||||
|
||||
5.1. QUOTA Response
|
||||
|
||||
Data: quota root name
|
||||
list of resource names, usages, and limits
|
||||
|
||||
This response occurs as a result of a GETQUOTA or GETQUOTAROOT
|
||||
command. The first string is the name of the quota root for which
|
||||
this quota applies.
|
||||
|
||||
The name is followed by a S-expression format list of the resource
|
||||
usage and limits of the quota root. The list contains zero or
|
||||
more triplets. Each triplet conatins a resource name, the current
|
||||
usage of the resource, and the resource limit.
|
||||
|
||||
Resources not named in the list are not limited in the quota root.
|
||||
Thus, an empty list means there are no administrative resource
|
||||
limits in the quota root.
|
||||
|
||||
Example: S: * QUOTA "" (STORAGE 10 512)
|
||||
|
||||
5.2. QUOTAROOT Response
|
||||
|
||||
Data: mailbox name
|
||||
zero or more quota root names
|
||||
|
||||
This response occurs as a result of a GETQUOTAROOT command. The
|
||||
first string is the mailbox and the remaining strings are the
|
||||
names of the quota roots for the mailbox.
|
||||
|
||||
Example: S: * QUOTAROOT INBOX ""
|
||||
S: * QUOTAROOT comp.mail.mime
|
||||
|
||||
6. Formal syntax
|
||||
|
||||
The following syntax specification uses the augmented Backus-Naur
|
||||
Form (BNF) notation as specified in RFC 822 with one exception; the
|
||||
delimiter used with the "#" construct is a single space (SP) and not
|
||||
one or more commas.
|
||||
|
||||
Except as noted otherwise, all alphabetic characters are case-
|
||||
insensitive. The use of upper or lower case characters to define
|
||||
token strings is for editorial clarity only. Implementations MUST
|
||||
accept these strings in a case-insensitive fashion.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers Standards Track [Page 4]
|
||||
|
||||
RFC 2087 QUOTA January 1997
|
||||
|
||||
|
||||
getquota ::= "GETQUOTA" SP astring
|
||||
|
||||
getquotaroot ::= "GETQUOTAROOT" SP astring
|
||||
|
||||
quota_list ::= "(" #quota_resource ")"
|
||||
|
||||
quota_resource ::= atom SP number SP number
|
||||
|
||||
quota_response ::= "QUOTA" SP astring SP quota_list
|
||||
|
||||
quotaroot_response
|
||||
::= "QUOTAROOT" SP astring *(SP astring)
|
||||
|
||||
setquota ::= "SETQUOTA" SP astring SP setquota_list
|
||||
|
||||
setquota_list ::= "(" 0#setquota_resource ")"
|
||||
|
||||
setquota_resource ::= atom SP number
|
||||
|
||||
7. References
|
||||
|
||||
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
|
||||
RFC 1730, University of Washington, December 1994.
|
||||
|
||||
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
|
||||
Text Messages", STD 11, RFC 822.
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
Implementors should be careful to make sure the implementation of
|
||||
these commands does not violate the site's security policy. The
|
||||
resource usage of other users is likely to be considered confidential
|
||||
information and should not be divulged to unauthorized persons.
|
||||
|
||||
9. Author's Address
|
||||
|
||||
John G. Myers
|
||||
Carnegie-Mellon University
|
||||
5000 Forbes Ave.
|
||||
Pittsburgh PA, 15213-3890
|
||||
|
||||
EMail: jgm+@cmu.edu
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Myers Standards Track [Page 5]
|
||||
|
||||
115
docs/rfc/rfc2088.txt
Normal file
115
docs/rfc/rfc2088.txt
Normal file
@ -0,0 +1,115 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group J. Myers
|
||||
Request for Comments: 2088 Carnegie Mellon
|
||||
Cateogry: Standards Track January 1997
|
||||
|
||||
|
||||
IMAP4 non-synchronizing literals
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
1. Abstract
|
||||
|
||||
The Internet Message Access Protocol [IMAP4] contains the "literal"
|
||||
syntactic construct for communicating strings. When sending a
|
||||
literal from client to server, IMAP4 requires the client to wait for
|
||||
the server to send a command continuation request between sending the
|
||||
octet count and the string data. This document specifies an
|
||||
alternate form of literal which does not require this network round
|
||||
trip.
|
||||
|
||||
2. Conventions Used in this Document
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server respectively.
|
||||
|
||||
3. Specification
|
||||
|
||||
The non-synchronizing literal is added an alternate form of literal,
|
||||
and may appear in communication from client to server instead of the
|
||||
IMAP4 form of literal. The IMAP4 form of literal, used in
|
||||
communication from client to server, is referred to as a
|
||||
synchronizing literal.
|
||||
|
||||
Non-synchronizing literals may be used with any IMAP4 server
|
||||
implementation which returns "LITERAL+" as one of the supported
|
||||
capabilities to the CAPABILITY command. If the server does not
|
||||
advertise the LITERAL+ capability, the client must use synchronizing
|
||||
literals instead.
|
||||
|
||||
The non-synchronizing literal is distinguished from the original
|
||||
synchronizing literal by having a plus ('+') between the octet count
|
||||
and the closing brace ('}'). The server does not generate a command
|
||||
continuation request in response to a non-synchronizing literal, and
|
||||
|
||||
|
||||
|
||||
Myers Standards Track [Page 1]
|
||||
|
||||
RFC 2088 LITERAL January 1997
|
||||
|
||||
|
||||
clients are not required to wait before sending the octets of a non-
|
||||
synchronizing literal.
|
||||
|
||||
The protocol receiver of an IMAP4 server must check the end of every
|
||||
received line for an open brace ('{') followed by an octet count, a
|
||||
plus ('+'), and a close brace ('}') immediately preceeding the CRLF.
|
||||
If it finds this sequence, it is the octet count of a non-
|
||||
synchronizing literal and the server MUST treat the specified number
|
||||
of following octets and the following line as part of the same
|
||||
command. A server MAY still process commands and reject errors on a
|
||||
line-by-line basis, as long as it checks for non-synchronizing
|
||||
literals at the end of each line.
|
||||
|
||||
Example: C: A001 LOGIN {11+}
|
||||
C: FRED FOOBAR {7+}
|
||||
C: fat man
|
||||
S: A001 OK LOGIN completed
|
||||
|
||||
4. Formal Syntax
|
||||
|
||||
The following syntax specification uses the augmented Backus-Naur
|
||||
Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
|
||||
Non-terminals referenced but not defined below are as defined by
|
||||
[IMAP4].
|
||||
|
||||
literal ::= "{" number ["+"] "}" CRLF *CHAR8
|
||||
;; Number represents the number of CHAR8 octets
|
||||
|
||||
6. References
|
||||
|
||||
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
|
||||
draft-crispin-imap-base-XX.txt, University of Washington, April 1996.
|
||||
|
||||
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
|
||||
Messages", STD 11, RFC 822.
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
There are no known security issues with this extension.
|
||||
|
||||
8. Author's Address
|
||||
|
||||
John G. Myers
|
||||
Carnegie-Mellon University
|
||||
5000 Forbes Ave.
|
||||
Pittsburgh PA, 15213-3890
|
||||
|
||||
Email: jgm+@cmu.edu
|
||||
|
||||
|
||||
|
||||
Myers Standards Track [Page 2]
|
||||
|
||||
227
docs/rfc/rfc2177.txt
Normal file
227
docs/rfc/rfc2177.txt
Normal file
@ -0,0 +1,227 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group B. Leiba
|
||||
Request for Comments: 2177 IBM T.J. Watson Research Center
|
||||
Category: Standards Track June 1997
|
||||
|
||||
|
||||
IMAP4 IDLE command
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
1. Abstract
|
||||
|
||||
The Internet Message Access Protocol [IMAP4] requires a client to
|
||||
poll the server for changes to the selected mailbox (new mail,
|
||||
deletions). It's often more desirable to have the server transmit
|
||||
updates to the client in real time. This allows a user to see new
|
||||
mail immediately. It also helps some real-time applications based on
|
||||
IMAP, which might otherwise need to poll extremely often (such as
|
||||
every few seconds). (While the spec actually does allow a server to
|
||||
push EXISTS responses aysynchronously, a client can't expect this
|
||||
behaviour and must poll.)
|
||||
|
||||
This document specifies the syntax of an IDLE command, which will
|
||||
allow a client to tell the server that it's ready to accept such
|
||||
real-time updates.
|
||||
|
||||
2. Conventions Used in this Document
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server respectively.
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
|
||||
in this document are to be interpreted as described in RFC 2060
|
||||
[IMAP4].
|
||||
|
||||
3. Specification
|
||||
|
||||
IDLE Command
|
||||
|
||||
Arguments: none
|
||||
|
||||
Responses: continuation data will be requested; the client sends
|
||||
the continuation data "DONE" to end the command
|
||||
|
||||
|
||||
|
||||
Leiba Standards Track [Page 1]
|
||||
|
||||
RFC 2177 IMAP4 IDLE command June 1997
|
||||
|
||||
|
||||
|
||||
Result: OK - IDLE completed after client sent "DONE"
|
||||
NO - failure: the server will not allow the IDLE
|
||||
command at this time
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The IDLE command may be used with any IMAP4 server implementation
|
||||
that returns "IDLE" as one of the supported capabilities to the
|
||||
CAPABILITY command. If the server does not advertise the IDLE
|
||||
capability, the client MUST NOT use the IDLE command and must poll
|
||||
for mailbox updates. In particular, the client MUST continue to be
|
||||
able to accept unsolicited untagged responses to ANY command, as
|
||||
specified in the base IMAP specification.
|
||||
|
||||
The IDLE command is sent from the client to the server when the
|
||||
client is ready to accept unsolicited mailbox update messages. The
|
||||
server requests a response to the IDLE command using the continuation
|
||||
("+") response. The IDLE command remains active until the client
|
||||
responds to the continuation, and as long as an IDLE command is
|
||||
active, the server is now free to send untagged EXISTS, EXPUNGE, and
|
||||
other messages at any time.
|
||||
|
||||
The IDLE command is terminated by the receipt of a "DONE"
|
||||
continuation from the client; such response satisfies the server's
|
||||
continuation request. At that point, the server MAY send any
|
||||
remaining queued untagged responses and then MUST immediately send
|
||||
the tagged response to the IDLE command and prepare to process other
|
||||
commands. As in the base specification, the processing of any new
|
||||
command may cause the sending of unsolicited untagged responses,
|
||||
subject to the ambiguity limitations. The client MUST NOT send a
|
||||
command while the server is waiting for the DONE, since the server
|
||||
will not be able to distinguish a command from a continuation.
|
||||
|
||||
The server MAY consider a client inactive if it has an IDLE command
|
||||
running, and if such a server has an inactivity timeout it MAY log
|
||||
the client off implicitly at the end of its timeout period. Because
|
||||
of that, clients using IDLE are advised to terminate the IDLE and
|
||||
re-issue it at least every 29 minutes to avoid being logged off.
|
||||
This still allows a client to receive immediate mailbox updates even
|
||||
though it need only "poll" at half hour intervals.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Leiba Standards Track [Page 2]
|
||||
|
||||
RFC 2177 IMAP4 IDLE command June 1997
|
||||
|
||||
|
||||
Example: C: A001 SELECT INBOX
|
||||
S: * FLAGS (Deleted Seen)
|
||||
S: * 3 EXISTS
|
||||
S: * 0 RECENT
|
||||
S: * OK [UIDVALIDITY 1]
|
||||
S: A001 OK SELECT completed
|
||||
C: A002 IDLE
|
||||
S: + idling
|
||||
...time passes; new mail arrives...
|
||||
S: * 4 EXISTS
|
||||
C: DONE
|
||||
S: A002 OK IDLE terminated
|
||||
...another client expunges message 2 now...
|
||||
C: A003 FETCH 4 ALL
|
||||
S: * 4 FETCH (...)
|
||||
S: A003 OK FETCH completed
|
||||
C: A004 IDLE
|
||||
S: * 2 EXPUNGE
|
||||
S: * 3 EXISTS
|
||||
S: + idling
|
||||
...time passes; another client expunges message 3...
|
||||
S: * 3 EXPUNGE
|
||||
S: * 2 EXISTS
|
||||
...time passes; new mail arrives...
|
||||
S: * 3 EXISTS
|
||||
C: DONE
|
||||
S: A004 OK IDLE terminated
|
||||
C: A005 FETCH 3 ALL
|
||||
S: * 3 FETCH (...)
|
||||
S: A005 OK FETCH completed
|
||||
C: A006 IDLE
|
||||
|
||||
4. Formal Syntax
|
||||
|
||||
The following syntax specification uses the augmented Backus-Naur
|
||||
Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
|
||||
Non-terminals referenced but not defined below are as defined by
|
||||
[IMAP4].
|
||||
|
||||
command_auth ::= append / create / delete / examine / list / lsub /
|
||||
rename / select / status / subscribe / unsubscribe
|
||||
/ idle
|
||||
;; Valid only in Authenticated or Selected state
|
||||
|
||||
idle ::= "IDLE" CRLF "DONE"
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Leiba Standards Track [Page 3]
|
||||
|
||||
RFC 2177 IMAP4 IDLE command June 1997
|
||||
|
||||
|
||||
5. References
|
||||
|
||||
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
|
||||
4rev1", RFC 2060, December 1996.
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
There are no known security issues with this extension.
|
||||
|
||||
7. Author's Address
|
||||
|
||||
Barry Leiba
|
||||
IBM T.J. Watson Research Center
|
||||
30 Saw Mill River Road
|
||||
Hawthorne, NY 10532
|
||||
|
||||
Email: leiba@watson.ibm.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Leiba Standards Track [Page 4]
|
||||
|
||||
787
docs/rfc/rfc2180.txt
Normal file
787
docs/rfc/rfc2180.txt
Normal file
@ -0,0 +1,787 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Gahrns
|
||||
Request for Comments: 2180 Microsoft
|
||||
Category: Informational July 1997
|
||||
|
||||
|
||||
IMAP4 Multi-Accessed Mailbox Practice
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This memo provides information for the Internet community. This memo
|
||||
does not specify an Internet standard of any kind. Distribution of
|
||||
this memo is unlimited.
|
||||
|
||||
1. Abstract
|
||||
|
||||
IMAP4[RFC-2060] is rich client/server protocol that allows a client
|
||||
to access and manipulate electronic mail messages on a server.
|
||||
Within the protocol framework, it is possible to have differing
|
||||
results for particular client/server interactions. If a protocol does
|
||||
not allow for this, it is often unduly restrictive.
|
||||
|
||||
For example, when multiple clients are accessing a mailbox and one
|
||||
attempts to delete the mailbox, an IMAP4 server may choose to
|
||||
implement a solution based upon server architectural constraints or
|
||||
individual preference.
|
||||
|
||||
With this flexibility comes greater client responsibility. It is not
|
||||
sufficient for a client to be written based upon the behavior of a
|
||||
particular IMAP server. Rather the client must be based upon the
|
||||
behavior allowed by the protocol.
|
||||
|
||||
By documenting common IMAP4 server practice for the case of
|
||||
simultaneous client access to a mailbox, we hope to ensure the widest
|
||||
amount of inter-operation between IMAP4 clients and servers.
|
||||
|
||||
The behavior described in this document reflects the practice of some
|
||||
existing servers or behavior that the consensus of the IMAP mailing
|
||||
list has deemed to be reasonable. The behavior described within this
|
||||
document is believed to be [RFC-2060] compliant. However, this
|
||||
document is not meant to define IMAP4 compliance, nor is it an
|
||||
exhaustive list of valid IMAP4 behavior. [RFC-2060] must always be
|
||||
consulted to determine IMAP4 compliance, especially for server
|
||||
behavior not described within this document.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 1]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
2. Conventions used in this document
|
||||
|
||||
In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different
|
||||
clients (client #1, client #2 and client #3) that are connected to a
|
||||
server. "S1:", "S2:" and "S3:" indicated lines sent by the server to
|
||||
client #1, client #2 and client #3 respectively.
|
||||
|
||||
A shared mailbox, is a mailbox that can be used by multiple users.
|
||||
|
||||
A multi-accessed mailbox, is a mailbox that has multiple clients
|
||||
simultaneously accessing it.
|
||||
|
||||
A client is said to have accessed a mailbox after a successful SELECT
|
||||
or EXAMINE command.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC-2119].
|
||||
|
||||
|
||||
3. Deletion/Renaming of a multi-accessed mailbox
|
||||
|
||||
If an external agent or multiple clients are accessing a mailbox,
|
||||
care must be taken when handling the deletion or renaming of the
|
||||
mailbox. Following are some strategies an IMAP server may choose to
|
||||
use when dealing with this situation.
|
||||
|
||||
|
||||
3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed
|
||||
mailbox
|
||||
|
||||
In some cases, this behavior may not be practical. For example, if a
|
||||
large number of clients are accessing a shared mailbox, the window in
|
||||
which no clients have the mailbox accessed may be small or non-
|
||||
existent, effectively rendering the mailbox undeletable or
|
||||
unrenamable.
|
||||
|
||||
Example:
|
||||
|
||||
<Client #1 and Client #2 have mailbox FOO accessed. Client #1 tries
|
||||
to DELETE the mailbox and is refused>
|
||||
|
||||
C1: A001 DELETE FOO
|
||||
S1: A001 NO Mailbox FOO is in use by another user.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 2]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
3.2. The server MAY allow the DELETE command of a multi-accessed
|
||||
mailbox, but keep the information in the mailbox available for
|
||||
those clients that currently have access to the mailbox.
|
||||
|
||||
When all clients have finished accessing the mailbox, it is
|
||||
permanently removed. For clients that do not already have access to
|
||||
the mailbox, the 'ghosted' mailbox would not be available. For
|
||||
example, it would not be returned to these clients in a subsequent
|
||||
LIST or LSUB command and would not be a valid mailbox argument to any
|
||||
other IMAP command until the reference count of clients accessing the
|
||||
mailbox reached 0.
|
||||
|
||||
In some cases, this behavior may not be desirable. For example if
|
||||
someone created a mailbox with offensive or sensitive information,
|
||||
one might prefer to have the mailbox deleted and all access to the
|
||||
information contained within removed immediately, rather than
|
||||
continuing to allow access until the client closes the mailbox.
|
||||
|
||||
Furthermore, this behavior, may prevent 'recycling' of the same
|
||||
mailbox name until all clients have finished accessing the original
|
||||
mailbox.
|
||||
|
||||
Example:
|
||||
|
||||
<Client #1 and Client #2 have mailbox FOO selected. Client #1 DELETEs
|
||||
mailbox FOO>
|
||||
|
||||
C1: A001 DELETE FOO
|
||||
S1: A001 OK Mailbox FOO is deleted.
|
||||
|
||||
<Client #2 is still able to operate on the deleted mailbox>
|
||||
|
||||
C2: B001 STORE 1 +FLAGS (\Seen)
|
||||
S2: * 1 FETCH FLAGS (\Seen)
|
||||
S2: B001 OK STORE completed
|
||||
|
||||
<Client #3 which did not have access to the mailbox prior to the
|
||||
deletion by client #1 does not have access to the mailbox>
|
||||
|
||||
C3: C001 STATUS FOO (MESSAGES)
|
||||
S3: C001 NO Mailbox does not exist
|
||||
|
||||
<Nor is client #3 able to create a mailbox with the name FOO, while
|
||||
the reference count is non zero>
|
||||
|
||||
C3: C002 CREATE FOO
|
||||
S3: C002 NO Mailbox FOO is still in use. Try again later.
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 3]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
<Client #2 closes its access to the mailbox, no other clients have
|
||||
access to the mailbox FOO and reference count becomes 0>
|
||||
|
||||
C2: B002 CLOSE
|
||||
S2: B002 OK CLOSE Completed
|
||||
|
||||
<Now that the reference count on FOO has reached 0, the mailbox name
|
||||
can be recycled>
|
||||
|
||||
C3: C003 CREATE FOO
|
||||
S3: C003 OK CREATE Completed
|
||||
|
||||
|
||||
3.3. The server MAY allow the DELETE/RENAME of a multi-accessed
|
||||
mailbox, but disconnect all other clients who have the mailbox
|
||||
accessed by sending a untagged BYE response.
|
||||
|
||||
A server may often choose to disconnect clients in the DELETE case,
|
||||
but may choose to implement a "friendlier" method for the RENAME
|
||||
case.
|
||||
|
||||
Example:
|
||||
|
||||
<Client #1 and Client #2 have mailbox FOO accessed. Client #1 DELETEs
|
||||
the mailbox FOO>
|
||||
|
||||
C1: A002 DELETE FOO
|
||||
S1: A002 OK DELETE completed.
|
||||
|
||||
<Server disconnects all other users of the mailbox>
|
||||
S2: * BYE Mailbox FOO has been deleted.
|
||||
|
||||
|
||||
3.4. The server MAY allow the RENAME of a multi-accessed mailbox by
|
||||
simply changing the name attribute on the mailbox.
|
||||
|
||||
Other clients that have access to the mailbox can continue issuing
|
||||
commands such as FETCH that do not reference the mailbox name.
|
||||
Clients would discover the renaming the next time they referred to
|
||||
the old mailbox name. Some servers MAY choose to include the
|
||||
[NEWNAME] response code in their tagged NO response to a command that
|
||||
contained the old mailbox name, as a hint to the client that the
|
||||
operation can succeed if the command is issued with the new mailbox
|
||||
name.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 4]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
<Client #1 and Client #2 have mailbox FOO accessed. Client #1 RENAMEs
|
||||
the mailbox.>
|
||||
|
||||
C1: A001 RENAME FOO BAR
|
||||
S1: A001 OK RENAME completed.
|
||||
|
||||
<Client #2 is still able to do operations that do not reference the
|
||||
mailbox name>
|
||||
|
||||
C2: B001 FETCH 2:4 (FLAGS)
|
||||
S2: * 2 FETCH . . .
|
||||
S2: * 3 FETCH . . .
|
||||
S2: * 4 FETCH . . .
|
||||
S2: B001 OK FETCH completed
|
||||
|
||||
<Client #2 is not able to do operations that reference the mailbox
|
||||
name>
|
||||
|
||||
C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994
|
||||
21:52:25 0800 (PST) C2: . . . S2: B002 NO [NEWNAME FOO
|
||||
BAR] Mailbox has been renamed
|
||||
|
||||
|
||||
4. Expunging of messages on a multi-accessed mailbox
|
||||
|
||||
If an external agent or multiple clients are accessing a mailbox,
|
||||
care must be taken when handling the EXPUNGE of messages. Other
|
||||
clients accessing the mailbox may be in the midst of issuing a
|
||||
command that depends upon message sequence numbers. Because an
|
||||
EXPUNGE response can not be sent while responding to a FETCH, STORE
|
||||
or SEARCH command, it is not possible to immediately notify the
|
||||
client of the EXPUNGE. This can result in ambiguity if the client
|
||||
issues a FETCH, STORE or SEARCH operation on a message that has been
|
||||
EXPUNGED.
|
||||
|
||||
|
||||
4.1. Fetching of expunged messages
|
||||
|
||||
Following are some strategies an IMAP server may choose to use when
|
||||
dealing with a FETCH command on expunged messages.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 5]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
Consider the following scenario:
|
||||
|
||||
- Client #1 and Client #2 have mailbox FOO selected.
|
||||
- There are 7 messages in the mailbox.
|
||||
- Messages 4:7 are marked for deletion.
|
||||
- Client #1 issues an EXPUNGE, to expunge messages 4:7
|
||||
|
||||
|
||||
4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but
|
||||
keep the messages available to satisfy subsequent FETCH commands
|
||||
until it is able to send an EXPUNGE response to each client.
|
||||
|
||||
In some cases, the behavior of keeping "ghosted" messages may not be
|
||||
desirable. For example if a message contained offensive or sensitive
|
||||
information, one might prefer to instantaneously remove all access to
|
||||
the information, regardless of whether another client is in the midst
|
||||
of accessing it.
|
||||
|
||||
Example: (Building upon the scenario outlined in 4.1.)
|
||||
|
||||
<Client #2 is still able to access the expunged messages because the
|
||||
server has kept a 'ghosted' copy of the messages until it is able to
|
||||
notify client #2 of the EXPUNGE>
|
||||
|
||||
C2: B001 FETCH 4:7 RFC822
|
||||
S2: * 4 FETCH RFC822 . . . (RFC822 info returned)
|
||||
S2: * 5 FETCH RFC822 . . . (RFC822 info returned)
|
||||
S2: * 6 FETCH RFC822 . . . (RFC822 info returned)
|
||||
S2: * 7 FETCH RFC822 . . . (RFC822 info returned)
|
||||
S2: B001 OK FETCH Completed
|
||||
|
||||
<Client #2 issues a command where it can get notified of the EXPUNGE>
|
||||
|
||||
C2: B002 NOOP
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 3 EXISTS
|
||||
S2: B002 OK NOOP Complete
|
||||
|
||||
<Client #2 no longer has access to the expunged messages>
|
||||
|
||||
C2: B003 FETCH 4:7 RFC822
|
||||
S2: B003 NO Messages 4:7 are no longer available.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 6]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox,
|
||||
and on subsequent FETCH commands return FETCH responses only for
|
||||
non-expunged messages and a tagged NO.
|
||||
|
||||
After receiving a tagged NO FETCH response, the client SHOULD issue a
|
||||
NOOP command so that it will be informed of any pending EXPUNGE
|
||||
responses. The client may then either reissue the failed FETCH
|
||||
command, or by examining the EXPUNGE response from the NOOP and the
|
||||
FETCH response from the FETCH, determine that the FETCH failed
|
||||
because of pending expunges.
|
||||
|
||||
Example: (Building upon the scenario outlined in 4.1.)
|
||||
|
||||
<Client #2 attempts to FETCH a mix of expunged and non-expunged
|
||||
messages. A FETCH response is returned only for then non-expunged
|
||||
messages along with a tagged NO>
|
||||
|
||||
C2: B001 FETCH 3:5 ENVELOPE
|
||||
S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
|
||||
S2: B001 NO Some of the requested messages no longer exist
|
||||
|
||||
<Upon receiving a tagged NO FETCH response, Client #2 issues a NOOP
|
||||
to be informed of any pending EXPUNGE responses>
|
||||
|
||||
C2: B002 NOOP
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 3 EXISTS
|
||||
S2: B002 OK NOOP Completed.
|
||||
|
||||
<By receiving a FETCH response for message 3, and an EXPUNGE response
|
||||
that indicates messages 4:7 have been expunged, the client does not
|
||||
need to re-issue the FETCH>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 7]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and
|
||||
on subsequent FETCH commands return the usual FETCH responses for
|
||||
non-expunged messages, "NIL FETCH Responses" for expunged
|
||||
messages, and a tagged OK response.
|
||||
|
||||
If all of the messages in the subsequent FETCH command have been
|
||||
expunged, the server SHOULD return only a tagged NO. In this case,
|
||||
the client SHOULD issue a NOOP command so that it will be informed of
|
||||
any pending EXPUNGE responses. The client may then either reissue
|
||||
the failed FETCH command, or by examining the EXPUNGE response from
|
||||
the NOOP, determine that the FETCH failed because of pending
|
||||
expunges.
|
||||
|
||||
"NIL FETCH responses" are a representation of empty data as
|
||||
appropriate for the FETCH argument specified.
|
||||
|
||||
Example:
|
||||
|
||||
* 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL))
|
||||
* 1 FETCH (FLAGS ())
|
||||
* 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000")
|
||||
* 1 FETCH (RFC822 "")
|
||||
* 1 FETCH (RFC822.HEADER "")
|
||||
* 1 FETCH (RFC822.TEXT "")
|
||||
* 1 FETCH (RFC822.SIZE 0)
|
||||
* 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
|
||||
* 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
|
||||
* 1 FETCH (BODY[<section>] "")
|
||||
* 1 FETCH (BODY[<section>]<partial> "")
|
||||
|
||||
In some cases, a client may not be able to distinguish between "NIL
|
||||
FETCH responses" received because a message was expunged and those
|
||||
received because the data actually was NIL. For example, a * 5
|
||||
FETCH (FLAGS ()) response could be received if no flags were set on
|
||||
message 5, or because message 5 was expunged. In a case of potential
|
||||
ambiguity, the client SHOULD issue a command such as NOOP to force
|
||||
the sending of the EXPUNGE responses to resolve any ambiguity.
|
||||
|
||||
Example: (Building upon the scenario outlined in 4.1.)
|
||||
|
||||
<Client #2 attempts to access a mix of expunged and non-expunged
|
||||
messages. Normal data is returned for non-expunged message, "NIL
|
||||
FETCH responses" are returned for expunged messages>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 8]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
C2: B002 FETCH 3:5 ENVELOPE
|
||||
S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
|
||||
S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
|
||||
NIL NIL)
|
||||
S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
|
||||
NIL NIL)
|
||||
S2: B002 OK FETCH Completed
|
||||
|
||||
<Client #2 attempts to FETCH only expunged messages and receives a
|
||||
tagged NO response>
|
||||
|
||||
C2: B002 FETCH 4:7 ENVELOPE
|
||||
S2: B002 NO Messages 4:7 have been expunged.
|
||||
|
||||
|
||||
4.1.4 To avoid the situation altogether, the server MAY fail the
|
||||
EXPUNGE of a multi-accessed mailbox
|
||||
|
||||
In some cases, this behavior may not be practical. For example, if a
|
||||
large number of clients are accessing a shared mailbox, the window in
|
||||
which no clients have the mailbox accessed may be small or non-
|
||||
existent, effectively rendering the message unexpungeable.
|
||||
|
||||
|
||||
4.2. Storing of expunged messages
|
||||
|
||||
Following are some strategies an IMAP server may choose to use when
|
||||
dealing with a STORE command on expunged messages.
|
||||
|
||||
|
||||
4.2.1 If the ".SILENT" suffix is used, and the STORE completed
|
||||
successfully for all the non-expunged messages, the server SHOULD
|
||||
return a tagged OK.
|
||||
|
||||
Example: (Building upon the scenario outlined in 4.1.)
|
||||
|
||||
<Client #2 tries to silently STORE flags on expunged and non-
|
||||
expunged messages. The server sets the flags on the non-expunged
|
||||
messages and returns OK>
|
||||
|
||||
C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)
|
||||
S2: B001 OK
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 9]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
4.2.2. If the ".SILENT" suffix is not used, and only expunged messages
|
||||
are referenced, the server SHOULD return only a tagged NO.
|
||||
|
||||
Example: (Building upon the scenario outlined in 4.1.)
|
||||
|
||||
<Client #2 tries to STORE flags only on expunged messages>
|
||||
|
||||
C2: B001 STORE 5:7 +FLAGS (\SEEN)
|
||||
S2: B001 NO Messages have been expunged
|
||||
|
||||
|
||||
4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged
|
||||
and non-expunged messages are referenced, the server MAY set the
|
||||
flags and return a FETCH response for the non-expunged messages
|
||||
along with a tagged NO.
|
||||
|
||||
After receiving a tagged NO STORE response, the client SHOULD issue a
|
||||
NOOP command so that it will be informed of any pending EXPUNGE
|
||||
responses. The client may then either reissue the failed STORE
|
||||
command, or by examining the EXPUNGE responses from the NOOP and
|
||||
FETCH responses from the STORE, determine that the STORE failed
|
||||
because of pending expunges.
|
||||
|
||||
Example: (Building upon the scenario outlined in 4.1.)
|
||||
|
||||
<Client #2 tries to STORE flags on a mixture of expunged and non-
|
||||
expunged messages>
|
||||
|
||||
C2: B001 STORE 1:7 +FLAGS (\SEEN)
|
||||
S2: * FETCH 1 FLAGS (\SEEN)
|
||||
S2: * FETCH 2 FLAGS (\SEEN)
|
||||
S2: * FETCH 3 FLAGS (\SEEN)
|
||||
S2: B001 NO Some of the messages no longer exist.
|
||||
|
||||
C2: B002 NOOP
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 3 EXISTS
|
||||
S2: B002 OK NOOP Completed.
|
||||
|
||||
<By receiving FETCH responses for messages 1:3, and an EXPUNGE
|
||||
response that indicates messages 4:7 have been expunged, the client
|
||||
does not need to re-issue the STORE>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 10]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged
|
||||
and non-expunged messages are referenced, the server MAY return
|
||||
an untagged NO and not set any flags.
|
||||
|
||||
After receiving a tagged NO STORE response, the client SHOULD issue a
|
||||
NOOP command so that it will be informed of any pending EXPUNGE
|
||||
responses. The client would then re-issue the STORE command after
|
||||
updating its message list per any EXPUNGE response.
|
||||
|
||||
If a large number of clients are accessing a shared mailbox, the
|
||||
window in which there are no pending expunges may be small or non-
|
||||
existent, effectively disallowing a client from setting the flags on
|
||||
all messages at once.
|
||||
|
||||
Example: (Building upon the scenario outlined in 4.1.)
|
||||
|
||||
<Client #2 tries to STORE flags on a mixture of expunged and non-
|
||||
expunged messages>
|
||||
|
||||
C2: B001 STORE 1:7 +FLAGS (\SEEN)
|
||||
S2: B001 NO Some of the messages no longer exist.
|
||||
|
||||
<Client #2 issues a NOOP to be informed of the EXPUNGED messages>
|
||||
|
||||
C2: B002 NOOP
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 4 EXPUNGE
|
||||
S2: * 3 EXISTS
|
||||
S2: B002 OK NOOP Completed.
|
||||
|
||||
<Client #2 updates its message list and re-issues the STORE on only
|
||||
those messages that have not been expunged>
|
||||
|
||||
C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS
|
||||
(\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS
|
||||
(\SEEN) S2: B003 OK STORE Completed
|
||||
|
||||
|
||||
4.3. Searching of expunged messages
|
||||
|
||||
A server MAY simply not return a search response for messages that
|
||||
have been expunged and it has not been able to inform the client
|
||||
about. If a client was expecting a particular message to be returned
|
||||
in a search result, and it was not, the client SHOULD issue a NOOP
|
||||
command to see if the message was expunged by another client.
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 11]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
4.4 Copying of expunged messages
|
||||
|
||||
COPY is the only IMAP4 sequence number command that is safe to allow
|
||||
an EXPUNGE response on. This is because a client is not permitted to
|
||||
cascade several COPY commands together. A client is required to wait
|
||||
and confirm that the copy worked before issuing another one.
|
||||
|
||||
4.4.1 The server MAY disallow the COPY of messages in a multi-access
|
||||
mailbox that contains expunged messages.
|
||||
|
||||
Pending EXPUNGE response(s) MUST be returned to the COPY command.
|
||||
|
||||
Example:
|
||||
|
||||
C: A001 COPY 2,4,6,8 FRED
|
||||
S: * 4 EXPUNGE
|
||||
S: A001 NO COPY rejected, because some of the requested
|
||||
messages were expunged
|
||||
|
||||
Note: Non of the above messages are copied because if a COPY command
|
||||
is unsuccessful, the server MUST restore the destination mailbox to
|
||||
its state before the COPY attempt.
|
||||
|
||||
|
||||
4.4.2 The server MAY allow the COPY of messages in a multi-access
|
||||
mailbox that contains expunged messages.
|
||||
|
||||
Pending EXPUNGE response(s) MUST be returned to the COPY command.
|
||||
Messages that are copied are messages corresponding to sequence
|
||||
numbers before any EXPUNGE response.
|
||||
|
||||
Example:
|
||||
|
||||
C: A001 COPY 2,4,6,8 FRED
|
||||
S: * 3 EXPUNGE
|
||||
S: A001 OK COPY completed
|
||||
|
||||
In the above example, the messages that are copied to FRED are
|
||||
messages 2,4,6,8 at the start of the COPY command. These are
|
||||
equivalent to messages 2,3,5,7 at the end of the COPY command. The
|
||||
EXPUNGE response can't take place until after the messages from the
|
||||
COPY command are identified (because of the "no expunge while no
|
||||
commands in progress" rule).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 12]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
C: A001 COPY 2,4,6,8 FRED
|
||||
S: * 4 EXPUNGE
|
||||
S: A001 OK COPY completed
|
||||
|
||||
In the above example, message 4 was copied before it was expunged,
|
||||
and MUST appear in the destination mailbox FRED.
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
This document describes behavior of servers that use the IMAP4
|
||||
protocol, and as such, has the same security considerations as
|
||||
described in [RFC-2060].
|
||||
|
||||
In particular, some described server behavior does not allow for the
|
||||
immediate deletion of information when a mailbox is accessed by
|
||||
multiple clients. This may be a consideration when dealing with
|
||||
sensitive information where immediate deletion would be preferred.
|
||||
|
||||
|
||||
6. References
|
||||
|
||||
[RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
|
||||
4rev1", RFC 2060, University of Washington, December 1996.
|
||||
|
||||
[RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", RFC 2119, Harvard University, March 1997.
|
||||
|
||||
|
||||
7. Acknowledgments
|
||||
|
||||
This document is the result of discussions on the IMAP4 mailing list
|
||||
and is meant to reflect consensus of this group. In particular,
|
||||
Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole,
|
||||
Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry
|
||||
Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De
|
||||
Winter were active participants in this discussion or made
|
||||
suggestions to this document.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 13]
|
||||
|
||||
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
|
||||
|
||||
|
||||
8. Author's Address
|
||||
|
||||
Mike Gahrns
|
||||
Microsoft
|
||||
One Microsoft Way
|
||||
Redmond, WA, 98072
|
||||
|
||||
Phone: (206) 936-9833
|
||||
EMail: mikega@microsoft.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Informational [Page 14]
|
||||
|
||||
507
docs/rfc/rfc2193.txt
Normal file
507
docs/rfc/rfc2193.txt
Normal file
@ -0,0 +1,507 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Gahrns
|
||||
Request for Comments: 2193 Microsoft
|
||||
Category: Standards Track September 1997
|
||||
|
||||
|
||||
IMAP4 Mailbox Referrals
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
1. Abstract
|
||||
|
||||
When dealing with large amounts of users, messages and geographically
|
||||
dispersed IMAP4 [RFC-2060] servers, it is often desirable to
|
||||
distribute messages amongst different servers within an organization.
|
||||
For example an administrator may choose to store user's personal
|
||||
mailboxes on a local IMAP4 server, while storing shared mailboxes
|
||||
remotely on another server. This type of configuration is common
|
||||
when it is uneconomical to store all data centrally due to limited
|
||||
bandwidth or disk resources.
|
||||
|
||||
Mailbox referrals allow clients to seamlessly access mailboxes that
|
||||
are distributed across several IMAP4 servers.
|
||||
|
||||
A referral mechanism can provide efficiencies over the alternative
|
||||
"proxy method", in which the local IMAP4 server contacts the remote
|
||||
server on behalf of the client, and then transfers the data from the
|
||||
remote server to itself, and then on to the client. The referral
|
||||
mechanism's direct client connection to the remote server is often a
|
||||
more efficient use of bandwidth, and does not require the local
|
||||
server to impersonate the client when authenticating to the remote
|
||||
server.
|
||||
|
||||
2. Conventions used in this document
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server respectively.
|
||||
|
||||
A home server, is an IMAP4 server that contains the user's inbox.
|
||||
|
||||
A remote mailbox is a mailbox that is not hosted on the user's home
|
||||
server.
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 1]
|
||||
|
||||
RFC 2193 IMAP4 Mailbox Referrals September 1997
|
||||
|
||||
|
||||
A remote server is a server that contains remote mailboxes.
|
||||
|
||||
A shared mailbox, is a mailbox that multiple users have access to.
|
||||
|
||||
An IMAP mailbox referral is when the server directs the client to
|
||||
another IMAP mailbox.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC-2119].
|
||||
|
||||
3. Introduction and Overview
|
||||
|
||||
IMAP4 servers that support this extension MUST list the keyword
|
||||
MAILBOX-REFERRALS in their CAPABILITY response. No client action is
|
||||
needed to invoke the MAILBOX-REFERRALS capability in a server.
|
||||
|
||||
A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals
|
||||
that result in a referrals loop.
|
||||
|
||||
A referral response consists of a tagged NO response and a REFERRAL
|
||||
response code. The REFERRAL response code MUST contain as an
|
||||
argument a one or more valid URLs separated by a space as defined in
|
||||
[RFC-1738]. If a server replies with multiple URLs for a particular
|
||||
object, they MUST all be of the same type. In this case, the URL MUST
|
||||
be an IMAP URL as defined in [RFC-2192]. A client that supports the
|
||||
REFERRALS extension MUST be prepared for a URL of any type, but it
|
||||
need only be able to process IMAP URLs.
|
||||
|
||||
A server MAY respond with multiple IMAP mailbox referrals if there is
|
||||
more than one replica of the mailbox. This allows the implementation
|
||||
of a load balancing or failover scheme. How a server keeps multiple
|
||||
replicas of a mailbox in sync is not addressed by this document.
|
||||
|
||||
If the server has a preferred order in which the client should
|
||||
attempt to access the URLs, the preferred URL SHOULD be listed in the
|
||||
first, with the remaining URLs presented in descending order of
|
||||
preference. If multiple referrals are given for a mailbox, a server
|
||||
should be aware that there are synchronization issues for a client if
|
||||
the UIDVALIDITY of the referred mailboxes are different.
|
||||
|
||||
An IMAP mailbox referral may be given in response to an IMAP command
|
||||
that specifies a mailbox as an argument.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 2]
|
||||
|
||||
RFC 2193 IMAP4 Mailbox Referrals September 1997
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE]Remote Mailbox
|
||||
|
||||
NOTE: user;AUTH=* is specified as required by [RFC-2192] to avoid a
|
||||
client falling back to anonymous login.
|
||||
|
||||
Remote mailboxes and their inferiors, that are accessible only via
|
||||
referrals SHOULD NOT appear in LIST and LSUB responses issued against
|
||||
the user's home server. They MUST appear in RLIST and RLSUB
|
||||
responses issued against the user's home server. Hierarchy referrals,
|
||||
in which a client would be required to connect to the remote server
|
||||
to issue a LIST to discover the inferiors of a mailbox are not
|
||||
addressed in this document.
|
||||
|
||||
For example, if shared mailboxes were only accessible via referrals
|
||||
on a remote server, a RLIST "" "#SHARED/%" command would return the
|
||||
same response if issued against the user's home server or the remote
|
||||
server.
|
||||
|
||||
Note: Mailboxes that are available on the user's home server do not
|
||||
need to be available on the remote server. In addition, there may be
|
||||
additional mailboxes available on the remote server, but they will
|
||||
not accessible to the client via referrals unless they appear in the
|
||||
LIST response to the RLIST command against the user's home server.
|
||||
|
||||
A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB
|
||||
commands in lieu of LIST and LSUB. The RLIST and RLSUB commands
|
||||
behave identically to their LIST and LSUB counterparts, except remote
|
||||
mailboxes are returned in addition to local mailboxes in the LIST and
|
||||
LSUB responses. This avoids displaying to a non MAILBOX-REFERRALS
|
||||
enabled client inaccessible remote mailboxes.
|
||||
|
||||
4.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND
|
||||
Referrals
|
||||
|
||||
An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE,
|
||||
SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more
|
||||
IMAP mailbox referrals to indicate to the client that the mailbox is
|
||||
hosted on a remote server.
|
||||
|
||||
When a client processes an IMAP mailbox referral, it will open a new
|
||||
connection or use an existing connection to the remote server so that
|
||||
it is able to issue the commands necessary to process the remote
|
||||
mailbox.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 3]
|
||||
|
||||
RFC 2193 IMAP4 Mailbox Referrals September 1997
|
||||
|
||||
|
||||
Example: <IMAP4 connection to home server>
|
||||
|
||||
C: A001 DELETE "SHARED/FOO"
|
||||
S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
|
||||
Remote mailbox. Try SERVER2.
|
||||
|
||||
<Client established a second connection to SERVER2 and
|
||||
issues the DELETE command on the referred mailbox>
|
||||
|
||||
S: * OK IMAP4rev1 server ready
|
||||
C: B001 AUTHENTICATE KERBEROS_V4
|
||||
<authentication exchange>
|
||||
S: B001 OK user is authenticated
|
||||
|
||||
C: B002 DELETE "SHARED/FOO"
|
||||
S: B002 OK DELETE completed
|
||||
|
||||
Example: <IMAP4 connection to home server>
|
||||
|
||||
C: A001 SELECT REMOTE
|
||||
S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE
|
||||
IMAP://user;AUTH=*@SERVER3/REMOTE] Remote mailbox.
|
||||
Try SERVER2 or SERVER3.
|
||||
|
||||
<Client opens second connection to remote server, and
|
||||
issues the commands needed to process the items in the
|
||||
remote mailbox>
|
||||
|
||||
S: * OK IMAP4rev1 server ready
|
||||
C: B001 AUTHENTICATE KERBEROS_V4
|
||||
<authentication exchange>
|
||||
S: B001 OK user is authenticated
|
||||
|
||||
C: B002 SELECT REMOTE
|
||||
S: * 12 EXISTS
|
||||
S: * 1 RECENT
|
||||
S: * OK [UNSEEN 10] Message 10 is first unseen
|
||||
S: * OK [UIDVALIDITY 123456789]
|
||||
S: * FLAGS (Answered Flagged Deleted Seen Draft)
|
||||
S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
|
||||
S: B002 OK [READ-WRITE] Selected completed
|
||||
|
||||
C: B003 FETCH 10:12 RFC822
|
||||
S: * 10 FETCH . . .
|
||||
S: * 11 FETCH . . .
|
||||
S: * 12 FETCH . . .
|
||||
S: B003 OK FETCH Completed
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 4]
|
||||
|
||||
RFC 2193 IMAP4 Mailbox Referrals September 1997
|
||||
|
||||
|
||||
<Client is finished processing the REMOTE mailbox and
|
||||
wants to process a mailbox on its home server>
|
||||
|
||||
C: B004 LOGOUT
|
||||
S: * BYE IMAP4rev1 server logging out
|
||||
S: B004 OK LOGOUT Completed
|
||||
|
||||
<Client continues with first connection>
|
||||
|
||||
C: A002 SELECT INBOX
|
||||
S: * 16 EXISTS
|
||||
S: * 2 RECENT
|
||||
S: * OK [UNSEEN 10] Message 10 is first unseen
|
||||
S: * OK [UIDVALIDITY 123456789]
|
||||
S: * FLAGS (Answered Flagged Deleted Seen Draft)
|
||||
S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
|
||||
S: A002 OK [READ-WRITE] Selected completed
|
||||
|
||||
4.2. CREATE Referrals
|
||||
|
||||
An IMAP4 server MAY respond to the CREATE command with one or more
|
||||
IMAP mailbox referrals, if it wishes to direct the client to issue
|
||||
the CREATE against another server. The server can employ any means,
|
||||
such as examining the hierarchy of the specified mailbox name, in
|
||||
determining which server the mailbox should be created on.
|
||||
|
||||
Example:
|
||||
|
||||
C: A001 CREATE "SHARED/FOO"
|
||||
S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
|
||||
Mailbox should be created on remote server
|
||||
|
||||
Alternatively, because a home server is required to maintain a
|
||||
listing of referred remote mailboxes, a server MAY allow the creation
|
||||
of a mailbox that will ultimately reside on a remote server against
|
||||
the home server, and provide referrals on subsequent commands that
|
||||
manipulate the mailbox.
|
||||
|
||||
Example:
|
||||
|
||||
C: A001 CREATE "SHARED/FOO"
|
||||
S: A001 OK CREATE succeeded
|
||||
|
||||
C: A002 SELECT "SHARED/FOO"
|
||||
S: A002 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
|
||||
Remote mailbox. Try SERVER2
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 5]
|
||||
|
||||
RFC 2193 IMAP4 Mailbox Referrals September 1997
|
||||
|
||||
|
||||
4.3. RENAME Referrals
|
||||
|
||||
An IMAP4 server MAY respond to the RENAME command with one or more
|
||||
pairs of IMAP mailbox referrals. In each pair of IMAP mailbox
|
||||
referrals, the first one is an URL to the existing mailbox name and
|
||||
the second is an URL to the requested new mailbox name.
|
||||
|
||||
If within an IMAP mailbox referral pair, the existing and new mailbox
|
||||
URLs are on different servers, the remote servers are unable to
|
||||
perform the RENAME operation. To achieve the same behavior of
|
||||
server RENAME, the client MAY issue the constituent CREATE, FETCH,
|
||||
APPEND, and DELETE commands against both servers.
|
||||
|
||||
If within an IMAP mailbox referral pair, the existing and new mailbox
|
||||
URLs are on the same server it is an indication that the currently
|
||||
connected server is unable to perform the operation. The client can
|
||||
simply re-issue the RENAME command on the remote server.
|
||||
|
||||
Example:
|
||||
|
||||
C: A001 RENAME FOO BAR
|
||||
S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER1/FOO
|
||||
IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
|
||||
across servers
|
||||
|
||||
Since the existing and new mailbox names are on different servers,
|
||||
the client would be required to make a connection to both servers and
|
||||
issue the constituent commands require to achieve the RENAME.
|
||||
|
||||
Example:
|
||||
|
||||
C: A001 RENAME FOO BAR
|
||||
S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/FOO
|
||||
IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
|
||||
located on SERVER2
|
||||
|
||||
Since both the existing and new mailbox are on the same remote
|
||||
server, the client can simply make a connection to the remote server
|
||||
and re-issue the RENAME command.
|
||||
|
||||
4.4. COPY Referrals
|
||||
|
||||
An IMAP4 server MAY respond to the COPY command with one or more IMAP
|
||||
mailbox referrals. This indicates that the destination mailbox is on
|
||||
a remote server. To achieve the same behavior of a server COPY, the
|
||||
client MAY issue the constituent FETCH and APPEND commands against
|
||||
both servers.
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 6]
|
||||
|
||||
RFC 2193 IMAP4 Mailbox Referrals September 1997
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
C: A001 COPY 1 "SHARED/STUFF"
|
||||
S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/STUFF]
|
||||
Unable to copy message(s) to SERVER2.
|
||||
|
||||
5.1 RLIST command
|
||||
|
||||
Arguments: reference name
|
||||
mailbox name with possible wildcards
|
||||
|
||||
Responses: untagged responses: LIST
|
||||
|
||||
Result: OK - RLIST Completed
|
||||
NO - RLIST Failure
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The RLIST command behaves identically to its LIST counterpart, except
|
||||
remote mailboxes are returned in addition to local mailboxes in the
|
||||
LIST responses.
|
||||
|
||||
5.2 RLSUB Command
|
||||
|
||||
Arguments: reference name
|
||||
mailbox name with possible wildcards
|
||||
|
||||
Responses: untagged responses: LSUB
|
||||
|
||||
Result: OK - RLSUB Completed
|
||||
NO - RLSUB Failure
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The RLSUB command behaves identically to its LSUB counterpart, except
|
||||
remote mailboxes are returned in addition to local mailboxes in the
|
||||
LSUB responses.
|
||||
|
||||
6. Formal Syntax
|
||||
|
||||
The following syntax specification uses the augmented Backus-Naur
|
||||
Form (BNF) as described in [ABNF].
|
||||
|
||||
list_mailbox = <list_mailbox> as defined in [RFC-2060]
|
||||
|
||||
mailbox = <mailbox> as defined in [RFC-2060]
|
||||
|
||||
mailbox_referral = <tag> SPACE "NO" SPACE
|
||||
<referral_response_code> (text / text_mime2)
|
||||
; See [RFC-2060] for <tag>, text and text_mime2 definition
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 7]
|
||||
|
||||
RFC 2193 IMAP4 Mailbox Referrals September 1997
|
||||
|
||||
|
||||
referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"
|
||||
; See [RFC-1738] for <url> definition
|
||||
|
||||
rlist = "RLIST" SPACE mailbox SPACE list_mailbox
|
||||
|
||||
rlsub = "RLSUB" SPACE mailbox SPACE list_mailbox
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
The IMAP4 referral mechanism makes use of IMAP URLs, and as such,
|
||||
have the same security considerations as general internet URLs [RFC-
|
||||
1738], and in particular IMAP URLs [RFC-2192].
|
||||
|
||||
With the MAILBOX-REFERRALS capability, it is potentially easier to
|
||||
write a rogue server that injects a bogus referral response that
|
||||
directs a user to an incorrect mailbox. Although referrals reduce
|
||||
the effort to write such a server, the referral response makes
|
||||
detection of the intrusion easier.
|
||||
|
||||
7. References
|
||||
|
||||
[RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
|
||||
4rev1", RFC 2060, University of Washington, December 1996.
|
||||
|
||||
[RFC-2192], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
|
||||
September 1997.
|
||||
|
||||
[RFC-1738], Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
|
||||
Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
|
||||
University of Minnesota, December 1994.
|
||||
|
||||
[RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", RFC 2119, Harvard University, March 1997.
|
||||
|
||||
[ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
|
||||
Syntax Specifications: ABNF", Work in Progress, Internet Mail
|
||||
Consortium, April 1997.
|
||||
|
||||
8. Acknowledgments
|
||||
|
||||
Many valuable suggestions were received from private discussions and
|
||||
the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin,
|
||||
Mark Keasling, Chris Newman and Larry Osterman made significant
|
||||
contributions to this document.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 8]
|
||||
|
||||
RFC 2193 IMAP4 Mailbox Referrals September 1997
|
||||
|
||||
|
||||
9. Author's Address
|
||||
|
||||
Mike Gahrns
|
||||
Microsoft
|
||||
One Microsoft Way
|
||||
Redmond, WA, 98072
|
||||
|
||||
Phone: (206) 936-9833
|
||||
EMail: mikega@microsoft.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 9]
|
||||
|
||||
283
docs/rfc/rfc2195.txt
Normal file
283
docs/rfc/rfc2195.txt
Normal file
@ -0,0 +1,283 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group J. Klensin
|
||||
Request for Comments: 2195 R. Catoe
|
||||
Category: Standards Track P. Krumviede
|
||||
Obsoletes: 2095 MCI
|
||||
September 1997
|
||||
|
||||
|
||||
IMAP/POP AUTHorize Extension for Simple Challenge/Response
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
While IMAP4 supports a number of strong authentication mechanisms as
|
||||
described in RFC 1731, it lacks any mechanism that neither passes
|
||||
cleartext, reusable passwords across the network nor requires either
|
||||
a significant security infrastructure or that the mail server update
|
||||
a mail-system-wide user authentication file on each mail access.
|
||||
This specification provides a simple challenge-response
|
||||
authentication protocol that is suitable for use with IMAP4. Since
|
||||
it utilizes Keyed-MD5 digests and does not require that the secret be
|
||||
stored in the clear on the server, it may also constitute an
|
||||
improvement on APOP for POP3 use as specified in RFC 1734.
|
||||
|
||||
1. Introduction
|
||||
|
||||
Existing Proposed Standards specify an AUTHENTICATE mechanism for the
|
||||
IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
|
||||
the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is
|
||||
intended to be extensible; the four methods specified in [IMAP-AUTH]
|
||||
are all fairly powerful and require some security infrastructure to
|
||||
support. The base POP3 specification [POP3] also contains a
|
||||
lightweight challenge-response mechanism called APOP. APOP is
|
||||
associated with most of the risks associated with such protocols: in
|
||||
particular, it requires that both the client and server machines have
|
||||
access to the shared secret in cleartext form. CRAM offers a method
|
||||
for avoiding such cleartext storage while retaining the algorithmic
|
||||
simplicity of APOP in using only MD5, though in a "keyed" method.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Klensin, Catoe & Krumviede Standards Track [Page 1]
|
||||
|
||||
RFC 2195 IMAP/POP AUTHorize Extension September 1997
|
||||
|
||||
|
||||
At present, IMAP [IMAP] lacks any facility corresponding to APOP.
|
||||
The only alternative to the strong mechanisms identified in [IMAP-
|
||||
AUTH] is a presumably cleartext username and password, supported
|
||||
through the LOGIN command in [IMAP]. This document describes a
|
||||
simple challenge-response mechanism, similar to APOP and PPP CHAP
|
||||
[PPP], that can be used with IMAP (and, in principle, with POP3).
|
||||
|
||||
This mechanism also has the advantage over some possible alternatives
|
||||
of not requiring that the server maintain information about email
|
||||
"logins" on a per-login basis. While mechanisms that do require such
|
||||
per-login history records may offer enhanced security, protocols such
|
||||
as IMAP, which may have several connections between a given client
|
||||
and server open more or less simultaneous, may make their
|
||||
implementation particularly challenging.
|
||||
|
||||
2. Challenge-Response Authentication Mechanism (CRAM)
|
||||
|
||||
The authentication type associated with CRAM is "CRAM-MD5".
|
||||
|
||||
The data encoded in the first ready response contains an
|
||||
presumptively arbitrary string of random digits, a timestamp, and the
|
||||
fully-qualified primary host name of the server. The syntax of the
|
||||
unencoded form must correspond to that of an RFC 822 'msg-id'
|
||||
[RFC822] as described in [POP3].
|
||||
|
||||
The client makes note of the data and then responds with a string
|
||||
consisting of the user name, a space, and a 'digest'. The latter is
|
||||
computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
|
||||
the key is a shared secret and the digested text is the timestamp
|
||||
(including angle-brackets).
|
||||
|
||||
This shared secret is a string known only to the client and server.
|
||||
The `digest' parameter itself is a 16-octet value which is sent in
|
||||
hexadecimal format, using lower-case ASCII characters.
|
||||
|
||||
When the server receives this client response, it verifies the digest
|
||||
provided. If the digest is correct, the server should consider the
|
||||
client authenticated and respond appropriately.
|
||||
|
||||
Keyed MD5 is chosen for this application because of the greater
|
||||
security imparted to authentication of short messages. In addition,
|
||||
the use of the techniques described in [KEYED-MD5] for precomputation
|
||||
of intermediate results make it possible to avoid explicit cleartext
|
||||
storage of the shared secret on the server system by instead storing
|
||||
the intermediate results which are known as "contexts".
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Klensin, Catoe & Krumviede Standards Track [Page 2]
|
||||
|
||||
RFC 2195 IMAP/POP AUTHorize Extension September 1997
|
||||
|
||||
|
||||
CRAM does not support a protection mechanism.
|
||||
|
||||
Example:
|
||||
|
||||
The examples in this document show the use of the CRAM mechanism with
|
||||
the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of
|
||||
the challenges and responses is part of the IMAP4 AUTHENTICATE
|
||||
command, not part of the CRAM specification itself.
|
||||
|
||||
S: * OK IMAP4 Server
|
||||
C: A0001 AUTHENTICATE CRAM-MD5
|
||||
S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
|
||||
C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
|
||||
S: A0001 OK CRAM authentication successful
|
||||
|
||||
In this example, the shared secret is the string
|
||||
'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced by
|
||||
calculating
|
||||
|
||||
MD5((tanstaaftanstaaf XOR opad),
|
||||
MD5((tanstaaftanstaaf XOR ipad),
|
||||
<1896.697170952@postoffice.reston.mci.net>))
|
||||
|
||||
where ipad and opad are as defined in the keyed-MD5 Work in
|
||||
Progress [KEYED-MD5] and the string shown in the challenge is the
|
||||
base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The
|
||||
shared secret is null-padded to a length of 64 bytes. If the
|
||||
shared secret is longer than 64 bytes, the MD5 digest of the
|
||||
shared secret is used as a 16 byte input to the keyed MD5
|
||||
calculation.
|
||||
|
||||
This produces a digest value (in hexadecimal) of
|
||||
|
||||
b913a602c7eda7a495b4e6e7334d3890
|
||||
|
||||
The user name is then prepended to it, forming
|
||||
|
||||
tim b913a602c7eda7a495b4e6e7334d3890
|
||||
|
||||
Which is then base64 encoded to meet the requirements of the IMAP4
|
||||
AUTHENTICATE command (or the similar POP3 AUTH command), yielding
|
||||
|
||||
dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Klensin, Catoe & Krumviede Standards Track [Page 3]
|
||||
|
||||
RFC 2195 IMAP/POP AUTHorize Extension September 1997
|
||||
|
||||
|
||||
3. References
|
||||
|
||||
[CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
|
||||
RFC 1334, October 1992.
|
||||
|
||||
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
|
||||
4rev1", RFC 2060, University of Washington, December 1996.
|
||||
|
||||
[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
|
||||
RFC 1731, Carnegie Mellon, December 1994.
|
||||
|
||||
[KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
|
||||
Message Authentication", RFC 2104, February 1997.
|
||||
|
||||
[MD5] Rivest, R., "The MD5 Message Digest Algorithm",
|
||||
RFC 1321, MIT Laboratory for Computer Science, April 1992.
|
||||
|
||||
[POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
|
||||
STD 53, RFC 1939, Carnegie Mellon, May 1996.
|
||||
|
||||
[POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
|
||||
Carnegie Mellon, December, 1994.
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
It is conjectured that use of the CRAM authentication mechanism
|
||||
provides origin identification and replay protection for a session.
|
||||
Accordingly, a server that implements both a cleartext password
|
||||
command and this authentication type should not allow both methods of
|
||||
access for a given user.
|
||||
|
||||
While the saving, on the server, of "contexts" (see section 2) is
|
||||
marginally better than saving the shared secrets in cleartext as is
|
||||
required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
|
||||
protect the secrets if the server itself is compromised.
|
||||
Consequently, servers that store the secrets or contexts must both be
|
||||
protected to a level appropriate to the potential information value
|
||||
in user mailboxes and identities.
|
||||
|
||||
As the length of the shared secret increases, so does the difficulty
|
||||
of deriving it.
|
||||
|
||||
While there are now suggestions in the literature that the use of MD5
|
||||
and keyed MD5 in authentication procedures probably has a limited
|
||||
effective lifetime, the technique is now widely deployed and widely
|
||||
understood. It is believed that this general understanding may
|
||||
assist with the rapid replacement, by CRAM-MD5, of the current uses
|
||||
of permanent cleartext passwords in IMAP. This document has been
|
||||
|
||||
|
||||
|
||||
Klensin, Catoe & Krumviede Standards Track [Page 4]
|
||||
|
||||
RFC 2195 IMAP/POP AUTHorize Extension September 1997
|
||||
|
||||
|
||||
deliberately written to permit easy upgrading to use SHA (or whatever
|
||||
alternatives emerge) when they are considered to be widely available
|
||||
and adequately safe.
|
||||
|
||||
Even with the use of CRAM, users are still vulnerable to active
|
||||
attacks. An example of an increasingly common active attack is 'TCP
|
||||
Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
|
||||
|
||||
See section 1 above for additional discussion.
|
||||
|
||||
5. Acknowledgements
|
||||
|
||||
This memo borrows ideas and some text liberally from [POP3] and
|
||||
[RFC-1731] and thanks are due the authors of those documents. Ran
|
||||
Atkinson made a number of valuable technical and editorial
|
||||
contributions to the document.
|
||||
|
||||
6. Authors' Addresses
|
||||
|
||||
John C. Klensin
|
||||
MCI Telecommunications
|
||||
800 Boylston St, 7th floor
|
||||
Boston, MA 02199
|
||||
USA
|
||||
|
||||
EMail: klensin@mci.net
|
||||
Phone: +1 617 960 1011
|
||||
|
||||
Randy Catoe
|
||||
MCI Telecommunications
|
||||
2100 Reston Parkway
|
||||
Reston, VA 22091
|
||||
USA
|
||||
|
||||
EMail: randy@mci.net
|
||||
Phone: +1 703 715 7366
|
||||
|
||||
Paul Krumviede
|
||||
MCI Telecommunications
|
||||
2100 Reston Parkway
|
||||
Reston, VA 22091
|
||||
USA
|
||||
|
||||
EMail: paul@mci.net
|
||||
Phone: +1 703 715 7251
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Klensin, Catoe & Krumviede Standards Track [Page 5]
|
||||
|
||||
283
docs/rfc/rfc2221.txt
Normal file
283
docs/rfc/rfc2221.txt
Normal file
@ -0,0 +1,283 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Gahrns
|
||||
Request for Comments: 2221 Microsoft
|
||||
Category: Standards Track October 1997
|
||||
|
||||
|
||||
IMAP4 Login Referrals
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (1997). All Rights Reserved.
|
||||
|
||||
1. Abstract
|
||||
|
||||
When dealing with large amounts of users and many IMAP4 [RFC-2060]
|
||||
servers, it is often necessary to move users from one IMAP4 server to
|
||||
another. For example, hardware failures or organizational changes
|
||||
may dictate such a move.
|
||||
|
||||
Login referrals allow clients to transparently connect to an
|
||||
alternate IMAP4 server, if their home IMAP4 server has changed.
|
||||
|
||||
A referral mechanism can provide efficiencies over the alternative
|
||||
'proxy method', in which the local IMAP4 server contacts the remote
|
||||
server on behalf of the client, and then transfers the data from the
|
||||
remote server to itself, and then on to the client. The referral
|
||||
mechanism's direct client connection to the remote server is often a
|
||||
more efficient use of bandwidth, and does not require the local
|
||||
server to impersonate the client when authenticating to the remote
|
||||
server.
|
||||
|
||||
2. Conventions used in this document
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server respectively.
|
||||
|
||||
A home server, is an IMAP4 server that contains the user's inbox.
|
||||
|
||||
A remote server is a server that contains remote mailboxes.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 1]
|
||||
|
||||
RFC 2221 IMAP4 Login Referrals October 1997
|
||||
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC-2119].
|
||||
|
||||
3. Introduction and Overview
|
||||
|
||||
IMAP4 servers that support this extension MUST list the keyword
|
||||
LOGIN-REFERRALS in their CAPABILITY response. No client action is
|
||||
needed to invoke the LOGIN-REFERRALS capability in a server.
|
||||
|
||||
A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral
|
||||
to a server that will return a referral. A client MUST NOT follow
|
||||
more than 10 levels of referral without consulting the user.
|
||||
|
||||
A LOGIN-REFERRALS response code MUST contain as an argument a valid
|
||||
IMAP server URL as defined in [IMAP-URL].
|
||||
|
||||
A home server referral consists of either a tagged NO or OK, or an
|
||||
untagged BYE response that contains a LOGIN-REFERRALS response code.
|
||||
|
||||
Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server
|
||||
|
||||
NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a
|
||||
client falling back to anonymous login.
|
||||
|
||||
4. Home Server Referrals
|
||||
|
||||
A home server referral may be returned in response to an AUTHENTICATE
|
||||
or LOGIN command, or it may appear in the connection startup banner.
|
||||
If a server returns a home server referral in a tagged NO response,
|
||||
that server does not contain any mailboxes that are accessible to the
|
||||
user. If a server returns a home server referral in a tagged OK
|
||||
response, it indicates that the user's personal mailboxes are
|
||||
elsewhere, but the server contains public mailboxes which are
|
||||
readable by the user. After receiving a home server referral, the
|
||||
client can not make any assumptions as to whether this was a
|
||||
permanent or temporary move of the user.
|
||||
|
||||
4.1. LOGIN and AUTHENTICATE Referrals
|
||||
|
||||
An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a
|
||||
home server referral if it wishes to direct the user to another IMAP4
|
||||
server.
|
||||
|
||||
Example: C: A001 LOGIN MIKE PASSWORD
|
||||
S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user
|
||||
is invalid on this server. Try SERVER2.
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 2]
|
||||
|
||||
RFC 2221 IMAP4 Login Referrals October 1997
|
||||
|
||||
|
||||
Example: C: A001 LOGIN MATTHEW PASSWORD
|
||||
S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified
|
||||
user's personal mailboxes located on Server2, but
|
||||
public mailboxes are available.
|
||||
|
||||
Example: C: A001 AUTHENTICATE GSSAPI
|
||||
<authentication exchange>
|
||||
S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/]
|
||||
Specified user is invalid on this server. Try
|
||||
SERVER2.
|
||||
|
||||
4.2. BYE at connection startup referral
|
||||
|
||||
An IMAP4 server MAY respond with an untagged BYE and a REFERRAL
|
||||
response code that contains an IMAP URL to a home server if it is not
|
||||
willing to accept connections and wishes to direct the client to
|
||||
another IMAP4 server.
|
||||
|
||||
Example: S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not
|
||||
accepting connections. Try SERVER2
|
||||
|
||||
5. Formal Syntax
|
||||
|
||||
The following syntax specification uses the augmented Backus-Naur
|
||||
Form (BNF) as described in [ABNF].
|
||||
|
||||
This amends the "resp_text_code" element of the IMAP4 grammar
|
||||
described in [RFC-2060]
|
||||
|
||||
resp_text_code =/ "REFERRAL" SPACE <imapurl>
|
||||
; See [IMAP-URL] for definition of <imapurl>
|
||||
; See [RFC-2060] for base definition of resp_text_code
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
The IMAP4 login referral mechanism makes use of IMAP URLs, and as
|
||||
such, have the same security considerations as general internet URLs
|
||||
[RFC-1738], and in particular IMAP URLs [IMAP-URL].
|
||||
|
||||
A server MUST NOT give a login referral if authentication for that
|
||||
user fails. This is to avoid revealing information about the user's
|
||||
account to an unauthorized user.
|
||||
|
||||
With the LOGIN-REFERRALS capability, it is potentially easier to
|
||||
write a rogue 'password catching' server that collects login data and
|
||||
then refers the client to their actual IMAP4 server. Although
|
||||
referrals reduce the effort to write such a server, the referral
|
||||
response makes detection of the intrusion easier.
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 3]
|
||||
|
||||
RFC 2221 IMAP4 Login Referrals October 1997
|
||||
|
||||
|
||||
7. References
|
||||
|
||||
[RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
|
||||
4rev1", RFC 2060, December 1996.
|
||||
|
||||
[IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
|
||||
September 1997.
|
||||
|
||||
[RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
|
||||
Resource Locators (URL)", RFC 1738, December 1994.
|
||||
|
||||
[RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", RFC 2119, March 1997.
|
||||
|
||||
[ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
|
||||
Syntax Specifications: ABNF", Work in Progress.
|
||||
|
||||
8. Acknowledgments
|
||||
|
||||
Many valuable suggestions were received from private discussions and
|
||||
the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin,
|
||||
Mark Keasling Chris Newman and Larry Osterman made significant
|
||||
contributions to this document.
|
||||
|
||||
9. Author's Address
|
||||
|
||||
Mike Gahrns
|
||||
Microsoft
|
||||
One Microsoft Way
|
||||
Redmond, WA, 98072
|
||||
|
||||
Phone: (206) 936-9833
|
||||
EMail: mikega@microsoft.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 4]
|
||||
|
||||
RFC 2221 IMAP4 Login Referrals October 1997
|
||||
|
||||
|
||||
10. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (1997). All Rights Reserved.
|
||||
|
||||
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 implmentation may be prepared, copied, published
|
||||
andand 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.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
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."
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns Standards Track [Page 5]
|
||||
|
||||
563
docs/rfc/rfc2342.txt
Normal file
563
docs/rfc/rfc2342.txt
Normal file
@ -0,0 +1,563 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Gahrns
|
||||
Request for Comments: 2342 Microsoft
|
||||
Category: Standards Track C. Newman
|
||||
Innosoft
|
||||
May 1998
|
||||
|
||||
|
||||
IMAP4 Namespace
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||
|
||||
1. Abstract
|
||||
|
||||
IMAP4 [RFC-2060] does not define a default server namespace. As a
|
||||
result, two common namespace models have evolved:
|
||||
|
||||
The "Personal Mailbox" model, in which the default namespace that is
|
||||
presented consists of only the user's personal mailboxes. To access
|
||||
shared mailboxes, the user must use an escape mechanism to reach
|
||||
another namespace.
|
||||
|
||||
The "Complete Hierarchy" model, in which the default namespace that
|
||||
is presented includes the user's personal mailboxes along with any
|
||||
other mailboxes they have access to.
|
||||
|
||||
These two models, create difficulties for certain client operations.
|
||||
This document defines a NAMESPACE command that allows a client to
|
||||
discover the prefixes of namespaces used by a server for personal
|
||||
mailboxes, other users' mailboxes, and shared mailboxes. This allows
|
||||
a client to avoid much of the manual user configuration that is now
|
||||
necessary when mixing and matching IMAP4 clients and servers.
|
||||
|
||||
2. Conventions used in this document
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server respectively. If such lines are wrapped without a new "C:" or
|
||||
"S:" label, then the wrapping is for editorial clarity and is not
|
||||
part of the command.
|
||||
|
||||
|
||||
|
||||
Gahrns & Newman Standards Track [Page 1]
|
||||
|
||||
RFC 2342 IMAP4 Namespace May 1998
|
||||
|
||||
|
||||
Personal Namespace: A namespace that the server considers within the
|
||||
personal scope of the authenticated user on a particular connection.
|
||||
Typically, only the authenticated user has access to mailboxes in
|
||||
their Personal Namespace. It is the part of the namespace that
|
||||
belongs to the user that is allocated for mailboxes. If an INBOX
|
||||
exists for a user, it MUST appear within the user's personal
|
||||
namespace. In the typical case, there SHOULD be only one Personal
|
||||
Namespace on a server.
|
||||
|
||||
Other Users' Namespace: A namespace that consists of mailboxes from
|
||||
the Personal Namespaces of other users. To access mailboxes in the
|
||||
Other Users' Namespace, the currently authenticated user MUST be
|
||||
explicitly granted access rights. For example, it is common for a
|
||||
manager to grant to their secretary access rights to their mailbox.
|
||||
In the typical case, there SHOULD be only one Other Users' Namespace
|
||||
on a server.
|
||||
|
||||
Shared Namespace: A namespace that consists of mailboxes that are
|
||||
intended to be shared amongst users and do not exist within a user's
|
||||
Personal Namespace.
|
||||
|
||||
The namespaces a server uses MAY differ on a per-user basis.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC-2119].
|
||||
|
||||
3. Introduction and Overview
|
||||
|
||||
Clients often attempt to create mailboxes for such purposes as
|
||||
maintaining a record of sent messages (e.g. "Sent Mail") or
|
||||
temporarily saving messages being composed (e.g. "Drafts"). For
|
||||
these clients to inter-operate correctly with the variety of IMAP4
|
||||
servers available, the user must enter the prefix of the Personal
|
||||
Namespace used by the server. Using the NAMESPACE command, a client
|
||||
is able to automatically discover this prefix without manual user
|
||||
configuration.
|
||||
|
||||
In addition, users are often required to manually enter the prefixes
|
||||
of various namespaces in order to view the mailboxes located there.
|
||||
For example, they might be required to enter the prefix of #shared to
|
||||
view the shared mailboxes namespace. The NAMESPACE command allows a
|
||||
client to automatically discover the namespaces that are available on
|
||||
a server. This allows a client to present the available namespaces to
|
||||
the user in what ever manner it deems appropriate. For example, a
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns & Newman Standards Track [Page 2]
|
||||
|
||||
RFC 2342 IMAP4 Namespace May 1998
|
||||
|
||||
|
||||
client could choose to initially display only personal mailboxes, or
|
||||
it may choose to display the complete list of mailboxes available,
|
||||
and initially position the user at the root of their Personal
|
||||
Namespace.
|
||||
|
||||
A server MAY choose to make available to the NAMESPACE command only a
|
||||
subset of the complete set of namespaces the server supports. To
|
||||
provide the ability to access these namespaces, a client SHOULD allow
|
||||
the user the ability to manually enter a namespace prefix.
|
||||
|
||||
4. Requirements
|
||||
|
||||
IMAP4 servers that support this extension MUST list the keyword
|
||||
NAMESPACE in their CAPABILITY response.
|
||||
|
||||
The NAMESPACE command is valid in the Authenticated and Selected
|
||||
state.
|
||||
|
||||
5. NAMESPACE Command
|
||||
|
||||
Arguments: none
|
||||
|
||||
Response: an untagged NAMESPACE response that contains the prefix
|
||||
and hierarchy delimiter to the server's Personal
|
||||
Namespace(s), Other Users' Namespace(s), and Shared
|
||||
Namespace(s) that the server wishes to expose. The
|
||||
response will contain a NIL for any namespace class
|
||||
that is not available. Namespace_Response_Extensions
|
||||
MAY be included in the response.
|
||||
Namespace_Response_Extensions which are not on the IETF
|
||||
standards track, MUST be prefixed with an "X-".
|
||||
|
||||
Result: OK - Command completed
|
||||
NO - Error: Can't complete command
|
||||
BAD - argument invalid
|
||||
|
||||
Example 5.1:
|
||||
===========
|
||||
|
||||
< A server that supports a single personal namespace. No leading
|
||||
prefix is used on personal mailboxes and "/" is the hierarchy
|
||||
delimiter.>
|
||||
|
||||
C: A001 NAMESPACE
|
||||
S: * NAMESPACE (("" "/")) NIL NIL
|
||||
S: A001 OK NAMESPACE command completed
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns & Newman Standards Track [Page 3]
|
||||
|
||||
RFC 2342 IMAP4 Namespace May 1998
|
||||
|
||||
|
||||
Example 5.2:
|
||||
===========
|
||||
|
||||
< A user logged on anonymously to a server. No personal mailboxes
|
||||
are associated with the anonymous user and the user does not have
|
||||
access to the Other Users' Namespace. No prefix is required to
|
||||
access shared mailboxes and the hierarchy delimiter is "." >
|
||||
|
||||
C: A001 NAMESPACE
|
||||
S: * NAMESPACE NIL NIL (("" "."))
|
||||
S: A001 OK NAMESPACE command completed
|
||||
|
||||
Example 5.3:
|
||||
===========
|
||||
|
||||
< A server that contains a Personal Namespace and a single Shared
|
||||
Namespace. >
|
||||
|
||||
C: A001 NAMESPACE
|
||||
S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
|
||||
S: A001 OK NAMESPACE command completed
|
||||
|
||||
Example 5.4:
|
||||
===========
|
||||
|
||||
< A server that contains a Personal Namespace, Other Users'
|
||||
Namespace and multiple Shared Namespaces. Note that the hierarchy
|
||||
delimiter used within each namespace can be different. >
|
||||
|
||||
C: A001 NAMESPACE
|
||||
S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
|
||||
("#public/" "/")("#ftp/" "/")("#news." "."))
|
||||
S: A001 OK NAMESPACE command completed
|
||||
|
||||
The prefix string allows a client to do things such as automatically
|
||||
creating personal mailboxes or LISTing all available mailboxes within
|
||||
a namespace.
|
||||
|
||||
Example 5.5:
|
||||
===========
|
||||
|
||||
< A server that supports only the Personal Namespace, with a
|
||||
leading prefix of INBOX to personal mailboxes and a hierarchy
|
||||
delimiter of ".">
|
||||
|
||||
C: A001 NAMESPACE
|
||||
S: * NAMESPACE (("INBOX." ".")) NIL NIL
|
||||
S: A001 OK NAMESPACE command completed
|
||||
|
||||
|
||||
|
||||
Gahrns & Newman Standards Track [Page 4]
|
||||
|
||||
RFC 2342 IMAP4 Namespace May 1998
|
||||
|
||||
|
||||
< Automatically create a mailbox to store sent items.>
|
||||
|
||||
C: A002 CREATE "INBOX.Sent Mail"
|
||||
S: A002 OK CREATE command completed
|
||||
|
||||
Although typically a server will support only a single Personal
|
||||
Namespace, and a single Other User's Namespace, circumstances exist
|
||||
where there MAY be multiples of these, and a client MUST be prepared
|
||||
for them. If a client is configured such that it is required to
|
||||
create a certain mailbox, there can be circumstances where it is
|
||||
unclear which Personal Namespaces it should create the mailbox in.
|
||||
In these situations a client SHOULD let the user select which
|
||||
namespaces to create the mailbox in.
|
||||
|
||||
Example 5.6:
|
||||
===========
|
||||
|
||||
< In this example, a server supports 2 Personal Namespaces. In
|
||||
addition to the regular Personal Namespace, the user has an
|
||||
additional personal namespace to allow access to mailboxes in an
|
||||
MH format mailstore. >
|
||||
|
||||
< The client is configured to save a copy of all mail sent by the
|
||||
user into a mailbox called 'Sent Mail'. Furthermore, after a
|
||||
message is deleted from a mailbox, the client is configured to
|
||||
move that message to a mailbox called 'Deleted Items'.>
|
||||
|
||||
< Note that this example demonstrates how some extension flags can
|
||||
be passed to further describe the #mh namespace. >
|
||||
|
||||
C: A001 NAMESPACE
|
||||
S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM" ("FLAG1" "FLAG2")))
|
||||
NIL NIL
|
||||
S: A001 OK NAMESPACE command completed
|
||||
|
||||
< It is desired to keep only one copy of sent mail. It is unclear
|
||||
which Personal Namespace the client should use to create the 'Sent
|
||||
Mail' mailbox. The user is prompted to select a namespace and
|
||||
only one 'Sent Mail' mailbox is created. >
|
||||
|
||||
C: A002 CREATE "Sent Mail"
|
||||
S: A002 OK CREATE command completed
|
||||
|
||||
< The client is designed so that it keeps two 'Deleted Items'
|
||||
mailboxes, one for each namespace. >
|
||||
|
||||
C: A003 CREATE "Delete Items"
|
||||
S: A003 OK CREATE command completed
|
||||
|
||||
|
||||
|
||||
Gahrns & Newman Standards Track [Page 5]
|
||||
|
||||
RFC 2342 IMAP4 Namespace May 1998
|
||||
|
||||
|
||||
C: A004 CREATE "#mh/Deleted Items"
|
||||
S: A004 OK CREATE command completed
|
||||
|
||||
The next level of hierarchy following the Other Users' Namespace
|
||||
prefix SHOULD consist of <username>, where <username> is a user name
|
||||
as per the IMAP4 LOGIN or AUTHENTICATE command.
|
||||
|
||||
A client can construct a LIST command by appending a "%" to the Other
|
||||
Users' Namespace prefix to discover the Personal Namespaces of other
|
||||
users that are available to the currently authenticated user.
|
||||
|
||||
In response to such a LIST command, a server SHOULD NOT return user
|
||||
names that have not granted access to their personal mailboxes to the
|
||||
user in question.
|
||||
|
||||
A server MAY return a LIST response containing only the names of
|
||||
users that have explicitly granted access to the user in question.
|
||||
|
||||
Alternatively, a server MAY return NO to such a LIST command,
|
||||
requiring that a user name be included with the Other Users'
|
||||
Namespace prefix before listing any other user's mailboxes.
|
||||
|
||||
Example 5.7:
|
||||
===========
|
||||
|
||||
< A server that supports providing a list of other user's
|
||||
mailboxes that are accessible to the currently logged on user. >
|
||||
|
||||
C: A001 NAMESPACE
|
||||
S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
|
||||
S: A001 OK NAMESPACE command completed
|
||||
|
||||
C: A002 LIST "" "Other Users/%"
|
||||
S: * LIST () "/" "Other Users/Mike"
|
||||
S: * LIST () "/" "Other Users/Karen"
|
||||
S: * LIST () "/" "Other Users/Matthew"
|
||||
S: * LIST () "/" "Other Users/Tesa"
|
||||
S: A002 OK LIST command completed
|
||||
|
||||
Example 5.8:
|
||||
===========
|
||||
|
||||
< A server that does not support providing a list of other user's
|
||||
mailboxes that are accessible to the currently logged on user.
|
||||
The mailboxes are listable if the client includes the name of the
|
||||
other user with the Other Users' Namespace prefix. >
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns & Newman Standards Track [Page 6]
|
||||
|
||||
RFC 2342 IMAP4 Namespace May 1998
|
||||
|
||||
|
||||
C: A001 NAMESPACE
|
||||
S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
|
||||
S: A001 OK NAMESPACE command completed
|
||||
|
||||
< In this example, the currently logged on user has access to the
|
||||
Personal Namespace of user Mike, but the server chose to suppress
|
||||
this information in the LIST response. However, by appending the
|
||||
user name Mike (received through user input) to the Other Users'
|
||||
Namespace prefix, the client is able to get a listing of the
|
||||
personal mailboxes of user Mike. >
|
||||
|
||||
C: A002 LIST "" "#Users/%"
|
||||
S: A002 NO The requested item could not be found.
|
||||
|
||||
C: A003 LIST "" "#Users/Mike/%"
|
||||
S: * LIST () "/" "#Users/Mike/INBOX"
|
||||
S: * LIST () "/" "#Users/Mike/Foo"
|
||||
S: A003 OK LIST command completed.
|
||||
|
||||
A prefix string might not contain a hierarchy delimiter, because
|
||||
in some cases it is not needed as part of the prefix.
|
||||
|
||||
Example 5.9:
|
||||
===========
|
||||
|
||||
< A server that allows access to the Other Users' Namespace by
|
||||
prefixing the others' mailboxes with a '~' followed by <username>,
|
||||
where <username> is a user name as per the IMAP4 LOGIN or
|
||||
AUTHENTICATE command.>
|
||||
|
||||
C: A001 NAMESPACE
|
||||
S: * NAMESPACE (("" "/")) (("~" "/")) NIL
|
||||
S: A001 OK NAMESPACE command completed
|
||||
|
||||
< List the mailboxes for user mark >
|
||||
|
||||
C: A002 LIST "" "~mark/%"
|
||||
S: * LIST () "/" "~mark/INBOX"
|
||||
S: * LIST () "/" "~mark/foo"
|
||||
S: A002 OK LIST command completed
|
||||
|
||||
Historical convention has been to start all namespaces with the "#"
|
||||
character. Namespaces that include the "#" character are not IMAP
|
||||
URL [IMAP-URL] friendly requiring the "#" character to be represented
|
||||
as %23 when within URLs. As such, server implementers MAY instead
|
||||
consider using namespace prefixes that do not contain the "#"
|
||||
character.
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns & Newman Standards Track [Page 7]
|
||||
|
||||
RFC 2342 IMAP4 Namespace May 1998
|
||||
|
||||
|
||||
6. Formal Syntax
|
||||
|
||||
The following syntax specification uses the augmented Backus-Naur
|
||||
Form (BNF) as described in [ABNF].
|
||||
|
||||
atom = <atom>
|
||||
; <atom> as defined in [RFC-2060]
|
||||
|
||||
Namespace = nil / "(" 1*( "(" string SP (<"> QUOTED_CHAR <"> /
|
||||
nil) *(Namespace_Response_Extension) ")" ) ")"
|
||||
|
||||
Namespace_Command = "NAMESPACE"
|
||||
|
||||
Namespace_Response_Extension = SP string SP "(" string *(SP string)
|
||||
")"
|
||||
|
||||
Namespace_Response = "*" SP "NAMESPACE" SP Namespace SP Namespace SP
|
||||
Namespace
|
||||
|
||||
; The first Namespace is the Personal Namespace(s)
|
||||
; The second Namespace is the Other Users' Namespace(s)
|
||||
; The third Namespace is the Shared Namespace(s)
|
||||
|
||||
nil = <nil>
|
||||
; <nil> as defined in [RFC-2060]
|
||||
|
||||
QUOTED_CHAR = <QUOTED_CHAR>
|
||||
; <QUOTED_CHAR> as defined in [RFC-2060]
|
||||
|
||||
string = <string>
|
||||
; <string> as defined in [RFC-2060]
|
||||
; Note that the namespace prefix is to a mailbox and following
|
||||
; IMAP4 convention, any international string in the NAMESPACE
|
||||
; response MUST be of modified UTF-7 format as described in
|
||||
; [RFC-2060].
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
In response to a LIST command containing an argument of the Other
|
||||
Users' Namespace prefix, a server SHOULD NOT list users that have not
|
||||
granted list access to their personal mailboxes to the currently
|
||||
authenticated user. Providing such a list, could compromise security
|
||||
by potentially disclosing confidential information of who is located
|
||||
on the server, or providing a starting point of a list of user
|
||||
accounts to attack.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns & Newman Standards Track [Page 8]
|
||||
|
||||
RFC 2342 IMAP4 Namespace May 1998
|
||||
|
||||
|
||||
8. References
|
||||
|
||||
[RFC-2060], Crispin, M., "Internet Message Access Protocol Version
|
||||
4rev1", RFC 2060, December 1996.
|
||||
|
||||
[RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 2234, November 1997.
|
||||
|
||||
[IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
|
||||
|
||||
9. Acknowledgments
|
||||
|
||||
Many people have participated in the discussion of IMAP namespaces on
|
||||
the IMAP mailing list. In particular, the authors would like to
|
||||
thank Mark Crispin for many of the concepts relating to the Personal
|
||||
Namespace and accessing the Personal Namespace of other users, Steve
|
||||
Hole for summarizing the two namespace models, John Myers and Jack De
|
||||
Winter for their work in a preceding effort trying to define a
|
||||
standardized personal namespace, and Larry Osterman for his review
|
||||
and collaboration on this document.
|
||||
|
||||
11. Authors' Addresses
|
||||
|
||||
Mike Gahrns
|
||||
Microsoft
|
||||
One Microsoft Way
|
||||
Redmond, WA, 98072, USA
|
||||
|
||||
Phone: (425) 936-9833
|
||||
EMail: mikega@microsoft.com
|
||||
|
||||
|
||||
Chris Newman
|
||||
Innosoft International, Inc.
|
||||
1050 East Garvey Ave. South
|
||||
West Covina, CA, 91790, USA
|
||||
|
||||
EMail: chris.newman@innosoft.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns & Newman Standards Track [Page 9]
|
||||
|
||||
RFC 2342 IMAP4 Namespace May 1998
|
||||
|
||||
|
||||
12. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||
|
||||
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.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns & Newman Standards Track [Page 10]
|
||||
|
||||
1291
docs/rfc/rfc2683.txt
Normal file
1291
docs/rfc/rfc2683.txt
Normal file
File diff suppressed because it is too large
Load Diff
451
docs/rfc/rfc2971.txt
Normal file
451
docs/rfc/rfc2971.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group T. Showalter
|
||||
Request for Comments: 2971 Mirapoint, Inc.
|
||||
Category: Standards Track October 2000
|
||||
|
||||
|
||||
IMAP4 ID extension
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
The ID extension to the Internet Message Access Protocol - Version
|
||||
4rev1 (IMAP4rev1) protocol allows the server and client to exchange
|
||||
identification information on their implementation in order to make
|
||||
bug reports and usage statistics more complete.
|
||||
|
||||
1. Introduction
|
||||
|
||||
The IMAP4rev1 protocol described in [IMAP4rev1] provides a method for
|
||||
accessing remote mail stores, but it provides no facility to
|
||||
advertise what program a client or server uses to provide service.
|
||||
This makes it difficult for implementors to get complete bug reports
|
||||
from users, as it is frequently difficult to know what client or
|
||||
server is in use.
|
||||
|
||||
Additionally, some sites may wish to assemble usage statistics based
|
||||
on what clients are used, but in an an environment where users are
|
||||
permitted to obtain and maintain their own clients this is difficult
|
||||
to accomplish.
|
||||
|
||||
The ID command provides a facility to advertise information on what
|
||||
programs are being used along with contact information (should bugs
|
||||
ever occur).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Showalter Standards Track [Page 1]
|
||||
|
||||
RFC 2971 IMAP4 ID extension October 2000
|
||||
|
||||
|
||||
2. Conventions Used in this Document
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [KEYWORDS].
|
||||
|
||||
The conventions used in this document are the same as specified in
|
||||
[IMAP4rev1]. In examples, "C:" and "S:" indicate lines sent by the
|
||||
client and server respectively. Line breaks have been inserted for
|
||||
readability.
|
||||
|
||||
3. Specification
|
||||
|
||||
The sole purpose of the ID extension is to enable clients and servers
|
||||
to exchange information on their implementations for the purposes of
|
||||
statistical analysis and problem determination.
|
||||
|
||||
This information is be submitted to a server by any client wishing to
|
||||
provide information for statistical purposes, provided the server
|
||||
advertises its willingness to take the information with the atom "ID"
|
||||
included in the list of capabilities returned by the CAPABILITY
|
||||
command.
|
||||
|
||||
Implementations MUST NOT make operational changes based on the data
|
||||
sent as part of the ID command or response. The ID command is for
|
||||
human consumption only, and is not to be used in improving the
|
||||
performance of clients or servers.
|
||||
|
||||
This includes, but is not limited to, the following:
|
||||
|
||||
Servers MUST NOT attempt to work around client bugs by using
|
||||
information from the ID command. Clients MUST NOT attempt to work
|
||||
around server bugs based on the ID response.
|
||||
|
||||
Servers MUST NOT provide features to a client or otherwise
|
||||
optimize for a particular client by using information from the ID
|
||||
command. Clients MUST NOT provide features to a server or
|
||||
otherwise optimize for a particular server based on the ID
|
||||
response.
|
||||
|
||||
Servers MUST NOT deny access to or refuse service for a client
|
||||
based on information from the ID command. Clients MUST NOT refuse
|
||||
to operate or limit their operation with a server based on the ID
|
||||
response.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Showalter Standards Track [Page 2]
|
||||
|
||||
RFC 2971 IMAP4 ID extension October 2000
|
||||
|
||||
|
||||
Rationale: It is imperative that this extension not supplant IMAP's
|
||||
CAPABILITY mechanism with a ad-hoc approach where implementations
|
||||
guess each other's features based on who they claim to be.
|
||||
|
||||
Implementations MUST NOT send false information in an ID command.
|
||||
|
||||
Implementations MAY send less information than they have available or
|
||||
no information at all. Such behavior may be useful to preserve user
|
||||
privacy. See Security Considerations, section 7.
|
||||
|
||||
3.1. ID Command
|
||||
|
||||
Arguments: client parameter list or NIL
|
||||
|
||||
Responses: OPTIONAL untagged response: ID
|
||||
|
||||
Result: OK identification information accepted
|
||||
BAD command unknown or arguments invalid
|
||||
|
||||
Implementation identification information is sent by the client with
|
||||
the ID command.
|
||||
|
||||
This command is valid in any state.
|
||||
|
||||
The information sent is in the form of a list of field/value pairs.
|
||||
Fields are permitted to be any IMAP4 string, and values are permitted
|
||||
to be any IMAP4 string or NIL. A value of NIL indicates that the
|
||||
client can not or will not specify this information. The client may
|
||||
also send NIL instead of the list, indicating that it wants to send
|
||||
no information, but would still accept a server response.
|
||||
|
||||
The available fields are defined in section 3.3.
|
||||
|
||||
Example: C: a023 ID ("name" "sodr" "version" "19.34" "vendor"
|
||||
"Pink Floyd Music Limited")
|
||||
S: * ID NIL
|
||||
S: a023 OK ID completed
|
||||
|
||||
3.2. ID Response
|
||||
|
||||
Contents: server parameter list
|
||||
|
||||
In response to an ID command issued by the client, the server replies
|
||||
with a tagged response containing information on its implementation.
|
||||
The format is the same as the client list.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Showalter Standards Track [Page 3]
|
||||
|
||||
RFC 2971 IMAP4 ID extension October 2000
|
||||
|
||||
|
||||
Example: C: a042 ID NIL
|
||||
S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos"
|
||||
"os-version" "5.5" "support-url"
|
||||
"mailto:cyrus-bugs+@andrew.cmu.edu")
|
||||
S: a042 OK ID command completed
|
||||
|
||||
A server MUST send a tagged ID response to an ID command. However, a
|
||||
server MAY send NIL in place of the list.
|
||||
|
||||
3.3. Defined Field Values
|
||||
|
||||
Any string may be sent as a field, but the following are defined to
|
||||
describe certain values that might be sent. Implementations are free
|
||||
to send none, any, or all of these. Strings are not case-sensitive.
|
||||
Field strings MUST NOT be longer than 30 octets. Value strings MUST
|
||||
NOT be longer than 1024 octets. Implementations MUST NOT send more
|
||||
than 30 field-value pairs.
|
||||
|
||||
name Name of the program
|
||||
version Version number of the program
|
||||
os Name of the operating system
|
||||
os-version Version of the operating system
|
||||
vendor Vendor of the client/server
|
||||
support-url URL to contact for support
|
||||
address Postal address of contact/vendor
|
||||
date Date program was released, specified as a date-time
|
||||
in IMAP4rev1
|
||||
command Command used to start the program
|
||||
arguments Arguments supplied on the command line, if any
|
||||
if any
|
||||
environment Description of environment, i.e., UNIX environment
|
||||
variables or Windows registry settings
|
||||
|
||||
Implementations MUST NOT use contact information to submit automatic
|
||||
bug reports. Implementations may include information from an ID
|
||||
response in a report automatically prepared, but are prohibited from
|
||||
sending the report without user authorization.
|
||||
|
||||
It is preferable to find the name and version of the underlying
|
||||
operating system at runtime in cases where this is possible.
|
||||
|
||||
Information sent via an ID response may violate user privacy. See
|
||||
Security Considerations, section 7.
|
||||
|
||||
Implementations MUST NOT send the same field name more than once.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Showalter Standards Track [Page 4]
|
||||
|
||||
RFC 2971 IMAP4 ID extension October 2000
|
||||
|
||||
|
||||
4. Formal Syntax
|
||||
|
||||
This syntax is intended to augment the grammar specified in
|
||||
[IMAP4rev1] in order to provide for the ID command. This
|
||||
specification uses the augmented Backus-Naur Form (BNF) notation as
|
||||
used in [IMAP4rev1].
|
||||
|
||||
command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id
|
||||
;; adds id command to command_any in [IMAP4rev1]
|
||||
|
||||
id ::= "ID" SPACE id_params_list
|
||||
|
||||
id_response ::= "ID" SPACE id_params_list
|
||||
|
||||
id_params_list ::= "(" #(string SPACE nstring) ")" / nil
|
||||
;; list of field value pairs
|
||||
|
||||
response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
|
||||
mailbox_data / message_data / capability_data / id_response)
|
||||
|
||||
5. Use of the ID extension with Firewalls and Other Intermediaries
|
||||
|
||||
There exist proxies, firewalls, and other intermediary systems that
|
||||
can intercept an IMAP session and make changes to the data exchanged
|
||||
in the session. Such intermediaries are not anticipated by the IMAP4
|
||||
protocol design and are not within the scope of the IMAP4 standard.
|
||||
However, in order for the ID command to be useful in the presence of
|
||||
such intermediaries, those intermediaries need to take special note
|
||||
of the ID command and response. In particular, if an intermediary
|
||||
changes any part of the IMAP session it must also change the ID
|
||||
command to advertise its presence.
|
||||
|
||||
A firewall MAY act to block transmission of specific information
|
||||
fields in the ID command and response that it believes reveal
|
||||
information that could expose a security vulnerability. However, a
|
||||
firewall SHOULD NOT disable the extension, when present, entirely,
|
||||
and SHOULD NOT unconditionally remove either the client or server
|
||||
list.
|
||||
|
||||
Finally, it should be noted that a firewall, when handling a
|
||||
CAPABILITY response, MUST NOT allow the names of extensions to be
|
||||
returned to the client that the firewall has no knowledge of.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Showalter Standards Track [Page 5]
|
||||
|
||||
RFC 2971 IMAP4 ID extension October 2000
|
||||
|
||||
|
||||
6. References
|
||||
|
||||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", RFC 2119, March 1997.
|
||||
|
||||
[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
|
||||
4rev1", RFC 2060, October 1996.
|
||||
|
||||
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
|
||||
Text Messages", STD 11, RFC 822, August 1982.
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
This extension has the danger of violating the privacy of users if
|
||||
misused. Clients and servers should notify users that they implement
|
||||
and enable the ID command.
|
||||
|
||||
It is highly desirable that implementations provide a method of
|
||||
disabling ID support, perhaps by not sending ID at all, or by sending
|
||||
NIL as the argument to the ID command or response.
|
||||
|
||||
Implementors must exercise extreme care in adding fields sent as part
|
||||
of an ID command or response. Some fields, including a processor ID
|
||||
number, Ethernet address, or other unique (or mostly unique)
|
||||
identifier allow tracking of users in ways that violate user privacy
|
||||
expectations.
|
||||
|
||||
Having implementation information of a given client or server may
|
||||
make it easier for an attacker to gain unauthorized access due to
|
||||
security holes.
|
||||
|
||||
Since this command includes arbitrary data and does not require the
|
||||
user to authenticate, server implementations are cautioned to guard
|
||||
against an attacker sending arbitrary garbage data in order to fill
|
||||
up the ID log. In particular, if a server naively logs each ID
|
||||
command to disk without inspecting it, an attacker can simply fire up
|
||||
thousands of connections and send a few kilobytes of random data.
|
||||
Servers have to guard against this. Methods include truncating
|
||||
abnormally large responses; collating responses by storing only a
|
||||
single copy, then keeping a counter of the number of times that
|
||||
response has been seen; keeping only particularly interesting parts
|
||||
of responses; and only logging responses of users who actually log
|
||||
in.
|
||||
|
||||
Security is affected by firewalls which modify the IMAP protocol
|
||||
stream; see section 5, Use of the ID Extension with Firewalls and
|
||||
Other Intermediaries, for more information.
|
||||
|
||||
|
||||
|
||||
|
||||
Showalter Standards Track [Page 6]
|
||||
|
||||
RFC 2971 IMAP4 ID extension October 2000
|
||||
|
||||
|
||||
8. Author's Address
|
||||
|
||||
Tim Showalter
|
||||
Mirapoint, Inc.
|
||||
909 Hermosa Ct.
|
||||
Sunnyvale, CA 94095
|
||||
|
||||
EMail: tjs@mirapoint.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Showalter Standards Track [Page 7]
|
||||
|
||||
RFC 2971 IMAP4 ID extension October 2000
|
||||
|
||||
|
||||
9. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
||||
|
||||
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.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
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.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Showalter Standards Track [Page 8]
|
||||
|
||||
339
docs/rfc/rfc3348.txt
Normal file
339
docs/rfc/rfc3348.txt
Normal file
@ -0,0 +1,339 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Gahrns
|
||||
Request for Comments: 3348 R. Cheng
|
||||
Category: Informational Microsoft
|
||||
July 2002
|
||||
|
||||
|
||||
The Internet Message Action Protocol (IMAP4)
|
||||
Child Mailbox Extension
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This memo provides information for the Internet community. It does
|
||||
not specify an Internet standard of any kind. Distribution of this
|
||||
memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
The Internet Message Action Protocol (IMAP4) CHILDREN extension
|
||||
provides a mechanism for a client to efficiently determine if a
|
||||
particular mailbox has children, without issuing a LIST "" * or a
|
||||
LIST "" % for each mailbox.
|
||||
|
||||
1. Conventions used in this document
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server respectively. If such lines are wrapped without a new "C:" or
|
||||
"S:" label, then the wrapping is for editorial clarity and is not
|
||||
part of the command.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC-2119].
|
||||
|
||||
2. Introduction and Overview
|
||||
|
||||
Many IMAP4 [RFC-2060] clients present to the user a hierarchical view
|
||||
of the mailboxes that a user has access to. Rather than initially
|
||||
presenting to the user the entire mailbox hierarchy, it is often
|
||||
preferable to show to the user a collapsed outline list of the
|
||||
mailbox hierarchy (particularly if there is a large number of
|
||||
mailboxes). The user can then expand the collapsed outline hierarchy
|
||||
as needed. It is common to include within the collapsed hierarchy a
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns, et al. Informational [Page 1]
|
||||
|
||||
RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
||||
|
||||
|
||||
visual clue (such as a "+") to indicate that there are child
|
||||
mailboxes under a particular mailbox. When the visual clue is
|
||||
clicked the hierarchy list is expanded to show the child mailboxes.
|
||||
|
||||
Several IMAP vendors implemented this proposal, and it is proposed to
|
||||
document this behavior and functionality as an Informational RFC.
|
||||
|
||||
There is interest in addressing the general extensibility of the IMAP
|
||||
LIST command through an IMAP LIST Extension draft. Similar
|
||||
functionality to the \HasChildren and \HasNoChildren flags could be
|
||||
incorporated into this new LIST Extension. It is proposed that the
|
||||
more general LIST Extension draft proceed on the standards track with
|
||||
this proposal being relegated to informational status only.
|
||||
|
||||
If the functionality of the \HasChildren and \HasNoChildren flags
|
||||
were incorporated into a more general LIST extension, this would have
|
||||
the advantage that a client could then have the opportunity to
|
||||
request whether or not the server should return this information.
|
||||
This would be an advantage over the current draft for servers where
|
||||
this information is expensive to compute, since the server would only
|
||||
need to compute the information when it knew that the client
|
||||
requesting the information was able to consume it.
|
||||
|
||||
3. Requirements
|
||||
|
||||
IMAP4 servers that support this extension MUST list the keyword
|
||||
CHILDREN in their CAPABILITY response.
|
||||
|
||||
The CHILDREN extension defines two new attributes that MAY be
|
||||
returned within a LIST response.
|
||||
|
||||
\HasChildren - The presence of this attribute indicates that the
|
||||
mailbox has child mailboxes.
|
||||
|
||||
Servers SHOULD NOT return \HasChildren if child mailboxes exist, but
|
||||
none will be displayed to the current user in a LIST response (as
|
||||
should be the case where child mailboxes exist, but a client does not
|
||||
have permissions to access them.) In this case, \HasNoChildren
|
||||
SHOULD be used.
|
||||
|
||||
In many cases, however, a server may not be able to efficiently
|
||||
compute whether a user has access to all child mailboxes, or multiple
|
||||
users may be accessing the same account and simultaneously changing
|
||||
the mailbox hierarchy. As such a client MUST be prepared to accept
|
||||
the \HasChildren attribute as a hint. That is, a mailbox MAY be
|
||||
flagged with the \HasChildren attribute, but no child mailboxes will
|
||||
appear in a subsequent LIST response.
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns, et al. Informational [Page 2]
|
||||
|
||||
RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
||||
|
||||
|
||||
Example 3.1:
|
||||
============
|
||||
|
||||
/*** Consider a server that has the following mailbox hierarchy:
|
||||
|
||||
INBOX
|
||||
ITEM_1
|
||||
ITEM_1A
|
||||
ITEM_2
|
||||
TOP_SECRET
|
||||
|
||||
Where INBOX, ITEM_1 and ITEM_2 are top level mailboxes. ITEM_1A is a
|
||||
child mailbox of ITEM_1 and TOP_SECRET is a child mailbox of ITEM_2
|
||||
that the currently logged on user does NOT have access to.
|
||||
|
||||
Note that in this case, the server is not able to efficiently compute
|
||||
access rights to child mailboxes and responds with a \HasChildren
|
||||
attribute for mailbox ITEM_2, even though ITEM_2/TOP_SECRET does not
|
||||
appear in the list response. ***/
|
||||
|
||||
C: A001 LIST "" *
|
||||
S: * LIST (\HasNoChildren) "/" INBOX
|
||||
S: * LIST (\HasChildren) "/" ITEM_1
|
||||
S: * LIST (\HasNoChildren) "/" ITEM_1/ITEM_1A
|
||||
S: * LIST (\HasChildren) "/" ITEM_2
|
||||
S: A001 OK LIST Completed
|
||||
|
||||
\HasNoChildren - The presence of this attribute indicates that the
|
||||
mailbox has NO child mailboxes that are accessible to the currently
|
||||
authenticated user. If a mailbox has the \Noinferiors attribute, the
|
||||
\HasNoChildren attribute is redundant and SHOULD be omitted in the
|
||||
LIST response.
|
||||
|
||||
In some instances a server that supports the CHILDREN extension MAY
|
||||
NOT be able to determine whether a mailbox has children. For example
|
||||
it may have difficulty determining whether there are child mailboxes
|
||||
when LISTing mailboxes while operating in a particular namespace.
|
||||
|
||||
In these cases, a server MAY exclude both the \HasChildren and
|
||||
\HasNoChildren attributes in the LIST response. As such, a client
|
||||
can not make any assumptions about whether a mailbox has children
|
||||
based upon the absence of a single attribute.
|
||||
|
||||
It is an error for the server to return both a \HasChildren and a
|
||||
\HasNoChildren attribute in a LIST response.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns, et al. Informational [Page 3]
|
||||
|
||||
RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
||||
|
||||
|
||||
It is an error for the server to return both a \HasChildren and a
|
||||
\NoInferiors attribute in a LIST response.
|
||||
|
||||
Note: the \HasNoChildren attribute should not be confused with the
|
||||
IMAP4 [RFC-2060] defined attribute \Noinferiors which indicates that
|
||||
no child mailboxes exist now and none can be created in the future.
|
||||
|
||||
The \HasChildren and \HasNoChildren attributes might not be returned
|
||||
in response to a LSUB response. Many servers maintain a simple
|
||||
mailbox subscription list that is not updated when the underlying
|
||||
mailbox structure is changed. A client MUST NOT assume that
|
||||
hierarchy information will be maintained in the subscription list.
|
||||
|
||||
RLIST is a command defined in [RFC-2193] that includes in a LIST
|
||||
response mailboxes that are accessible only via referral. That is, a
|
||||
client must explicitly issue an RLIST command to see a list of these
|
||||
mailboxes. Thus in the case where a mailbox has child mailboxes that
|
||||
are available only via referral, the mailboxes would appear as
|
||||
\HasNoChildren in response to the LIST command, and \HasChildren in
|
||||
response to the RLIST command.
|
||||
|
||||
5. Formal Syntax
|
||||
|
||||
The following syntax specification uses the augmented Backus-Naur
|
||||
Form (BNF) as described in [ABNF].
|
||||
|
||||
Two new mailbox attributes are defined as flag_extensions to the
|
||||
IMAP4 mailbox_list response:
|
||||
|
||||
HasChildren = "\HasChildren"
|
||||
|
||||
HasNoChildren = "\HasNoChildren"
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
This extension provides a client a more efficient means of
|
||||
determining whether a particular mailbox has children. If a mailbox
|
||||
has children, but the currently authenticated user does not have
|
||||
access to any of them, the server SHOULD respond with a
|
||||
\HasNoChildren attribute. In many cases, however, a server may not
|
||||
be able to efficiently compute whether a user has access to all child
|
||||
mailboxes. If such a server responds with a \HasChildren attribute,
|
||||
when in fact the currently authenticated user does not have access to
|
||||
any child mailboxes, potentially more information is conveyed about
|
||||
the mailbox than intended. A server designed with such levels of
|
||||
security in mind SHOULD NOT attach the \HasChildren attribute to a
|
||||
mailbox unless the server is certain that the user has access to at
|
||||
least one of the child mailboxes.
|
||||
|
||||
|
||||
|
||||
Gahrns, et al. Informational [Page 4]
|
||||
|
||||
RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
||||
|
||||
|
||||
7. References
|
||||
|
||||
[RFC-2060] Crispin, M., "Internet Message Access Protocol - Version
|
||||
4rev1", RFC 2060, December 1996.
|
||||
|
||||
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC-2234] Crocker, D. and P. Overell, Editors, "Augmented BNF for
|
||||
Syntax Specifications: ABNF", RFC 2234, November 1997.
|
||||
|
||||
[RFC-2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September
|
||||
1997.
|
||||
|
||||
8. Acknowledgments
|
||||
|
||||
The authors would like to thank the participants of several IMC Mail
|
||||
Connect events for their input when this idea was originally
|
||||
presented and refined.
|
||||
|
||||
9. Author's Address
|
||||
|
||||
Mike Gahrns
|
||||
Microsoft
|
||||
One Microsoft Way
|
||||
Redmond, WA, 98052
|
||||
Phone: (425) 936-9833
|
||||
EMail: mikega@microsoft.com
|
||||
|
||||
Raymond Cheng
|
||||
Microsoft
|
||||
One Microsoft Way
|
||||
Redmond, WA, 98052
|
||||
Phone: (425) 703-4913
|
||||
EMail: raych@microsoft.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns, et al. Informational [Page 5]
|
||||
|
||||
RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
||||
|
||||
|
||||
10. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
||||
|
||||
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.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
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.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gahrns, et al. Informational [Page 6]
|
||||
|
||||
6052
docs/rfc/rfc3501.txt
Normal file
6052
docs/rfc/rfc3501.txt
Normal file
File diff suppressed because it is too large
Load Diff
395
docs/rfc/rfc3502.txt
Normal file
395
docs/rfc/rfc3502.txt
Normal file
@ -0,0 +1,395 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Crispin
|
||||
Request for Comments: 3502 University of Washington
|
||||
Category: Standards Track March 2003
|
||||
|
||||
|
||||
Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes the multiappending extension to the Internet
|
||||
Message Access Protocol (IMAP) (RFC 3501). This extension provides
|
||||
substantial performance improvements for IMAP clients which upload
|
||||
multiple messages at a time to a mailbox on the server.
|
||||
|
||||
A server which supports this extension indicates this with a
|
||||
capability name of "MULTIAPPEND".
|
||||
|
||||
Terminology
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
|
||||
be interpreted as described in [KEYWORDS].
|
||||
|
||||
Introduction
|
||||
|
||||
The MULTIAPPEND extension permits uploading of multiple messages with
|
||||
a single command. When used in conjunction with the [LITERAL+]
|
||||
extension, the entire upload is accomplished in a single
|
||||
command/response round trip.
|
||||
|
||||
A MULTIAPPEND APPEND operation is atomic; either all messages are
|
||||
successfully appended, or no messages are appended.
|
||||
|
||||
In the base IMAP specification, each message must be appended in a
|
||||
separate command, and there is no mechanism to "unappend" messages if
|
||||
an error occurs while appending. Also, some mail stores may require
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 1]
|
||||
|
||||
RFC 3502 IMAP MULTIAPPEND March 2003
|
||||
|
||||
|
||||
an expensive "open/lock + sync/unlock/close" operation as part of
|
||||
appending; this can be quite expensive if it must be done on a
|
||||
per-message basis.
|
||||
|
||||
If the server supports both LITERAL+ and pipelining but not
|
||||
MULTIAPPEND, it may be possible to get some of the performance
|
||||
advantages of MULTIAPPEND by doing a pipelined "batch" append.
|
||||
However, it will not work as well as MULTIAPPEND for the following
|
||||
reasons:
|
||||
|
||||
1) Multiple APPEND commands, even as part of a pipelined batch,
|
||||
are non-atomic by definition. There is no way to revert the
|
||||
mailbox to the state before the batch append in the event of an
|
||||
error.
|
||||
|
||||
2) It may not be feasible for the server to coalesce pipelined
|
||||
APPEND operations so as to avoid the "open/lock +
|
||||
sync/unlock/close" overhead described above. In any case, such
|
||||
coalescing would be timing dependent and thus potentially
|
||||
unreliable. In particular, with traditional UNIX mailbox files,
|
||||
it is assumed that a lock is held only for a single atomic
|
||||
operation, and many applications disregard any lock that is
|
||||
older than 5 minutes.
|
||||
|
||||
3) If an error occurs, depending upon the nature of the error,
|
||||
it is possible for additional messages to be appended after the
|
||||
error. For example, the user wants to append 5 messages, but a
|
||||
disk quota error occurs with the third message because of its
|
||||
size. However, the fourth and fifth messages have already been
|
||||
sent in the pipeline, so the mailbox ends up with the first,
|
||||
second, fourth, and fifth messages of the batch appended.
|
||||
|
||||
6.3.11. APPEND Command
|
||||
|
||||
Arguments: mailbox name
|
||||
one or more messages to upload, specified as:
|
||||
OPTIONAL flag parenthesized list
|
||||
OPTIONAL date/time string
|
||||
message literal
|
||||
|
||||
Data: no specific responses for this command
|
||||
|
||||
Result: OK - append completed
|
||||
NO - append error: can't append to that mailbox, error
|
||||
in flags or date/time or message text,
|
||||
append cancelled
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 2]
|
||||
|
||||
RFC 3502 IMAP MULTIAPPEND March 2003
|
||||
|
||||
|
||||
The APPEND command appends the literal arguments as new messages
|
||||
to the end of the specified destination mailbox. This argument
|
||||
SHOULD be in the format of an [RFC-2822] message. 8-bit
|
||||
characters are permitted in the message. A server implementation
|
||||
that is unable to preserve 8-bit data properly MUST be able to
|
||||
reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
|
||||
content transfer encoding.
|
||||
|
||||
Note: There MAY be exceptions, e.g., draft messages, in
|
||||
which required [RFC-2822] header lines are omitted in the
|
||||
message literal argument to APPEND. The full implications
|
||||
of doing so MUST be understood and carefully weighed.
|
||||
|
||||
If a flag parenthesized list is specified, the flags SHOULD be set
|
||||
in the resulting message; otherwise, the flag list of the
|
||||
resulting message is set empty by default.
|
||||
|
||||
If a date-time is specified, the internal date SHOULD be set in
|
||||
the resulting message; otherwise, the internal date of the
|
||||
resulting message is set to the current date and time by default.
|
||||
|
||||
A zero-length message literal argument is an error, and MUST
|
||||
return a NO. This can be used to cancel the append.
|
||||
|
||||
If the append is unsuccessful for any reason (including being
|
||||
cancelled), the mailbox MUST be restored to its state before the
|
||||
APPEND attempt; no partial appending is permitted. The server MAY
|
||||
return an error before processing all the message arguments.
|
||||
|
||||
If the destination mailbox does not exist, a server MUST return an
|
||||
error, and MUST NOT automatically create the mailbox. Unless it
|
||||
is certain that the destination mailbox can not be created, the
|
||||
server MUST 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.
|
||||
|
||||
If the mailbox is currently selected, the normal new message
|
||||
actions SHOULD occur. Specifically, the server SHOULD notify the
|
||||
client immediately via an untagged EXISTS response. If the server
|
||||
does not do so, the client MAY issue a NOOP command (or failing
|
||||
that, a CHECK command) after one or more APPEND commands.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 3]
|
||||
|
||||
RFC 3502 IMAP MULTIAPPEND March 2003
|
||||
|
||||
|
||||
Example: C: A003 APPEND saved-messages (\Seen) {329}
|
||||
S: + Ready for literal data
|
||||
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
|
||||
C: From: Fred Foobar <foobar@Blurdybloop.example.COM>
|
||||
C: Subject: afternoon meeting
|
||||
C: To: mooch@owatagu.example.net
|
||||
C: Message-Id: <B27397-0100000@Blurdybloop.example.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: (\Seen) " 7-Feb-1994 22:43:04 -0800" {295}
|
||||
S: + Ready for literal data
|
||||
C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
|
||||
C: From: Joe Mooch <mooch@OWaTaGu.example.net>
|
||||
C: Subject: Re: afternoon meeting
|
||||
C: To: foobar@blurdybloop.example.com
|
||||
C: Message-Id: <a0434793874930@OWaTaGu.example.net>
|
||||
C: MIME-Version: 1.0
|
||||
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
|
||||
C:
|
||||
C: 3:30 is fine with me.
|
||||
C:
|
||||
S: A003 OK APPEND completed
|
||||
C: A004 APPEND bogusname (\Flagged) {1023}
|
||||
S: A004 NO [TRYCREATE] No such mailbox as bogusname
|
||||
C: A005 APPEND test (\Flagged) {99}
|
||||
S: + Ready for literal data
|
||||
C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST)
|
||||
C: From: Fred Foobar <fred@example.com>
|
||||
C: Subject: hmm...
|
||||
C: {35403}
|
||||
S: A005 NO APPEND failed: Disk quota exceeded
|
||||
|
||||
Note: The APPEND command is not used for message delivery,
|
||||
because it does not provide a mechanism to transfer [SMTP]
|
||||
envelope information.
|
||||
|
||||
Modification to IMAP4rev1 Base Protocol Formal Syntax
|
||||
|
||||
The following syntax specification uses the Augmented Backus-Naur
|
||||
Form (ABNF) notation as specified in [ABNF].
|
||||
|
||||
append = "APPEND" SP mailbox 1*append-message
|
||||
|
||||
append-message = [SP flag-list] [SP date-time] SP literal
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 4]
|
||||
|
||||
RFC 3502 IMAP MULTIAPPEND March 2003
|
||||
|
||||
|
||||
MULTIAPPEND Interaction with UIDPLUS Extension
|
||||
|
||||
Servers which support both MULTIAPPEND and [UIDPLUS] will have the
|
||||
"resp-code-apnd" rule modified as follows:
|
||||
|
||||
resp-code-apnd = "APPENDUID" SP nz-number SP set
|
||||
|
||||
That is, the APPENDUID response code returns as many UIDs as there
|
||||
were messages appended in the multiple append. The UIDs returned
|
||||
should be in the order the articles where appended. The message set
|
||||
may not contain extraneous UIDs or the symbol "*".
|
||||
|
||||
Security Considerations
|
||||
|
||||
The MULTIAPPEND extension does not raise any security considerations
|
||||
that are not present in the base [IMAP] protocol, and these issues
|
||||
are discussed in [IMAP]. Nevertheless, it is important to remember
|
||||
that IMAP4rev1 protocol transactions, including electronic mail data,
|
||||
are sent in the clear over the network unless protection from
|
||||
snooping is negotiated, either by the use of STARTTLS, privacy
|
||||
protection is negotiated in the AUTHENTICATE command, or some other
|
||||
protection mechanism is in effect.
|
||||
|
||||
Normative References
|
||||
|
||||
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 2234, November 1997.
|
||||
|
||||
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
|
||||
4rev1", RFC 3501, March 2003.
|
||||
|
||||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet
|
||||
Mail Extensions) Part One: Format of Internet Message
|
||||
Bodies", RFC 2045, November 1996.
|
||||
|
||||
[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April
|
||||
2001.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 5]
|
||||
|
||||
RFC 3502 IMAP MULTIAPPEND March 2003
|
||||
|
||||
|
||||
Informative References
|
||||
|
||||
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
|
||||
January 1997.
|
||||
|
||||
[UIDPLUS] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1988.
|
||||
|
||||
[SMTP] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
|
||||
2821, April 2001.
|
||||
|
||||
Author's Address
|
||||
|
||||
Mark R. Crispin
|
||||
Networks and Distributed Computing
|
||||
University of Washington
|
||||
4545 15th Avenue NE
|
||||
Seattle, WA 98105-4527
|
||||
|
||||
Phone: (206) 543-5762
|
||||
EMail: MRC@CAC.Washington.EDU
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 6]
|
||||
|
||||
RFC 3502 IMAP MULTIAPPEND March 2003
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
||||
|
||||
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.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
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.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 7]
|
||||
|
||||
507
docs/rfc/rfc3503.txt
Normal file
507
docs/rfc/rfc3503.txt
Normal file
@ -0,0 +1,507 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group A. Melnikov
|
||||
Request for Comments: 3503 ACI Worldwide/MessagingDirect
|
||||
Category: Standards Track March 2003
|
||||
|
||||
|
||||
Message Disposition Notification (MDN) profile for
|
||||
Internet Message Access Protocol (IMAP)
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
The Message Disposition Notification (MDN) facility defined in RFC
|
||||
2298 provides a means by which a message can request that message
|
||||
processing by the recipient be acknowledged as well as a format to be
|
||||
used for such acknowledgements. However, it doesn't describe how
|
||||
multiple Mail User Agents (MUAs) should handle the generation of MDNs
|
||||
in an Internet Message Access Protocol (IMAP4) environment.
|
||||
|
||||
This document describes how to handle MDNs in such an environment and
|
||||
provides guidelines for implementers of IMAP4 that want to add MDN
|
||||
support to their products.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 1]
|
||||
|
||||
RFC 3503 MDN profile for IMAP March 2003
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Conventions Used in this Document............................. 2
|
||||
2. Introduction and Overview..................................... 2
|
||||
3. Client behavior............................................... 3
|
||||
3.1. Client behavior when receiving a message................. 5
|
||||
3.2. Client behavior when copying a message................... 5
|
||||
3.3. Client behavior when sending a message................... 5
|
||||
3.4. Client behavior when saving a temporary message.......... 5
|
||||
4. Server behavior............................................... 5
|
||||
4.1. Server that supports arbitrary keywords.................. 5
|
||||
4.2. Server that supports only $MDNSent keyword............... 5
|
||||
4.3. Interaction with IMAP ACL extension...................... 6
|
||||
5. Examples...................................................... 6
|
||||
6. Security Considerations....................................... 7
|
||||
7. Formal Syntax................................................. 7
|
||||
8. Acknowledgments............................................... 7
|
||||
9. Normative References.......................................... 8
|
||||
10. Author's Address.............................................. 8
|
||||
11. Full Copyright Statement...................................... 9
|
||||
|
||||
1. Conventions Used in this Document
|
||||
|
||||
"C:" and "S:" in examples show lines sent by the client and server
|
||||
respectively.
|
||||
|
||||
The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
|
||||
this document when typed in uppercase are to be interpreted as
|
||||
defined in "Key words for use in RFCs to Indicate Requirement Levels"
|
||||
[KEYWORDS].
|
||||
|
||||
2. Introduction and Overview
|
||||
|
||||
This memo defines an additional [IMAP4] mailbox keyword that allows
|
||||
multiple Mail User Agents (MUAs) to know if a requested receipt
|
||||
notification was sent.
|
||||
|
||||
Message Disposition Notification [MDN] does not require any special
|
||||
support of IMAP in the case where a user has access to the mailstore
|
||||
from only one computer and is using a single MUA. In this case, the
|
||||
MUA behaves as described in [MDN], i.e., the MUA performs automatic
|
||||
processing and generates corresponding MDNs, it performs requested
|
||||
action and, with the user's permission, sends appropriate MDNs. The
|
||||
MUA will not send MDN twice because the MUA keeps track of sent
|
||||
notifications in a local configuration. However, that does not work
|
||||
when IMAP is used to access the same mailstore from different
|
||||
locations or is using different MUAs.
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 2]
|
||||
|
||||
RFC 3503 MDN profile for IMAP March 2003
|
||||
|
||||
|
||||
This document defines a new special purpose mailbox keyword $MDNSent
|
||||
that must be used by MUAs. It does not define any new command or
|
||||
response for IMAP, but describes a technique that MUAs should use to
|
||||
achieve interoperability.
|
||||
|
||||
When a client opens a mailbox for the first time, it verifies that
|
||||
the server is capable of storing the $MDNSent keyword by examining
|
||||
the PERMANENTFLAGS response code. In order to support MDN in IMAP, a
|
||||
server MUST support either the $MDNSent keyword, or arbitrary message
|
||||
keywords.
|
||||
|
||||
3. Client behavior
|
||||
|
||||
The use of IMAP requires few additional steps in mail processing on
|
||||
the client side. The following timeline modifies the timeline found
|
||||
in Section 4 of [MDN].
|
||||
|
||||
-- User composes message.
|
||||
|
||||
-- User tells MUA to send message.
|
||||
|
||||
-- MUA passes message to MSA (original recipient information passed
|
||||
along). MUA [optionally] saves message to a folder for sent mail
|
||||
with $MDNSent flag set.
|
||||
|
||||
-- MSA sends message to MTA.
|
||||
|
||||
-- Final MTA receives message.
|
||||
|
||||
-- Final MTA delivers message to MUA (possibly generating DSN).
|
||||
|
||||
-- MUA logs into IMAP server, opens mailbox, verifies if mailbox can
|
||||
store $MDNSent keyword by examining PERMANENTFLAGS response.
|
||||
|
||||
-- MUA performs automatic processing and generates corresponding MDNs
|
||||
("dispatched", "processed", "deleted", "denied" or "failed"
|
||||
disposition type with "automatic-action" and "MDN-sent-
|
||||
automatically" disposition modes) for messages that do not have
|
||||
$MDNSent keyword, or \Draft flag set. (*)
|
||||
|
||||
-- MUA sets the $MDNSent keyword for every message that required an
|
||||
automatic MDN to be sent, whether or not the MDN was sent.
|
||||
|
||||
-- MUA displays a list of messages to user.
|
||||
|
||||
-- User selects a message and requests that some action be performed
|
||||
on it.
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 3]
|
||||
|
||||
RFC 3503 MDN profile for IMAP March 2003
|
||||
|
||||
|
||||
-- MUA performs requested action and, with user's permission, sends
|
||||
appropriate MDN ("displayed", "dispatched", "processed",
|
||||
"deleted", "denied" or "failed" disposition type with "manual-
|
||||
action" and "MDN-sent-manually" or "MDN-sent-automatically"
|
||||
disposition mode). If the generated MDN is saved to a mailbox
|
||||
with the APPEND command, the client MUST specify the $MDNSent
|
||||
keyword in the APPEND.
|
||||
|
||||
-- MUA sets the $MDNSent keyword for all messages for which the user
|
||||
confirmed the dispatching of disposition (or was explicitly
|
||||
prohibited to do so).
|
||||
|
||||
-- User possibly performs other actions on message, but no further
|
||||
MDNs are generated.
|
||||
|
||||
(*) Note: MUA MUST NOT use \Recent flag as an indicator that it
|
||||
should send MDN, because according to [IMAP4], "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". Thus, using \Recent as an indicator will cause
|
||||
unpredictable client behavior with different IMAP4 servers.
|
||||
However, the client MAY use \Seen flag as one of the indicators
|
||||
that MDN must not be sent. The client MUST NOT use any other
|
||||
standard flags, like \Draft or \Answered, to indicate that MDN
|
||||
was previously sent, because they have different well known
|
||||
meaning. In any case, in the presence of the $MDNSent keyword,
|
||||
the client MUST ignore all other flags or keywords for the
|
||||
purpose of generating an MDN and MUST NOT send the MDN.
|
||||
|
||||
When the client opens a mailbox for the first time, it must verify
|
||||
that the server supports the $MDNSent keyword, or arbitrary message
|
||||
keywords by examining PERMANENTFLAGS response code.
|
||||
|
||||
The client MUST NOT try to set the $MDNSent keyword if the server is
|
||||
incapable of storing it permanently.
|
||||
|
||||
The client MUST be prepared to receive NO from the server as the
|
||||
result of STORE $MDNSent when the server advertises the support of
|
||||
storing arbitrary keywords, because the server may limit the number
|
||||
of message keywords it can store in a particular mailbox. A client
|
||||
SHOULD NOT send MDN if it fails to store the $MDNSent keyword.
|
||||
|
||||
Once the $MDNSent keyword is set, it MUST NOT be unset by a client.
|
||||
The client MAY set the $MDNSent keyword when a user denies sending
|
||||
the notification. This prohibits all other MUAs from sending MDN for
|
||||
this message.
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 4]
|
||||
|
||||
RFC 3503 MDN profile for IMAP March 2003
|
||||
|
||||
|
||||
3.1. Client behavior when receiving a message
|
||||
|
||||
The client MUST NOT send MDN if a message has the $MDNSent keyword
|
||||
set. It also MUST NOT send MDN if a message has \Draft flag, because
|
||||
some clients use this flag to mark a message as incomplete.
|
||||
|
||||
See the timeline in section 3 for details on client behavior when
|
||||
receiving a message.
|
||||
|
||||
3.2. Client behavior when copying a message
|
||||
|
||||
The client SHOULD verify that $MDNSent is preserved on a COPY
|
||||
operation. Furthermore, when a message is copied between servers
|
||||
with the APPEND command, the client MUST set the $MDNSent keyword
|
||||
correctly.
|
||||
|
||||
3.3. Client behavior when sending a message
|
||||
|
||||
When saving a sent message to any folder, the client MUST set the
|
||||
$MDNSent keyword to prevent another client from sending MDN for the
|
||||
message.
|
||||
|
||||
3.4. Client behavior when saving a temporary message
|
||||
|
||||
When saving an unfinished message to any folder client MUST set
|
||||
$MDNSent keyword to prevent another client from sending MDN for the
|
||||
message.
|
||||
|
||||
4. Server behavior
|
||||
|
||||
Server implementors that want to follow this specification must
|
||||
insure that their server complies with either section 4.1 or section
|
||||
4.2. If the server also supports the IMAP [ACL] extension, it MUST
|
||||
also comply with the section 4.3.
|
||||
|
||||
4.1. Server that supports arbitrary keywords
|
||||
|
||||
No changes are required from the server to make it compatible with
|
||||
the extension described in this document if it supports arbitrary
|
||||
keywords.
|
||||
|
||||
4.2. Server that supports only $MDNSent keyword
|
||||
|
||||
Servers that support only the $MDNSent keyword MUST preserve it on
|
||||
the COPY operation. It is also expected that a server that supports
|
||||
SEARCH <flag> will also support the SEARCH KEYWORD $MDNSent.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 5]
|
||||
|
||||
RFC 3503 MDN profile for IMAP March 2003
|
||||
|
||||
|
||||
4.3. Interaction with IMAP ACL extension
|
||||
|
||||
Any server that conforms to either 4.1 or 4.2 and also supports the
|
||||
IMAP [ACL] extension, SHOULD preserve the $MDNSent keyword on COPY
|
||||
even if the client does not have 'w' right. This will prevent the
|
||||
generation of a duplicated MDN for the same message. Note that the
|
||||
server MUST still check if the client has rights to perform the COPY
|
||||
operation on a message according to [ACL].
|
||||
|
||||
5. Examples
|
||||
|
||||
1) MUA opens mailbox for the first time.
|
||||
|
||||
a) The server supports storing of arbitrary keywords
|
||||
|
||||
C: a100 select INBOX
|
||||
S: * FLAGS (\Flagged \Draft \Deleted \Seen)
|
||||
S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)]
|
||||
S: * 5 EXISTS
|
||||
S: * 3 RECENT
|
||||
S: * OK [UIDVALIDITY 894294713]
|
||||
S: a100 OK [READ-WRITE] Completed
|
||||
|
||||
b) The server supports storing of the $MDNSent keyword
|
||||
|
||||
C: a100 select INBOX
|
||||
S: * FLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)
|
||||
S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)]
|
||||
S: * 5 EXISTS
|
||||
S: * 3 RECENT
|
||||
S: * OK [UIDVALIDITY 894294713]
|
||||
S: a100 OK [READ-WRITE] Completed
|
||||
|
||||
2) The MUA successfully sets the $MDNSent keyword
|
||||
|
||||
C: a200 STORE 4 +FLAGS ($MDNSent)
|
||||
S: * 4 FETCH (FLAGS (\Flagged \Seen $MDNSent))
|
||||
S: * FLAGS ($MDNSent \Flagged \Deleted \Draft \Seen)
|
||||
S: * OK [PERMANENTFLAGS ($MDNSent \Flagged \Deleted \Draft \Seen \*)]
|
||||
S: a200 OK STORE completed
|
||||
|
||||
3) The server refuses to store the $MDNSent keyword
|
||||
|
||||
C: a200 STORE 4 +FLAGS ($MDNSent)
|
||||
S: a200 NO STORE failed : no space left to store $MDNSent keyword
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 6]
|
||||
|
||||
RFC 3503 MDN profile for IMAP March 2003
|
||||
|
||||
|
||||
4) All clients and servers MUST treat the $MDNSent keyword as case
|
||||
insensitive in all operations, as stated in [IMAP].
|
||||
|
||||
C: a300 FETCH 1:* FLAGS
|
||||
S: * 1 FETCH (FLAGS (\Seen))
|
||||
S: * 2 FETCH (FLAGS (\Answered \Seen $MdnSENt))
|
||||
S: * 3 FETCH (FLAGS ())
|
||||
S: * 4 FETCH (FLAGS (\Flagged \Seen $MdnSENT))
|
||||
S: * 5 FETCH (FLAGS ($MDNSent))
|
||||
S: * 6 FETCH (FLAGS (\Recent))
|
||||
S: a300 OK FETCH completed
|
||||
C: a400 SEARCH KEYWORDS $mdnsent
|
||||
S: * SEARCH 2 4 5
|
||||
S: a400 OK SEARCH completed
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
There are no known security issues with this extension, not found in
|
||||
[MDN] and/or [IMAP4].
|
||||
|
||||
Section 4.3 changes ACL checking requirements on an IMAP server that
|
||||
implements IMAP [ACL] extension.
|
||||
|
||||
7. Formal Syntax
|
||||
|
||||
The following syntax specification uses the augmented Backus-Naur
|
||||
Form (BNF) notation as specified in [RFC-822], as modified by
|
||||
[IMAP4]. Non-terminals referenced, but not defined below, are as
|
||||
defined by [IMAP4].
|
||||
|
||||
Except as noted otherwise, all alphabetic characters are case-
|
||||
insensitive. The use of upper or lower case characters to define
|
||||
token strings is for editorial clarity only. Implementations MUST
|
||||
accept these strings in a case-insensitive fashion.
|
||||
|
||||
flag_keyword ::= "$MDNSent" / other_keywords
|
||||
|
||||
other_keywords ::= atom
|
||||
|
||||
8. Acknowledgments
|
||||
|
||||
This document is the product of discussions that took place on the
|
||||
IMAP mailing list. Special gratitude to Cyrus Daboo and Randall
|
||||
Gellens for reviewing the document.
|
||||
|
||||
Thank you to my father who as he has helped to make me what I am. I
|
||||
miss you terribly.
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 7]
|
||||
|
||||
RFC 3503 MDN profile for IMAP March 2003
|
||||
|
||||
|
||||
9. Normative References
|
||||
|
||||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[MDN] Fajman, R., "An Extensible Message Format for Message
|
||||
Disposition Notifications", RFC 2298, March 1998.
|
||||
|
||||
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
|
||||
4rev1", RFC 3501, March 2003.
|
||||
|
||||
[ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
|
||||
|
||||
10. Author's Address
|
||||
|
||||
Alexey Melnikov
|
||||
ACI Worldwide/MessagingDirect
|
||||
59 Clarendon Road
|
||||
Watford, Hertfordshire
|
||||
United Kingdom, WD17 1FQ
|
||||
|
||||
Phone: +44 1923 81 2877
|
||||
EMail: mel@messagingdirect.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 8]
|
||||
|
||||
RFC 3503 MDN profile for IMAP March 2003
|
||||
|
||||
|
||||
11. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
||||
|
||||
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.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
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.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 9]
|
||||
|
||||
451
docs/rfc/rfc3516.txt
Normal file
451
docs/rfc/rfc3516.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group L. Nerenberg
|
||||
Request for Comments: 3516 Orthanc Systems
|
||||
Category: Standards Track April 2003
|
||||
|
||||
|
||||
IMAP4 Binary Content Extension
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
This memo defines the Binary extension to the Internet Message Access
|
||||
Protocol (IMAP4). It provides a mechanism for IMAP4 clients and
|
||||
servers to exchange message body data without using a MIME content-
|
||||
transfer-encoding.
|
||||
|
||||
1. Conventions Used in this Document
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
|
||||
in this document are to be interpreted as described in [KEYWORD].
|
||||
|
||||
The abbreviation "CTE" means content-transfer-encoding.
|
||||
|
||||
2. Introduction
|
||||
|
||||
The MIME extensions to Internet messaging allow for the transmission
|
||||
of non-textual (binary) message content [MIME-IMB]. Since the
|
||||
traditional transports for messaging are not always capable of
|
||||
passing binary data transparently, MIME provides encoding schemes
|
||||
that allow binary content to be transmitted over transports that are
|
||||
not otherwise able to do so.
|
||||
|
||||
The overhead of MIME-encoding this content can be considerable in
|
||||
some contexts (e.g., slow radio links, streaming multimedia).
|
||||
Reducing the overhead associated with CTE schemes such as base64
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Nerenberg Standards Track [Page 1]
|
||||
|
||||
RFC 3516 IMAP4 Binary Content Extension April 2003
|
||||
|
||||
|
||||
can give a noticeable reduction in resource consumption. The Binary
|
||||
extension lets the server perform CTE decoding prior to transmitting
|
||||
message data to the client.
|
||||
|
||||
3. Content-Transfer-Encoding Considerations
|
||||
|
||||
Every IMAP4 body section has a MIME content-transfer-encoding.
|
||||
(Those without an explicit Content-Transfer-Encoding header are
|
||||
implicitly labeled as "7bit" content.) In the terminology of [MIME-
|
||||
IMB], the CTE specifies both a decoding algorithm and the domain of
|
||||
the decoded data. In this memo, "decoding" refers to the CTE
|
||||
decoding step described in [MIME-IMB].
|
||||
|
||||
Certain CTEs use an identity encoding transformation. For these CTEs
|
||||
there is no decoding required, however the domain of the underlying
|
||||
data may not be expressible in the IMAP4 protocol (e.g., MIME
|
||||
"binary" content containing NUL octets). To accommodate these cases
|
||||
the Binary extension introduces a new type of literal protocol
|
||||
element that is fully eight bit transparent.
|
||||
|
||||
Thus, server processing of the FETCH BINARY command involves two
|
||||
logical steps:
|
||||
|
||||
1) perform any CTE-related decoding
|
||||
|
||||
2) determine the domain of the decoded data
|
||||
|
||||
Step 2 is necessary to determine which protocol element should be
|
||||
used to transmit the decoded data. (See FETCH Response Extensions
|
||||
for further details.)
|
||||
|
||||
4. Framework for the IMAP4 Binary Extension
|
||||
|
||||
This memo defines the following extensions to [IMAP4rev1].
|
||||
|
||||
4.1. CAPABILITY Identification
|
||||
|
||||
IMAP4 servers that support this extension MUST include "BINARY" in
|
||||
the response list to the CAPABILITY command.
|
||||
|
||||
4.2. FETCH Command Extensions
|
||||
|
||||
This extension defines three new FETCH command data items.
|
||||
|
||||
BINARY<section-binary>[<partial>]
|
||||
|
||||
Requests that the specified section be transmitted after
|
||||
performing CTE-related decoding.
|
||||
|
||||
|
||||
|
||||
Nerenberg Standards Track [Page 2]
|
||||
|
||||
RFC 3516 IMAP4 Binary Content Extension April 2003
|
||||
|
||||
|
||||
The <partial> argument, if present, requests that a subset of
|
||||
the data be returned. The semantics of a partial FETCH BINARY
|
||||
command are the same as for a partial FETCH BODY command, with
|
||||
the exception that the <partial> arguments refer to the DECODED
|
||||
section data.
|
||||
|
||||
BINARY.PEEK<section-binary>[<partial>]
|
||||
|
||||
An alternate form of FETCH BINARY that does not implicitly set
|
||||
the \Seen flag.
|
||||
|
||||
BINARY.SIZE<section-binary>
|
||||
|
||||
Requests the decoded size of the section (i.e., the size to
|
||||
expect in response to the corresponding FETCH BINARY request).
|
||||
|
||||
Note: client authors are cautioned that this might be an
|
||||
expensive operation for some server implementations.
|
||||
Needlessly issuing this request could result in degraded
|
||||
performance due to servers having to calculate the value every
|
||||
time the request is issued.
|
||||
|
||||
4.3. FETCH Response Extensions
|
||||
|
||||
This extension defines two new FETCH response data items.
|
||||
|
||||
BINARY<section-binary>[<<number>>]
|
||||
|
||||
An <nstring> or <literal8> expressing the content of the
|
||||
specified section after removing any CTE-related encoding. If
|
||||
<number> is present it refers to the offset within the DECODED
|
||||
section data.
|
||||
|
||||
If the domain of the decoded data is "8bit" and the data does
|
||||
not contain the NUL octet, the server SHOULD return the data in
|
||||
a <string> instead of a <literal8>; this allows the client to
|
||||
determine if the "8bit" data contains the NUL octet without
|
||||
having to explicitly scan the data stream for for NULs.
|
||||
|
||||
If the server does not know how to decode the section's CTE, it
|
||||
MUST fail the request and issue a "NO" response that contains
|
||||
the "UNKNOWN-CTE" extended response code.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Nerenberg Standards Track [Page 3]
|
||||
|
||||
RFC 3516 IMAP4 Binary Content Extension April 2003
|
||||
|
||||
|
||||
BINARY.SIZE<section-binary>
|
||||
|
||||
The size of the section after removing any CTE-related
|
||||
encoding. The value returned MUST match the size of the
|
||||
<nstring> or <literal8> that will be returned by the
|
||||
corresponding FETCH BINARY request.
|
||||
|
||||
If the server does not know how to decode the section's CTE, it
|
||||
MUST fail the request and issue a "NO" response that contains
|
||||
the "UNKNOWN-CTE" extended response code.
|
||||
|
||||
4.4. APPEND Command Extensions
|
||||
|
||||
The APPEND command is extended to allow the client to append data
|
||||
containing NULs by using the <literal8> syntax. The server MAY
|
||||
modify the CTE of the appended data, however any such transformation
|
||||
MUST NOT result in a loss of data.
|
||||
|
||||
If the destination mailbox does not support the storage of binary
|
||||
content, the server MUST fail the request and issue a "NO" response
|
||||
that contains the "UNKNOWN-CTE" extended response code.
|
||||
|
||||
5. MIME Encoded Headers
|
||||
|
||||
[MIME-MHE] defines an encoding that allows for non-US-ASCII text in
|
||||
message headers. This encoding is not the same as the content-
|
||||
transfer-encoding applied to message bodies, and the decoding
|
||||
transformations described in this memo do not apply to [MIME-MHE]
|
||||
encoded header text. A server MUST NOT perform any conversion of
|
||||
[MIME-MHE] encoded header text in response to any binary FETCH or
|
||||
APPEND request.
|
||||
|
||||
6. Implementation Considerations
|
||||
|
||||
Messaging clients and servers have been notoriously lax in their
|
||||
adherence to the Internet CRLF convention for terminating lines of
|
||||
textual data in Internet protocols. When sending data using the
|
||||
Binary extension, servers MUST ensure that textual line-oriented
|
||||
sections are always transmitted using the IMAP4 CRLF line termination
|
||||
syntax, regardless of the underlying storage representation of the
|
||||
data on the server.
|
||||
|
||||
A server may choose to store message body binary content in a non-
|
||||
encoded format. Regardless of the internal storage representation
|
||||
used, the server MUST issue BODYSTRUCTURE responses that describe the
|
||||
message as though the binary-encoded sections are encoded in a CTE
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Nerenberg Standards Track [Page 4]
|
||||
|
||||
RFC 3516 IMAP4 Binary Content Extension April 2003
|
||||
|
||||
|
||||
acceptable to the IMAP4 base specification. Furthermore, the results
|
||||
of a FETCH BODY MUST return the message body content in the format
|
||||
described by the corresponding FETCH BODYSTRUCTURE response.
|
||||
|
||||
While the server is allowed to modify the CTE of APPENDed <literal8>
|
||||
data, this should only be done when it is absolutely necessary.
|
||||
Gratuitous encoding changes will render useless most cryptographic
|
||||
operations that have been performed on the message.
|
||||
|
||||
This extension provides an optimization that is useful in certain
|
||||
specific situations. It does not absolve clients from providing
|
||||
basic functionality (content transfer decoding) that should be
|
||||
available in all messaging clients. Clients supporting this
|
||||
extension SHOULD be prepared to perform their own CTE decoding
|
||||
operations.
|
||||
|
||||
7. Formal Protocol Syntax
|
||||
|
||||
The following syntax specification uses the augmented Backus-Naur
|
||||
Form (ABNF) notation as used in [ABNF], and incorporates by reference
|
||||
the Core Rules defined in that document.
|
||||
|
||||
This syntax augments the grammar specified in [IMAP4rev1].
|
||||
|
||||
append =/ "APPEND" SP mailbox [SP flag-list]
|
||||
[SP date-time] SP literal8
|
||||
|
||||
fetch-att =/ "BINARY" [".PEEK"] section-binary [partial]
|
||||
/ "BINARY.SIZE" section-binary
|
||||
|
||||
literal8 = "~{" number "}" CRLF *OCTET
|
||||
; <number> represents the number of OCTETs
|
||||
; in the response string.
|
||||
|
||||
msg-att-static =/ "BINARY" section-binary SP (nstring / literal8)
|
||||
/ "BINARY.SIZE" section-binary SP number
|
||||
|
||||
partial = "<" number "." nz-number ">"
|
||||
|
||||
resp-text-code =/ "UNKNOWN-CTE"
|
||||
|
||||
section-binary = "[" [section-part] "]"
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Nerenberg Standards Track [Page 5]
|
||||
|
||||
RFC 3516 IMAP4 Binary Content Extension April 2003
|
||||
|
||||
|
||||
8. Normative References
|
||||
|
||||
[ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for
|
||||
Syntax Specifications: ABNF", RFC 2234, November 1997.
|
||||
|
||||
[IMAP4rev1] Crispin, M., "Internet Message Access Protocol Version
|
||||
4rev1", RFC 3501, March 2003.
|
||||
|
||||
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[MIME-IMB] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
||||
Extensions (MIME) Part One: Format of Internet Message
|
||||
Bodies", RFC 2045, November 1996.
|
||||
|
||||
[MIME-MHE] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
|
||||
Part Three: Message Header Extensions for Non-ASCII
|
||||
Text", RFC 2047, November 1996.
|
||||
|
||||
9. Security Considerations
|
||||
|
||||
There are no known additional security issues with this extension
|
||||
beyond those described in the base protocol described in [IMAP4rev1].
|
||||
|
||||
10. Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
intellectual property or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; neither does it represent that it
|
||||
has made any effort to identify any such rights. Information on the
|
||||
IETF's procedures with respect to rights in standards-track and
|
||||
standards-related documentation can be found in BCP-11. Copies of
|
||||
claims of rights made available for publication and any assurances of
|
||||
licenses to be made available, or the result of an attempt made to
|
||||
obtain a general license or permission for the use of such
|
||||
proprietary rights by implementors or users of this specification can
|
||||
be obtained from the IETF Secretariat.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights which may cover technology that may be required to practice
|
||||
this standard. Please address the information to the IETF Executive
|
||||
Director.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Nerenberg Standards Track [Page 6]
|
||||
|
||||
RFC 3516 IMAP4 Binary Content Extension April 2003
|
||||
|
||||
|
||||
11. Author's Address
|
||||
|
||||
Lyndon Nerenberg
|
||||
Orthanc Systems
|
||||
1606 - 10770 Winterburn Road
|
||||
Edmonton, Alberta
|
||||
Canada T5S 1T6
|
||||
|
||||
EMail: lyndon@orthanc.ab.ca
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Nerenberg Standards Track [Page 7]
|
||||
|
||||
RFC 3516 IMAP4 Binary Content Extension April 2003
|
||||
|
||||
|
||||
12. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
||||
|
||||
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.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
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.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Nerenberg Standards Track [Page 8]
|
||||
|
||||
1067
docs/rfc/rfc3656.txt
Normal file
1067
docs/rfc/rfc3656.txt
Normal file
File diff suppressed because it is too large
Load Diff
283
docs/rfc/rfc3691.txt
Normal file
283
docs/rfc/rfc3691.txt
Normal file
@ -0,0 +1,283 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group A. Melnikov
|
||||
Request for Comments: 3691 Isode Ltd.
|
||||
Category: Standards Track February 2004
|
||||
|
||||
|
||||
Internet Message Access Protocol (IMAP) UNSELECT command
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
This document defines an UNSELECT command that can be used to close
|
||||
the current mailbox in an Internet Message Access Protocol - version
|
||||
4 (IMAP4) session without expunging it. Certain types of IMAP
|
||||
clients need to release resources associated with the selected
|
||||
mailbox without selecting a different mailbox. While IMAP4 provides
|
||||
this functionality (via a SELECT command with a nonexistent mailbox
|
||||
name or reselecting the same mailbox with EXAMINE command), a more
|
||||
clean solution is desirable.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||||
2. UNSELECT command . . . . . . . . . . . . . . . . . . . . . . . 2
|
||||
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 3
|
||||
4. Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 3
|
||||
6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
7. Normative References . . . . . . . . . . . . . . . . . . . . . 4
|
||||
8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 5
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 1]
|
||||
|
||||
RFC 3691 IMAP UNSELECT command February 2004
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Certain types of IMAP clients need to release resources associated
|
||||
with the selected mailbox without selecting a different mailbox.
|
||||
While [IMAP4] provides this functionality (via a SELECT command with
|
||||
a nonexistent mailbox name or reselecting the same mailbox with
|
||||
EXAMINE command), a more clean solution is desirable.
|
||||
|
||||
[IMAP4] defines the CLOSE command that closes the selected mailbox as
|
||||
well as permanently removes all messages with the \Deleted flag set.
|
||||
|
||||
However [IMAP4] lacks a command that simply closes the mailbox
|
||||
without expunging it. This document defines the UNSELECT command for
|
||||
this purpose.
|
||||
|
||||
A server which supports this extension indicates this with a
|
||||
capability name of "UNSELECT".
|
||||
|
||||
"C:" and "S:" in examples show lines sent by the client and server
|
||||
respectively.
|
||||
|
||||
The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
|
||||
this document when typed in uppercase are to be interpreted as
|
||||
defined in "Key words for use in RFCs to Indicate Requirement Levels"
|
||||
[KEYWORDS].
|
||||
|
||||
2. UNSELECT Command
|
||||
|
||||
Arguments: none
|
||||
|
||||
Responses: no specific responses for this command
|
||||
|
||||
Result: OK - unselect completed, now in authenticated state
|
||||
BAD - no mailbox selected, or argument supplied but
|
||||
none permitted
|
||||
|
||||
The UNSELECT command frees server's resources associated with the
|
||||
selected mailbox and returns the server to the authenticated
|
||||
state. This command performs the same actions as CLOSE, except
|
||||
that no messages are permanently removed from the currently
|
||||
selected mailbox.
|
||||
|
||||
Example: C: A341 UNSELECT
|
||||
S: A341 OK Unselect completed
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 2]
|
||||
|
||||
RFC 3691 IMAP UNSELECT command February 2004
|
||||
|
||||
|
||||
3. Security Considerations
|
||||
|
||||
It is believed that this extension doesn't raise any additional
|
||||
security concerns not already discussed in [IMAP4].
|
||||
|
||||
4. Formal Syntax
|
||||
|
||||
The following syntax specification uses the Augmented Backus-Naur
|
||||
Form (ABNF) notation as specified in [ABNF]. Non-terminals
|
||||
referenced but not defined below are as defined by [IMAP4].
|
||||
|
||||
Except as noted otherwise, all alphabetic characters are case-
|
||||
insensitive. The use of upper or lower case characters to define
|
||||
token strings is for editorial clarity only. Implementations MUST
|
||||
accept these strings in a case-insensitive fashion.
|
||||
|
||||
command-select /= "UNSELECT"
|
||||
|
||||
5. IANA Considerations
|
||||
|
||||
IMAP4 capabilities are registered by publishing a standards track or
|
||||
IESG approved experimental RFC. The registry is currently located
|
||||
at:
|
||||
|
||||
http://www.iana.org/assignments/imap4-capabilities
|
||||
|
||||
This document defines the UNSELECT IMAP capabilities. IANA has added
|
||||
this capability to the registry.
|
||||
|
||||
6. Acknowledgments
|
||||
|
||||
UNSELECT command was originally implemented by Tim Showalter in Cyrus
|
||||
IMAP server.
|
||||
|
||||
Also, the author of the document would like to thank Vladimir Butenko
|
||||
and Mark Crispin for reminding that UNSELECT has to be documented.
|
||||
Also thanks to Simon Josefsson for pointing out that there are
|
||||
multiple ways to implement UNSELECT.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 3]
|
||||
|
||||
RFC 3691 IMAP UNSELECT command February 2004
|
||||
|
||||
|
||||
7. Normative References
|
||||
|
||||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
|
||||
4rev1", RFC 3501, March 2003.
|
||||
|
||||
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 2234, November 1997.
|
||||
|
||||
8. Author's Address
|
||||
|
||||
Alexey Melnikov
|
||||
Isode Limited
|
||||
5 Castle Business Village
|
||||
Hampton, Middlesex TW12 2BX
|
||||
|
||||
EMail: Alexey.Melnikov@isode.com
|
||||
URI: http://www.melnikov.ca/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 4]
|
||||
|
||||
RFC 3691 IMAP UNSELECT command February 2004
|
||||
|
||||
|
||||
9. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2004). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78 and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
|
||||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
|
||||
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed
|
||||
to pertain to the implementation or use of the technology
|
||||
described in this document or the extent to which any license
|
||||
under such rights might or might not be available; nor does it
|
||||
represent that it has made any independent effort to identify any
|
||||
such rights. Information on the procedures with respect to
|
||||
rights in RFC documents can be found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use
|
||||
of such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository
|
||||
at http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention
|
||||
any copyrights, patents or patent applications, or other
|
||||
proprietary rights that may cover technology that may be required
|
||||
to implement this standard. Please address the information to the
|
||||
IETF at ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 5]
|
||||
|
||||
1515
docs/rfc/rfc4314.txt
Normal file
1515
docs/rfc/rfc4314.txt
Normal file
File diff suppressed because it is too large
Load Diff
451
docs/rfc/rfc4315.txt
Normal file
451
docs/rfc/rfc4315.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Crispin
|
||||
Request for Comments: 4315 December 2005
|
||||
Obsoletes: 2359
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Internet Message Access Protocol (IMAP) - UIDPLUS extension
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2005).
|
||||
|
||||
Abstract
|
||||
|
||||
The UIDPLUS extension of the Internet Message Access Protocol (IMAP)
|
||||
provides a set of features intended to reduce the amount of time and
|
||||
resources used by some client operations. The features in UIDPLUS
|
||||
are primarily intended for disconnected-use clients.
|
||||
|
||||
1. Introduction and Overview
|
||||
|
||||
The UIDPLUS extension is present in any IMAP server implementation
|
||||
that returns "UIDPLUS" as one of the supported capabilities to the
|
||||
CAPABILITY command.
|
||||
|
||||
The UIDPLUS extension defines an additional command. In addition,
|
||||
this document recommends new status response codes in IMAP that
|
||||
SHOULD be returned by all server implementations, regardless of
|
||||
whether or not the UIDPLUS extension is implemented.
|
||||
|
||||
The added facilities of the features in UIDPLUS are optimizations;
|
||||
clients can provide equivalent functionality, albeit less
|
||||
efficiently, by using facilities in the base protocol.
|
||||
|
||||
1.1. Conventions Used in This Document
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server, respectively.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 1]
|
||||
|
||||
RFC 4315 IMAP - UIDPLUS Extension December 2005
|
||||
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
|
||||
be interpreted as described in [KEYWORDS].
|
||||
|
||||
A "UID set" is similar to the [IMAP] sequence set; however, the "*"
|
||||
value for a sequence number is not permitted.
|
||||
|
||||
2. Additional Commands
|
||||
|
||||
The following command definition is an extension to [IMAP] section
|
||||
6.4.
|
||||
|
||||
2.1. UID EXPUNGE Command
|
||||
|
||||
Arguments: sequence set
|
||||
|
||||
Data: untagged responses: EXPUNGE
|
||||
|
||||
Result: OK - expunge completed
|
||||
NO - expunge failure (e.g., permission denied)
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The UID EXPUNGE command permanently removes all messages that both
|
||||
have the \Deleted flag set and have a UID that is included in the
|
||||
specified sequence set from the currently selected mailbox. If a
|
||||
message either does not have the \Deleted flag set or has a UID
|
||||
that is not included in the specified sequence set, it is not
|
||||
affected.
|
||||
|
||||
This command is particularly useful for disconnected use clients.
|
||||
By using UID EXPUNGE instead of EXPUNGE when resynchronizing with
|
||||
the server, the client can ensure that it does not inadvertantly
|
||||
remove any messages that have been marked as \Deleted by other
|
||||
clients between the time that the client was last connected and
|
||||
the time the client resynchronizes.
|
||||
|
||||
If the server does not support the UIDPLUS capability, the client
|
||||
should fall back to using the STORE command to temporarily remove
|
||||
the \Deleted flag from messages it does not want to remove, then
|
||||
issuing the EXPUNGE command. Finally, the client should use the
|
||||
STORE command to restore the \Deleted flag on the messages in
|
||||
which it was temporarily removed.
|
||||
|
||||
Alternatively, the client may fall back to using just the EXPUNGE
|
||||
command, risking the unintended removal of some messages.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 2]
|
||||
|
||||
RFC 4315 IMAP - UIDPLUS Extension December 2005
|
||||
|
||||
|
||||
Example: C: A003 UID EXPUNGE 3000:3002
|
||||
S: * 3 EXPUNGE
|
||||
S: * 3 EXPUNGE
|
||||
S: * 3 EXPUNGE
|
||||
S: A003 OK UID EXPUNGE completed
|
||||
|
||||
3. Additional Response Codes
|
||||
|
||||
The following response codes are extensions to the response codes
|
||||
defined in [IMAP] section 7.1. With limited exceptions, discussed
|
||||
below, server implementations that advertise the UIDPLUS extension
|
||||
SHOULD return these response codes.
|
||||
|
||||
In the case of a mailbox that has permissions set so that the client
|
||||
can COPY or APPEND to the mailbox, but not SELECT or EXAMINE it, the
|
||||
server SHOULD NOT send an APPENDUID or COPYUID response code as it
|
||||
would disclose information about the mailbox.
|
||||
|
||||
In the case of a mailbox that has UIDNOTSTICKY status (as defined
|
||||
below), the server MAY omit the APPENDUID or COPYUID response code as
|
||||
it is not meaningful.
|
||||
|
||||
If the server does not return the APPENDUID or COPYUID response
|
||||
codes, the client can discover this information by selecting the
|
||||
destination mailbox. The location of messages placed in the
|
||||
destination mailbox by COPY or APPEND can be determined by using
|
||||
FETCH and/or SEARCH commands (e.g., for Message-ID or some unique
|
||||
marker placed in the message in an APPEND).
|
||||
|
||||
APPENDUID
|
||||
|
||||
Followed by the UIDVALIDITY of the destination mailbox and the UID
|
||||
assigned to the appended message in the destination mailbox,
|
||||
indicates that the message has been appended to the destination
|
||||
mailbox with that UID.
|
||||
|
||||
If the server also supports the [MULTIAPPEND] extension, and if
|
||||
multiple messages were appended in the APPEND command, then the
|
||||
second value is a UID set containing the UIDs assigned to the
|
||||
appended messages, in the order they were transmitted in the
|
||||
APPEND command. This UID set may not contain extraneous UIDs or
|
||||
the symbol "*".
|
||||
|
||||
Note: the UID set form of the APPENDUID response code MUST NOT
|
||||
be used if only a single message was appended. In particular,
|
||||
a server MUST NOT send a range such as 123:123. This is
|
||||
because a client that does not support [MULTIAPPEND] expects
|
||||
only a single UID and not a UID set.
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 3]
|
||||
|
||||
RFC 4315 IMAP - UIDPLUS Extension December 2005
|
||||
|
||||
|
||||
UIDs are assigned in strictly ascending order in the mailbox
|
||||
(refer to [IMAP], section 2.3.1.1) and UID ranges are as in
|
||||
[IMAP]; in particular, note that a range of 12:10 is exactly
|
||||
equivalent to 10:12 and refers to the sequence 10,11,12.
|
||||
|
||||
This response code is returned in a tagged OK response to the
|
||||
APPEND command.
|
||||
|
||||
COPYUID
|
||||
|
||||
Followed by the UIDVALIDITY of the destination mailbox, a UID set
|
||||
containing the UIDs of the message(s) in the source mailbox that
|
||||
were copied to the destination mailbox and containing the UIDs
|
||||
assigned to the copied message(s) in the destination mailbox,
|
||||
indicates that the message(s) have been copied to the destination
|
||||
mailbox with the stated UID(s).
|
||||
|
||||
The source UID set is in the order the message(s) were copied; the
|
||||
destination UID set corresponds to the source UID set and is in
|
||||
the same order. Neither of the UID sets may contain extraneous
|
||||
UIDs or the symbol "*".
|
||||
|
||||
UIDs are assigned in strictly ascending order in the mailbox
|
||||
(refer to [IMAP], section 2.3.1.1) and UID ranges are as in
|
||||
[IMAP]; in particular, note that a range of 12:10 is exactly
|
||||
equivalent to 10:12 and refers to the sequence 10,11,12.
|
||||
|
||||
This response code is returned in a tagged OK response to the COPY
|
||||
command.
|
||||
|
||||
UIDNOTSTICKY
|
||||
|
||||
The selected mailbox is supported by a mail store that does not
|
||||
support persistent UIDs; that is, UIDVALIDITY will be different
|
||||
each time the mailbox is selected. Consequently, APPEND or COPY
|
||||
to this mailbox will not return an APPENDUID or COPYUID response
|
||||
code.
|
||||
|
||||
This response code is returned in an untagged NO response to the
|
||||
SELECT command.
|
||||
|
||||
Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores.
|
||||
This facility exists to support legacy mail stores in which it
|
||||
is technically infeasible to support persistent UIDs. This
|
||||
should be avoided when designing new mail stores.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 4]
|
||||
|
||||
RFC 4315 IMAP - UIDPLUS Extension December 2005
|
||||
|
||||
|
||||
Example: C: A003 APPEND saved-messages (\Seen) {297}
|
||||
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
|
||||
C: From: Fred Foobar <foobar@example.com>
|
||||
C: Subject: afternoon meeting
|
||||
C: To: mooch@example.com
|
||||
C: Message-Id: <B27397-0100000@example.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 [APPENDUID 38505 3955] APPEND completed
|
||||
C: A004 COPY 2:4 meeting
|
||||
S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done
|
||||
C: A005 UID COPY 305:310 meeting
|
||||
S: A005 OK No matching messages, so nothing copied
|
||||
C: A006 COPY 2 funny
|
||||
S: A006 OK Done
|
||||
C: A007 SELECT funny
|
||||
S: * 1 EXISTS
|
||||
S: * 1 RECENT
|
||||
S: * OK [UNSEEN 1] Message 1 is first unseen
|
||||
S: * OK [UIDVALIDITY 3857529045] Validity session-only
|
||||
S: * OK [UIDNEXT 2] Predicted next UID
|
||||
S: * NO [UIDNOTSTICKY] Non-persistent UIDs
|
||||
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
|
||||
S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited
|
||||
S: A007 OK [READ-WRITE] SELECT completed
|
||||
|
||||
In this example, A003 and A004 demonstrate successful appending and
|
||||
copying to a mailbox that returns the UIDs assigned to the messages.
|
||||
A005 is an example in which no messages were copied; this is because
|
||||
in A003, we see that message 2 had UID 304, and message 3 had UID
|
||||
319; therefore, UIDs 305 through 310 do not exist (refer to section
|
||||
2.3.1.1 of [IMAP] for further explanation). A006 is an example of a
|
||||
message being copied that did not return a COPYUID; and, as expected,
|
||||
A007 shows that the mail store containing that mailbox does not
|
||||
support persistent UIDs.
|
||||
|
||||
4. Formal Syntax
|
||||
|
||||
Formal syntax is defined using ABNF [ABNF], which extends the ABNF
|
||||
rules defined in [IMAP]. The IMAP4 ABNF should be imported before
|
||||
attempting to validate these rules.
|
||||
|
||||
append-uid = uniqueid
|
||||
|
||||
capability =/ "UIDPLUS"
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 5]
|
||||
|
||||
RFC 4315 IMAP - UIDPLUS Extension December 2005
|
||||
|
||||
|
||||
command-select =/ uid-expunge
|
||||
|
||||
resp-code-apnd = "APPENDUID" SP nz-number SP append-uid
|
||||
|
||||
resp-code-copy = "COPYUID" SP nz-number SP uid-set SP uid-set
|
||||
|
||||
resp-text-code =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY"
|
||||
; incorporated before the expansion rule of
|
||||
; atom [SP 1*<any TEXT-CHAR except "]">]
|
||||
; that appears in [IMAP]
|
||||
|
||||
uid-expunge = "UID" SP "EXPUNGE" SP sequence-set
|
||||
|
||||
uid-set = (uniqueid / uid-range) *("," uid-set)
|
||||
|
||||
uid-range = (uniqueid ":" uniqueid)
|
||||
; two uniqueid values and all values
|
||||
; between these two regards of order.
|
||||
; Example: 2:4 and 4:2 are equivalent.
|
||||
|
||||
Servers that support [MULTIAPPEND] will have the following extension
|
||||
to the above rules:
|
||||
|
||||
append-uid =/ uid-set
|
||||
; only permitted if client uses [MULTIAPPEND]
|
||||
; to append multiple messages.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
The COPYUID and APPENDUID response codes return information about the
|
||||
mailbox, which may be considered sensitive if the mailbox has
|
||||
permissions set that permit the client to COPY or APPEND to the
|
||||
mailbox, but not SELECT or EXAMINE it.
|
||||
|
||||
Consequently, these response codes SHOULD NOT be issued if the client
|
||||
does not have access to SELECT or EXAMINE the mailbox.
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
This document constitutes registration of the UIDPLUS capability in
|
||||
the imap4-capabilities registry, replacing [RFC2359].
|
||||
|
||||
7. Normative References
|
||||
|
||||
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 6]
|
||||
|
||||
RFC 4315 IMAP - UIDPLUS Extension December 2005
|
||||
|
||||
|
||||
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
|
||||
VERSION 4rev1", RFC 3501, March 2003.
|
||||
|
||||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
|
||||
MULTIAPPEND Extension", RFC 3502, March 2003.
|
||||
|
||||
8. Informative References
|
||||
|
||||
[RFC2359] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June
|
||||
1998.
|
||||
|
||||
9. Changes from RFC 2359
|
||||
|
||||
This document obsoletes [RFC2359]. However, it is based upon that
|
||||
document, and takes substantial text from it (albeit with numerous
|
||||
clarifications in wording).
|
||||
|
||||
[RFC2359] implied that a server must always return COPYUID/APPENDUID
|
||||
data; thus suggesting that in such cases the server should return
|
||||
arbitrary data if the destination mailbox did not support persistent
|
||||
UIDs. This document adds the UIDNOTSTICKY response code to indicate
|
||||
that a mailbox does not support persistent UIDs, and stipulates that
|
||||
a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY
|
||||
(or APPEND) destination mailbox has UIDNOTSTICKY status.
|
||||
|
||||
Author's Address
|
||||
|
||||
Mark R. Crispin
|
||||
Networks and Distributed Computing
|
||||
University of Washington
|
||||
4545 15th Avenue NE
|
||||
Seattle, WA 98105-4527
|
||||
|
||||
Phone: (206) 543-5762
|
||||
EMail: MRC@CAC.Washington.EDU
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 7]
|
||||
|
||||
RFC 4315 IMAP - UIDPLUS Extension December 2005
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2005).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at ietf-
|
||||
ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 8]
|
||||
|
||||
1851
docs/rfc/rfc4422.txt
Normal file
1851
docs/rfc/rfc4422.txt
Normal file
File diff suppressed because it is too large
Load Diff
955
docs/rfc/rfc4466.txt
Normal file
955
docs/rfc/rfc4466.txt
Normal file
@ -0,0 +1,955 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group A. Melnikov
|
||||
Request for Comments: 4466 Isode Ltd.
|
||||
Updates: 2088, 2342, 3501, 3502, 3516 C. Daboo
|
||||
Category: Standards Track April 2006
|
||||
|
||||
|
||||
Collected Extensions to IMAP4 ABNF
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
Over the years, many documents from IMAPEXT and LEMONADE working
|
||||
groups, as well as many individual documents, have added syntactic
|
||||
extensions to many base IMAP commands described in RFC 3501. For
|
||||
ease of reference, this document collects most of such ABNF changes
|
||||
in one place.
|
||||
|
||||
This document also suggests a set of standard patterns for adding
|
||||
options and extensions to several existing IMAP commands defined in
|
||||
RFC 3501. The patterns provide for compatibility between existing
|
||||
and future extensions.
|
||||
|
||||
This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
|
||||
It also includes part of the errata to RFC 3501. This document
|
||||
doesn't specify any semantic changes to the listed RFCs.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 1]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
1.1. Purpose of This Document ...................................2
|
||||
1.2. Conventions Used in This Document ..........................3
|
||||
2. IMAP ABNF Extensions ............................................3
|
||||
2.1. Optional Parameters with the SELECT/EXAMINE Commands .......3
|
||||
2.2. Extended CREATE Command ....................................4
|
||||
2.3. Extended RENAME Command ....................................5
|
||||
2.4. Extensions to FETCH and UID FETCH Commands .................6
|
||||
2.5. Extensions to STORE and UID STORE Commands .................6
|
||||
2.6. Extensions to SEARCH Command ...............................7
|
||||
2.6.1. Extended SEARCH Command .............................7
|
||||
2.6.2. ESEARCH untagged response ...........................8
|
||||
2.7. Extensions to APPEND Command ...............................8
|
||||
3. Formal Syntax ...................................................9
|
||||
4. Security Considerations ........................................14
|
||||
5. Normative References ...........................................15
|
||||
6. Acknowledgements ...............................................15
|
||||
|
||||
1. Introduction
|
||||
|
||||
1.1. Purpose of This Document
|
||||
|
||||
This document serves several purposes:
|
||||
|
||||
1. rationalize and generalize ABNF for some existing IMAP
|
||||
extensions;
|
||||
2. collect the ABNF in one place in order to minimize cross
|
||||
references between documents;
|
||||
3. define building blocks for future extensions so that they can
|
||||
be used together in a compatible way.
|
||||
|
||||
It is expected that a future revision of this document will be
|
||||
incorporated into a revision of RFC 3501.
|
||||
|
||||
This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
|
||||
It also includes part of the errata to RFC 3501. This document
|
||||
doesn't specify any semantic changes to the listed RFCs.
|
||||
|
||||
The ABNF in section 6 of RFC 2342 got rewritten to conform to the
|
||||
ABNF syntax as defined in RFC 4234 and to reference new non-terminals
|
||||
from RFC 3501. It was also restructured to allow for better
|
||||
readability. There were no changes "on the wire".
|
||||
|
||||
Section 2 extends ABNF for SELECT, EXAMINE, CREATE, RENAME, FETCH/UID
|
||||
FETCH, STORE/UID STORE, SEARCH, and APPEND commands in a consistent
|
||||
manner. Extensions to all the commands but APPEND have the same
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 2]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
structure. Extensibility for the APPEND command was done slightly
|
||||
differently in order to preserve backward compatibility with existing
|
||||
extensions.
|
||||
|
||||
Section 2 also defines a new ESEARCH response, whose purpose is to
|
||||
define a better version of the SEARCH response defined in RFC 3501.
|
||||
|
||||
Section 3 defines the collected ABNF that replaces pieces of ABNF in
|
||||
the aforementioned RFCs. The collected ABNF got generalized to allow
|
||||
for easier future extensibility.
|
||||
|
||||
1.2. Conventions Used in This Document
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server, respectively.
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
|
||||
in this document are to be interpreted as defined in "Key words for
|
||||
use in RFCs to Indicate Requirement Levels" [KEYWORDS].
|
||||
|
||||
2. IMAP ABNF Extensions
|
||||
|
||||
This section is not normative. It provides some background on the
|
||||
intended use of different extensions and it gives some guidance about
|
||||
how future extensions should extend the described commands.
|
||||
|
||||
2.1. Optional Parameters with the SELECT/EXAMINE Commands
|
||||
|
||||
This document adds the ability to include one or more parameters with
|
||||
the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section 6.3.2
|
||||
of [IMAP4]) commands, to turn on or off certain standard behaviors,
|
||||
or to add new optional behaviors required for a particular extension.
|
||||
|
||||
There are two possible modes of operation:
|
||||
|
||||
o A global state change where a single use of the optional parameter
|
||||
will affect the session state from that time on, irrespective of
|
||||
subsequent SELECT/EXAMINE commands.
|
||||
|
||||
o A per-mailbox state change that will affect the session only for
|
||||
the duration of the new selected state. A subsequent
|
||||
SELECT/EXAMINE without the optional parameter will cancel its
|
||||
effect for the newly selected mailbox.
|
||||
|
||||
Optional parameters to the SELECT or EXAMINE commands are added as a
|
||||
parenthesized list of attribute/value pairs, and appear after the
|
||||
mailbox name in the standard SELECT or EXAMINE command. The order of
|
||||
individual parameters is arbitrary. A parameter value is optional
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 3]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
and may consist of atoms, strings, or lists in a specific order. If
|
||||
the parameter value is present, it always appears in parentheses (*).
|
||||
Any parameter not defined by extensions that the server supports must
|
||||
be rejected with a BAD response.
|
||||
|
||||
Example:
|
||||
|
||||
C: a SELECT INBOX (ANNOTATE)
|
||||
S: ...
|
||||
S: a OK SELECT complete
|
||||
|
||||
In the above example, a single parameter is used with the SELECT
|
||||
command.
|
||||
|
||||
Example:
|
||||
|
||||
C: a EXAMINE INBOX (ANNOTATE RESPONSES ("UID Responses")
|
||||
CONDSTORE)
|
||||
S: ...
|
||||
S: a OK EXAMINE complete
|
||||
|
||||
In the above example, three parameters are used with the EXAMINE
|
||||
command. The second parameter consists of two items: an atom
|
||||
"RESPONSES" followed by a quoted string.
|
||||
|
||||
Example:
|
||||
|
||||
C: a SELECT INBOX (BLURDYBLOOP)
|
||||
S: a BAD Unknown parameter in SELECT command
|
||||
|
||||
In the above example, a parameter not supported by the server is
|
||||
used. This results in the BAD response from the server.
|
||||
|
||||
(*) - if a parameter has a mandatory value, which can always be
|
||||
represented as a number or a sequence-set, the parameter value does
|
||||
not need the enclosing (). See ABNF for more details.
|
||||
|
||||
2.2. Extended CREATE Command
|
||||
|
||||
Arguments: mailbox name
|
||||
OPTIONAL list of CREATE parameters
|
||||
|
||||
Responses: no specific responses for this command
|
||||
|
||||
Result: OK - create completed
|
||||
NO - create failure: cannot create mailbox with
|
||||
that name
|
||||
BAD - argument(s) invalid
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 4]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
This document adds the ability to include one or more parameters with
|
||||
the IMAP CREATE command (see section 6.3.3 of [IMAP4]), to turn on or
|
||||
off certain standard behaviors, or to add new optional behaviors
|
||||
required for a particular extension. No CREATE parameters are
|
||||
defined in this document.
|
||||
|
||||
Optional parameters to the CREATE command are added as a
|
||||
parenthesized list of attribute/value pairs after the mailbox name.
|
||||
The order of individual parameters is arbitrary. A parameter value
|
||||
is optional and may consist of atoms, strings, or lists in a specific
|
||||
order. If the parameter value is present, it always appears in
|
||||
parentheses (*). Any parameter not defined by extensions that the
|
||||
server supports must be rejected with a BAD response.
|
||||
|
||||
(*) - if a parameter has a mandatory value, which can always be
|
||||
represented as a number or a sequence-set, the parameter value does
|
||||
not need the enclosing (). See ABNF for more details.
|
||||
|
||||
2.3. Extended RENAME Command
|
||||
|
||||
Arguments: existing mailbox name
|
||||
new mailbox name
|
||||
OPTIONAL list of RENAME parameters
|
||||
|
||||
Responses: no specific responses for this command
|
||||
|
||||
Result: OK - rename completed
|
||||
NO - rename failure: cannot rename mailbox with
|
||||
that name, cannot rename to mailbox with
|
||||
that name, etc.
|
||||
BAD - argument(s) invalid
|
||||
|
||||
This document adds the ability to include one or more parameters with
|
||||
the IMAP RENAME command (see section 6.3.5 of [IMAP4]), to turn on or
|
||||
off certain standard behaviors, or to add new optional behaviors
|
||||
required for a particular extension. No RENAME parameters are
|
||||
defined in this document.
|
||||
|
||||
Optional parameters to the RENAME command are added as a
|
||||
parenthesized list of attribute/value pairs after the new mailbox
|
||||
name. The order of individual parameters is arbitrary. A parameter
|
||||
value is optional and may consist of atoms, strings, or lists in a
|
||||
specific order. If the parameter value is present, it always appears
|
||||
in parentheses (*). Any parameter not defined by extensions that the
|
||||
server supports must be rejected with a BAD response.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 5]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
(*) - if a parameter has a mandatory value, which can always be
|
||||
represented as a number or a sequence-set, the parameter value does
|
||||
not need the enclosing (). See ABNF for more details.
|
||||
|
||||
2.4. Extensions to FETCH and UID FETCH Commands
|
||||
|
||||
Arguments: sequence set
|
||||
message data item names or macro
|
||||
OPTIONAL fetch modifiers
|
||||
|
||||
Responses: untagged responses: FETCH
|
||||
|
||||
Result: OK - fetch completed
|
||||
NO - fetch error: cannot fetch that data
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
This document extends the syntax of the FETCH and UID FETCH commands
|
||||
(see section 6.4.5 of [IMAP4]) to include optional FETCH modifiers.
|
||||
No fetch modifiers are defined in this document.
|
||||
|
||||
The order of individual modifiers is arbitrary. Each modifier is an
|
||||
attribute/value pair. A modifier value is optional and may consist
|
||||
of atoms and/or strings and/or lists in a specific order. If the
|
||||
modifier value is present, it always appears in parentheses (*). Any
|
||||
modifiers not defined by extensions that the server supports must be
|
||||
rejected with a BAD response.
|
||||
|
||||
(*) - if a modifier has a mandatory value, which can always be
|
||||
represented as a number or a sequence-set, the modifier value does
|
||||
not need the enclosing (). See ABNF for more details.
|
||||
|
||||
2.5. Extensions to STORE and UID STORE Commands
|
||||
|
||||
Arguments: message set
|
||||
OPTIONAL store modifiers
|
||||
message data item name
|
||||
value for message data item
|
||||
|
||||
Responses: untagged responses: FETCH
|
||||
|
||||
Result: OK - store completed
|
||||
NO - store error: cannot store that data
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
This document extends the syntax of the STORE and UID STORE commands
|
||||
(see section 6.4.6 of [IMAP4]) to include optional STORE modifiers.
|
||||
No store modifiers are defined in this document.
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 6]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
The order of individual modifiers is arbitrary. Each modifier is an
|
||||
attribute/value pair. A modifier value is optional and may consist
|
||||
of atoms and/or strings and/or lists in a specific order. If the
|
||||
modifier value is present, it always appears in parentheses (*). Any
|
||||
modifiers not defined by extensions that the server supports must be
|
||||
rejected with a BAD response.
|
||||
|
||||
(*) - if a modifier has a mandatory value, which can always be
|
||||
represented as a number or a sequence-set, the modifier value does
|
||||
not need the enclosing (). See ABNF for more details.
|
||||
|
||||
2.6. Extensions to SEARCH Command
|
||||
|
||||
2.6.1. Extended SEARCH Command
|
||||
|
||||
Arguments: OPTIONAL result specifier
|
||||
OPTIONAL [CHARSET] specification
|
||||
searching criteria (one or more)
|
||||
|
||||
Responses: REQUIRED untagged response: SEARCH (*)
|
||||
|
||||
Result: OK - search completed
|
||||
NO - search error: cannot search that [CHARSET] or
|
||||
criteria
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
This section updates definition of the SEARCH command described in
|
||||
section 6.4.4 of [IMAP4].
|
||||
|
||||
The SEARCH command is extended to allow for result options. This
|
||||
document does not define any result options.
|
||||
|
||||
The order of individual options is arbitrary. Individual options may
|
||||
contain parameters enclosed in parentheses (**). If an option has
|
||||
parameters, they consist of atoms and/or strings and/or lists in a
|
||||
specific order. Any options not defined by extensions that the
|
||||
server supports must be rejected with a BAD response.
|
||||
|
||||
(*) - An extension to the SEARCH command may require another untagged
|
||||
response, or no untagged response to be returned. Section 2.6.2
|
||||
defines a new ESEARCH untagged response that replaces the SEARCH
|
||||
untagged response. Note that for a given extended SEARCH command the
|
||||
SEARCH and ESEARCH responses SHOULD be mutually exclusive, i.e., only
|
||||
one of them should be returned.
|
||||
|
||||
(**) - if an option has a mandatory parameter, which can always be
|
||||
represented as a number or a sequence-set, the option parameter does
|
||||
not need the enclosing (). See ABNF for more details.
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 7]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
2.6.2. ESEARCH untagged response
|
||||
|
||||
Contents: one or more search-return-data pairs
|
||||
|
||||
The ESEARCH response SHOULD be sent as a result of an extended SEARCH
|
||||
or UID SEARCH command specified in section 2.6.1.
|
||||
|
||||
The ESEARCH response starts with an optional search correlator. If
|
||||
it is missing, then the response was not caused by a particular IMAP
|
||||
command, whereas if it is present, it contains the tag of the command
|
||||
that caused the response to be returned.
|
||||
|
||||
The search correlator is followed by an optional UID indicator. If
|
||||
this indicator is present, all data in the ESEARCH response refers to
|
||||
UIDs, otherwise all returned data refers to message numbers.
|
||||
|
||||
The rest of the ESEARCH response contains one or more search data
|
||||
pairs. Each pair starts with unique return item name, followed by a
|
||||
space and the corresponding data. Search data pairs may be returned
|
||||
in any order. Unless specified otherwise by an extension, any return
|
||||
item name SHOULD appear only once in an ESEARCH response.
|
||||
|
||||
Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
|
||||
|
||||
Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
|
||||
|
||||
Example: S: * ESEARCH COUNT 5 ALL 1:17,21
|
||||
|
||||
2.7. Extensions to APPEND Command
|
||||
|
||||
The IMAP BINARY extension [BINARY] extends the APPEND command to
|
||||
allow a client to append data containing NULs by using the <literal8>
|
||||
syntax. The ABNF was rewritten to allow for easier extensibility by
|
||||
IMAP extensions. This document hasn't specified any semantical
|
||||
changes to the [BINARY] extension.
|
||||
|
||||
In addition, the non-terminal "literal8" defined in [BINARY] got
|
||||
extended to allow for non-synchronizing literals if both [BINARY] and
|
||||
[LITERAL+] extensions are supported by the server.
|
||||
|
||||
The IMAP MULTIAPPEND extension [MULTIAPPEND] extends the APPEND
|
||||
command to allow a client to append multiple messages atomically.
|
||||
This document defines a common syntax for the APPEND command that
|
||||
takes into consideration syntactic extensions defined by both
|
||||
[BINARY] and [MULTIAPPEND] extensions.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 8]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
3. Formal Syntax
|
||||
|
||||
The following syntax specification uses the Augmented Backus-Naur
|
||||
Form (ABNF) notation as specified in [ABNF].
|
||||
|
||||
Non-terminals referenced but not defined below are as defined by
|
||||
[IMAP4].
|
||||
|
||||
Except as noted otherwise, all alphabetic characters are case-
|
||||
insensitive. The use of uppercase or lowercase characters to define
|
||||
token strings is for editorial clarity only. Implementations MUST
|
||||
accept these strings in a case-insensitive fashion.
|
||||
|
||||
append = "APPEND" SP mailbox 1*append-message
|
||||
;; only a single append-message may appear
|
||||
;; if MULTIAPPEND [MULTIAPPEND] capability
|
||||
;; is not present
|
||||
|
||||
append-message = append-opts SP append-data
|
||||
|
||||
append-ext = append-ext-name SP append-ext-value
|
||||
;; This non-terminal define extensions to
|
||||
;; to message metadata.
|
||||
|
||||
append-ext-name = tagged-ext-label
|
||||
|
||||
append-ext-value= tagged-ext-val
|
||||
;; This non-terminal shows recommended syntax
|
||||
;; for future extensions.
|
||||
|
||||
|
||||
append-data = literal / literal8 / append-data-ext
|
||||
|
||||
append-data-ext = tagged-ext
|
||||
;; This non-terminal shows recommended syntax
|
||||
;; for future extensions,
|
||||
;; i.e., a mandatory label followed
|
||||
;; by parameters.
|
||||
|
||||
append-opts = [SP flag-list] [SP date-time] *(SP append-ext)
|
||||
;; message metadata
|
||||
|
||||
charset = atom / quoted
|
||||
;; Exact syntax is defined in [CHARSET].
|
||||
|
||||
create = "CREATE" SP mailbox
|
||||
[create-params]
|
||||
;; Use of INBOX gives a NO error.
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 9]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
create-params = SP "(" create-param *( SP create-param) ")"
|
||||
|
||||
create-param-name = tagged-ext-label
|
||||
|
||||
create-param = create-param-name [SP create-param-value]
|
||||
|
||||
create-param-value= tagged-ext-val
|
||||
;; This non-terminal shows recommended syntax
|
||||
;; for future extensions.
|
||||
|
||||
|
||||
esearch-response = "ESEARCH" [search-correlator] [SP "UID"]
|
||||
*(SP search-return-data)
|
||||
;; Note that SEARCH and ESEARCH responses
|
||||
;; SHOULD be mutually exclusive,
|
||||
;; i.e., only one of the response types
|
||||
;; should be
|
||||
;; returned as a result of a command.
|
||||
|
||||
|
||||
examine = "EXAMINE" SP mailbox [select-params]
|
||||
;; modifies the original IMAP EXAMINE command
|
||||
;; to accept optional parameters
|
||||
|
||||
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
|
||||
"FAST" / fetch-att /
|
||||
"(" fetch-att *(SP fetch-att) ")")
|
||||
[fetch-modifiers]
|
||||
;; modifies the original IMAP4 FETCH command to
|
||||
;; accept optional modifiers
|
||||
|
||||
fetch-modifiers = SP "(" fetch-modifier *(SP fetch-modifier) ")"
|
||||
|
||||
fetch-modifier = fetch-modifier-name [ SP fetch-modif-params ]
|
||||
|
||||
fetch-modif-params = tagged-ext-val
|
||||
;; This non-terminal shows recommended syntax
|
||||
;; for future extensions.
|
||||
|
||||
fetch-modifier-name = tagged-ext-label
|
||||
|
||||
literal8 = "~{" number ["+"] "}" CRLF *OCTET
|
||||
;; A string that might contain NULs.
|
||||
;; <number> represents the number of OCTETs
|
||||
;; in the response string.
|
||||
;; The "+" is only allowed when both LITERAL+ and
|
||||
;; BINARY extensions are supported by the server.
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 10]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
mailbox-data =/ Namespace-Response /
|
||||
esearch-response
|
||||
|
||||
Namespace = nil / "(" 1*Namespace-Descr ")"
|
||||
|
||||
Namespace-Command = "NAMESPACE"
|
||||
|
||||
Namespace-Descr = "(" string SP
|
||||
(DQUOTE QUOTED-CHAR DQUOTE / nil)
|
||||
*(Namespace-Response-Extension) ")"
|
||||
|
||||
Namespace-Response-Extension = SP string SP
|
||||
"(" string *(SP string) ")"
|
||||
|
||||
Namespace-Response = "NAMESPACE" SP Namespace
|
||||
SP Namespace SP Namespace
|
||||
;; This response is currently only allowed
|
||||
;; if the IMAP server supports [NAMESPACE].
|
||||
;; The first Namespace is the Personal Namespace(s)
|
||||
;; The second Namespace is the Other Users' Namespace(s)
|
||||
;; The third Namespace is the Shared Namespace(s)
|
||||
|
||||
rename = "RENAME" SP mailbox SP mailbox
|
||||
[rename-params]
|
||||
;; Use of INBOX as a destination gives
|
||||
;; a NO error, unless rename-params
|
||||
;; is not empty.
|
||||
|
||||
rename-params = SP "(" rename-param *( SP rename-param) ")"
|
||||
|
||||
rename-param = rename-param-name [SP rename-param-value]
|
||||
|
||||
rename-param-name = tagged-ext-label
|
||||
|
||||
rename-param-value= tagged-ext-val
|
||||
;; This non-terminal shows recommended syntax
|
||||
;; for future extensions.
|
||||
|
||||
|
||||
response-data = "*" SP response-payload CRLF
|
||||
|
||||
response-payload= resp-cond-state / resp-cond-bye /
|
||||
mailbox-data / message-data / capability-data
|
||||
|
||||
search = "SEARCH" [search-return-opts]
|
||||
SP search-program
|
||||
|
||||
search-correlator = SP "(" "TAG" SP tag-string ")"
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 11]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
search-program = ["CHARSET" SP charset SP]
|
||||
search-key *(SP search-key)
|
||||
;; CHARSET argument to SEARCH MUST be
|
||||
;; registered with IANA.
|
||||
|
||||
search-return-data = search-modifier-name SP search-return-value
|
||||
;; Note that not every SEARCH return option
|
||||
;; is required to have the corresponding
|
||||
;; ESEARCH return data.
|
||||
|
||||
search-return-opts = SP "RETURN" SP "(" [search-return-opt
|
||||
*(SP search-return-opt)] ")"
|
||||
|
||||
search-return-opt = search-modifier-name [SP search-mod-params]
|
||||
|
||||
search-return-value = tagged-ext-val
|
||||
;; Data for the returned search option.
|
||||
;; A single "nz-number"/"number" value
|
||||
;; can be returned as an atom (i.e., without
|
||||
;; quoting). A sequence-set can be returned
|
||||
;; as an atom as well.
|
||||
|
||||
search-modifier-name = tagged-ext-label
|
||||
|
||||
search-mod-params = tagged-ext-val
|
||||
;; This non-terminal shows recommended syntax
|
||||
;; for future extensions.
|
||||
|
||||
|
||||
select = "SELECT" SP mailbox [select-params]
|
||||
;; modifies the original IMAP SELECT command to
|
||||
;; accept optional parameters
|
||||
|
||||
select-params = SP "(" select-param *(SP select-param) ")"
|
||||
|
||||
select-param = select-param-name [SP select-param-value]
|
||||
;; a parameter to SELECT may contain one or
|
||||
;; more atoms and/or strings and/or lists.
|
||||
|
||||
select-param-name= tagged-ext-label
|
||||
|
||||
select-param-value= tagged-ext-val
|
||||
;; This non-terminal shows recommended syntax
|
||||
;; for future extensions.
|
||||
|
||||
|
||||
status-att-list = status-att-val *(SP status-att-val)
|
||||
;; Redefines status-att-list from RFC 3501.
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 12]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
;; status-att-val is defined in RFC 3501 errata
|
||||
|
||||
status-att-val = ("MESSAGES" SP number) /
|
||||
("RECENT" SP number) /
|
||||
("UIDNEXT" SP nz-number) /
|
||||
("UIDVALIDITY" SP nz-number) /
|
||||
("UNSEEN" SP number)
|
||||
;; Extensions to the STATUS responses
|
||||
;; should extend this production.
|
||||
;; Extensions should use the generic
|
||||
;; syntax defined by tagged-ext.
|
||||
|
||||
store = "STORE" SP sequence-set [store-modifiers]
|
||||
SP store-att-flags
|
||||
;; extend [IMAP4] STORE command syntax
|
||||
;; to allow for optional store-modifiers
|
||||
|
||||
store-modifiers = SP "(" store-modifier *(SP store-modifier)
|
||||
")"
|
||||
|
||||
store-modifier = store-modifier-name [SP store-modif-params]
|
||||
|
||||
store-modif-params = tagged-ext-val
|
||||
;; This non-terminal shows recommended syntax
|
||||
;; for future extensions.
|
||||
|
||||
store-modifier-name = tagged-ext-label
|
||||
|
||||
tag-string = string
|
||||
;; tag of the command that caused
|
||||
;; the ESEARCH response, sent as
|
||||
;; a string.
|
||||
|
||||
tagged-ext = tagged-ext-label SP tagged-ext-val
|
||||
;; recommended overarching syntax for
|
||||
;; extensions
|
||||
|
||||
tagged-ext-label = tagged-label-fchar *tagged-label-char
|
||||
;; Is a valid RFC 3501 "atom".
|
||||
|
||||
tagged-label-fchar = ALPHA / "-" / "_" / "."
|
||||
|
||||
tagged-label-char = tagged-label-fchar / DIGIT / ":"
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 13]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
tagged-ext-comp = astring /
|
||||
tagged-ext-comp *(SP tagged-ext-comp) /
|
||||
"(" tagged-ext-comp ")"
|
||||
;; Extensions that follow this general
|
||||
;; syntax should use nstring instead of
|
||||
;; astring when appropriate in the context
|
||||
;; of the extension.
|
||||
;; Note that a message set or a "number"
|
||||
;; can always be represented as an "atom".
|
||||
;; An URL should be represented as
|
||||
;; a "quoted" string.
|
||||
|
||||
tagged-ext-simple = sequence-set / number
|
||||
|
||||
tagged-ext-val = tagged-ext-simple /
|
||||
"(" [tagged-ext-comp] ")"
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
|
||||
The updated documents must be consulted for security considerations
|
||||
for the extensions that they define.
|
||||
|
||||
As a protocol gets more complex, parser bugs become more common
|
||||
including buffer overflow, denial of service, and other common
|
||||
security coding errors. To the extent that this document makes the
|
||||
parser more complex, it makes this situation worse. To the extent
|
||||
that this document makes the parser more consistent and thus simpler,
|
||||
the situation is improved. The impact will depend on how many
|
||||
deployed IMAP extensions are consistent with this document.
|
||||
Implementers are encouraged to take care of these issues when
|
||||
extending existing implementations. Future IMAP extensions should
|
||||
strive for consistency and simplicity to the greatest extent
|
||||
possible.
|
||||
|
||||
Extensions to IMAP commands that are permitted in NOT AUTHENTICATED
|
||||
state are more sensitive to these security issues due to the larger
|
||||
possible attacker community prior to authentication, and the fact
|
||||
that some IMAP servers run with elevated privileges in that state.
|
||||
This document does not extend any commands permitted in NOT
|
||||
AUTHENTICATED state. Future IMAP extensions to commands permitted in
|
||||
NOT AUTHENTICATED state should favor simplicity over consistency or
|
||||
extensibility.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 14]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
5. Normative References
|
||||
|
||||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
|
||||
VERSION 4rev1", RFC 3501, March 2003.
|
||||
|
||||
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
|
||||
Syntax Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration
|
||||
Procedures", BCP 19, RFC 2978, October 2000.
|
||||
|
||||
[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
|
||||
MULTIAPPEND Extension", RFC 3502, March 2003.
|
||||
|
||||
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
|
||||
May 1998.
|
||||
|
||||
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC
|
||||
2088, January 1997.
|
||||
|
||||
[BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC
|
||||
3516, April 2003.
|
||||
|
||||
6. Acknowledgements
|
||||
|
||||
This documents is based on ideas proposed by Pete Resnick, Mark
|
||||
Crispin, Ken Murchison, Philip Guenther, Randall Gellens, and Lyndon
|
||||
Nerenberg.
|
||||
|
||||
However, all errors and omissions must be attributed to the authors
|
||||
of the document.
|
||||
|
||||
Thanks to Philip Guenther, Dave Cridland, Mark Crispin, Chris Newman,
|
||||
Elwyn Davies, and Barry Leiba for comments and corrections.
|
||||
|
||||
literal8 syntax was taken from RFC 3516.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 15]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Alexey Melnikov
|
||||
Isode Limited
|
||||
5 Castle Business Village
|
||||
36 Station Road
|
||||
Hampton, Middlesex, TW12 2BX
|
||||
UK
|
||||
|
||||
EMail: Alexey.Melnikov@isode.com
|
||||
|
||||
|
||||
Cyrus Daboo
|
||||
|
||||
EMail: cyrus@daboo.name
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 16]
|
||||
|
||||
RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Daboo Standards Track [Page 17]
|
||||
|
||||
1011
docs/rfc/rfc4467.txt
Normal file
1011
docs/rfc/rfc4467.txt
Normal file
File diff suppressed because it is too large
Load Diff
787
docs/rfc/rfc4468.txt
Normal file
787
docs/rfc/rfc4468.txt
Normal file
@ -0,0 +1,787 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group C. Newman
|
||||
Request for Comments: 4468 Sun Microsystems
|
||||
Updates: 3463 May 2006
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Message Submission BURL Extension
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
The submission profile of Simple Mail Transfer Protocol (SMTP)
|
||||
provides a standard way for an email client to submit a complete
|
||||
message for delivery. This specification extends the submission
|
||||
profile by adding a new BURL command that can be used to fetch
|
||||
submission data from an Internet Message Access Protocol (IMAP)
|
||||
server. This permits a mail client to inject content from an IMAP
|
||||
server into the SMTP infrastructure without downloading it to the
|
||||
client and uploading it back to the server.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 1]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. Conventions Used in This Document ...............................2
|
||||
3. BURL Submission Extension .......................................3
|
||||
3.1. SMTP Submission Extension Registration .....................3
|
||||
3.2. BURL Transaction ...........................................3
|
||||
3.3. The BURL IMAP Options ......................................4
|
||||
3.4. Examples ...................................................5
|
||||
3.5. Formal Syntax ..............................................6
|
||||
4. 8-Bit and Binary ................................................7
|
||||
5. Updates to RFC 3463 .............................................7
|
||||
6. Response Codes ..................................................7
|
||||
7. IANA Considerations .............................................9
|
||||
8. Security Considerations .........................................9
|
||||
9. References .....................................................11
|
||||
9.1. Normative References ......................................11
|
||||
9.2. Informative References ....................................12
|
||||
Appendix A. Acknowledgements .....................................13
|
||||
|
||||
1. Introduction
|
||||
|
||||
This specification defines an extension to the standard Message
|
||||
Submission [RFC4409] protocol to permit data to be fetched from an
|
||||
IMAP server at message submission time. This MAY be used in
|
||||
conjunction with the CHUNKING [RFC3030] mechanism so that chunks of
|
||||
the message can come from an external IMAP server. This provides the
|
||||
ability to forward an email message without first downloading it to
|
||||
the client.
|
||||
|
||||
2. Conventions Used in This Document
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
|
||||
in this document are to be interpreted as defined in "Key words for
|
||||
use in RFCs to Indicate Requirement Levels" [RFC2119].
|
||||
|
||||
The formal syntax uses the Augmented Backus-Naur Form (ABNF)
|
||||
[RFC4234] notation including the core rules defined in Appendix B of
|
||||
RFC 4234.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 2]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
3. BURL Submission Extension
|
||||
|
||||
This section defines the BURL submission extension.
|
||||
|
||||
3.1. SMTP Submission Extension Registration
|
||||
|
||||
1. The name of this submission extension is "BURL". This extends
|
||||
the Message Submission protocol on port 587 and MUST NOT be
|
||||
advertised by a regular SMTP [RFC2821] server on port 25 that
|
||||
acts as a relay for incoming mail from other SMTP relays.
|
||||
|
||||
2. The EHLO keyword value associated with the extension is "BURL".
|
||||
|
||||
3. The BURL EHLO keyword will have zero or more arguments. The only
|
||||
argument defined at this time is the "imap" argument, which MUST
|
||||
be present in order to use IMAP URLs with BURL. Clients MUST
|
||||
ignore other arguments after the BURL EHLO keyword unless they
|
||||
are defined by a subsequent IETF standards track specification.
|
||||
The arguments that appear after the BURL EHLO keyword may change
|
||||
subsequent to the use of SMTP AUTH [RFC2554], so a server that
|
||||
advertises BURL with no arguments prior to authentication
|
||||
indicates that BURL is supported but authentication is required
|
||||
to use it.
|
||||
|
||||
4. This extension adds the BURL SMTP verb. This verb is used as a
|
||||
replacement for the DATA command and is only permitted during a
|
||||
mail transaction after at least one successful RCPT TO.
|
||||
|
||||
3.2. BURL Transaction
|
||||
|
||||
A simple BURL transaction will consist of MAIL FROM, one or more RCPT
|
||||
TO headers, and a BURL command with the "LAST" tag. The BURL command
|
||||
will include an IMAP URL pointing to a fully formed message ready for
|
||||
injection into the SMTP infrastructure. If PIPELINING [RFC2920] is
|
||||
advertised, the client MAY send the entire transaction in one round
|
||||
trip. If no valid RCPT TO address is supplied, the BURL command will
|
||||
simply fail, and no resolution of the BURL URL argument will be
|
||||
performed. If at least one valid RCPT TO address is supplied, then
|
||||
the BURL URL argument will be resolved before the server responds to
|
||||
the command.
|
||||
|
||||
A more sophisticated BURL transaction MAY occur when the server also
|
||||
advertises CHUNKING [RFC3030]. In this case, the BURL and BDAT
|
||||
commands may be interleaved until one of them terminates the
|
||||
transaction with the "LAST" argument. If PIPELINING [RFC2920] is
|
||||
also advertised, then the client may pipeline the entire transaction
|
||||
in one round-trip. However, it MUST wait for the results of the
|
||||
"LAST" BDAT or BURL command prior to initiating a new transaction.
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 3]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
The BURL command directs the server to fetch the data object to which
|
||||
the URL refers and include it in the message. If the URL fetch
|
||||
fails, the server will fail the entire transaction.
|
||||
|
||||
3.3. The BURL IMAP Options
|
||||
|
||||
When "imap" is present in the space-separated list of arguments
|
||||
following the BURL EHLO keyword, it indicates that the BURL command
|
||||
supports the URLAUTH [RFC4467] extended form of IMAP URLs [RFC2192]
|
||||
and that the submit server is configured with the necessary
|
||||
credentials to resolve "urlauth=submit+" IMAP URLs for the submit
|
||||
server's domain.
|
||||
|
||||
Subsequent to a successful SMTP AUTH command, the submission server
|
||||
MAY indicate a prearranged trust relationship with a specific IMAP
|
||||
server by including a BURL EHLO keyword argument of the form
|
||||
"imap://imap.example.com". In this case, the submission server will
|
||||
permit a regular IMAP URL referring to messages or parts of messages
|
||||
on imap.example.com that the user who authenticated to the submit
|
||||
server can access. Note that this form does not imply that the
|
||||
submit server supports URLAUTH URLs; the submit server must advertise
|
||||
both "imap" and "imap://imap.example.com" to indicate support for
|
||||
both extended and non-extended URL forms.
|
||||
|
||||
When the submit server connects to the IMAP server, it acts as an
|
||||
IMAP client and thus is subject to both the mandatory-to-implement
|
||||
IMAP capabilities in Section 6.1.1 of RFC 3501, and the security
|
||||
considerations in Section 11 of RFC 3501. Specifically, this
|
||||
requires that the submit server implement a configuration that uses
|
||||
STARTTLS followed by SASL PLAIN [SASL-PLAIN] to authenticate to the
|
||||
IMAP server.
|
||||
|
||||
When the submit server resolves a URLAUTH IMAP URL, it uses submit
|
||||
server credentials when authenticating to the IMAP server. The
|
||||
authentication identity and password used for submit credentials MUST
|
||||
be configurable. The string "submit" is suggested as a default value
|
||||
for the authentication identity, with no default for the password.
|
||||
Typically, the authorization identity is empty in this case; thus the
|
||||
IMAP server will derive the authorization identity from the
|
||||
authentication identity. If the IMAP URL uses the "submit+" access
|
||||
identifier prefix, the submit server MUST refuse the BURL command
|
||||
unless the userid in the URL's <access> token matches the submit
|
||||
client's authorization identity.
|
||||
|
||||
When the submit server resolves a regular IMAP URL, it uses the
|
||||
submit client's authorization identity when authenticating to the
|
||||
IMAP server. If both the submit client and the submit server's
|
||||
embedded IMAP client use SASL PLAIN (or the equivalent), the submit
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 4]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
server SHOULD forward the client's credentials if and only if the
|
||||
submit server knows that the IMAP server is in the same
|
||||
administrative domain. If the submit server supports SASL mechanisms
|
||||
other than PLAIN, it MUST implement a configuration in which the
|
||||
submit server's embedded IMAP client uses STARTTLS and SASL PLAIN
|
||||
with the submit server's authentication identity and password (for
|
||||
the respective IMAP server) and the submit client's authorization
|
||||
identity.
|
||||
|
||||
3.4. Examples
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server, respectively. If a single "C:" or "S:" label applies to
|
||||
multiple lines, then the line breaks between those lines are for
|
||||
editorial clarity only and are not part of the actual protocol
|
||||
exchange.
|
||||
|
||||
Two successful submissions (without and with pipelining) follow:
|
||||
|
||||
<SSL/TLS encryption layer negotiated>
|
||||
C: EHLO potter.example.com
|
||||
S: 250-owlry.example.com
|
||||
S: 250-8BITMIME
|
||||
S: 250-BURL imap
|
||||
S: 250-AUTH PLAIN
|
||||
S: 250-DSN
|
||||
S: 250 ENHANCEDSTATUSCODES
|
||||
C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
|
||||
S: 235 2.7.0 PLAIN authentication successful.
|
||||
C: MAIL FROM:<harry@gryffindor.example.com>
|
||||
S: 250 2.5.0 Address Ok.
|
||||
C: RCPT TO:<ron@gryffindor.example.com>
|
||||
S: 250 2.1.5 ron@gryffindor.example.com OK.
|
||||
C: BURL imap://harry@gryffindor.example.com/outbox
|
||||
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
|
||||
:internal:91354a473744909de610943775f92038 LAST
|
||||
S: 250 2.5.0 Ok.
|
||||
|
||||
<SSL/TLS encryption layer negotiated>
|
||||
C: EHLO potter.example.com
|
||||
S: 250-owlry.example.com
|
||||
S: 250-8BITMIME
|
||||
S: 250-PIPELINING
|
||||
S: 250-BURL imap
|
||||
S: 250-AUTH PLAIN
|
||||
S: 250-DSN
|
||||
S: 250 ENHANCEDSTATUSCODES
|
||||
C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 5]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
C: MAIL FROM:<harry@gryffindor.example.com>
|
||||
C: RCPT TO:<ron@gryffindor.example.com>
|
||||
C: BURL imap://harry@gryffindor.example.com/outbox
|
||||
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
|
||||
:internal:91354a473744909de610943775f92038 LAST
|
||||
S: 235 2.7.0 PLAIN authentication successful.
|
||||
S: 250 2.5.0 Address Ok.
|
||||
S: 250 2.1.5 ron@gryffindor.example.com OK.
|
||||
S: 250 2.5.0 Ok.
|
||||
|
||||
Note that PIPELINING of the AUTH command is only permitted if the
|
||||
selected mechanism can be completed in one round trip, a client
|
||||
initial response is provided, and no SASL security layer is
|
||||
negotiated. This is possible for PLAIN and EXTERNAL, but not for
|
||||
most other SASL mechanisms.
|
||||
|
||||
Some examples of failure cases:
|
||||
|
||||
C: MAIL FROM:<harry@gryffindor.example.com>
|
||||
C: RCPT TO:<malfoy@slitherin.example.com>
|
||||
C: BURL imap://harry@gryffindor.example.com/outbox
|
||||
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
|
||||
:internal:91354a473744909de610943775f92038 LAST
|
||||
S: 250 2.5.0 Address Ok.
|
||||
S: 550 5.7.1 Relaying not allowed: malfoy@slitherin.example.com
|
||||
S: 554 5.5.0 No recipients have been specified.
|
||||
|
||||
C: MAIL FROM:<harry@gryffindor.example.com>
|
||||
C: RCPT TO:<ron@gryffindor.example.com>
|
||||
C: BURL imap://harry@gryffindor.example.com/outbox
|
||||
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
|
||||
:internal:71354a473744909de610943775f92038 LAST
|
||||
S: 250 2.5.0 Address Ok.
|
||||
S: 250 2.1.5 ron@gryffindor.example.com OK.
|
||||
S: 554 5.7.0 IMAP URL authorization failed
|
||||
|
||||
3.5. Formal Syntax
|
||||
|
||||
The following syntax specification inherits ABNF [RFC4234] and
|
||||
Uniform Resource Identifiers [RFC3986].
|
||||
|
||||
burl-param = "imap" / ("imap://" authority)
|
||||
; parameter to BURL EHLO keyword
|
||||
|
||||
burl-cmd = "BURL" SP absolute-URI [SP end-marker] CRLF
|
||||
|
||||
end-marker = "LAST"
|
||||
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 6]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
4. 8-Bit and Binary
|
||||
|
||||
A submit server that advertises BURL MUST also advertise 8BITMIME
|
||||
[RFC1652] and perform the down conversion described in that
|
||||
specification on the resulting complete message if 8-bit data is
|
||||
received with the BURL command and passed to a 7-bit server. If the
|
||||
URL argument to BURL refers to binary data, then the submit server
|
||||
MAY refuse the command or down convert as described in Binary SMTP
|
||||
[RFC3030].
|
||||
|
||||
The Submit server MAY refuse to accept a BURL command or combination
|
||||
of BURL and BDAT commands that result in un-encoded 8-bit data in
|
||||
mail or MIME [RFC2045] headers. Alternatively, the server MAY accept
|
||||
such data and down convert to MIME header encoding [RFC2047].
|
||||
|
||||
5. Updates to RFC 3463
|
||||
|
||||
SMTP or Submit servers that advertise ENHANCEDSTATUSCODES [RFC2034]
|
||||
use enhanced status codes defined in RFC 3463 [RFC3463]. The BURL
|
||||
extension introduces new error cases that that RFC did not consider.
|
||||
The following additional enhanced status codes are defined by this
|
||||
specification:
|
||||
|
||||
X.6.6 Message content not available
|
||||
|
||||
The message content could not be fetched from a remote system.
|
||||
This may be useful as a permanent or persistent temporary
|
||||
notification.
|
||||
|
||||
X.7.8 Trust relationship required
|
||||
|
||||
The submission server requires a configured trust relationship
|
||||
with a third-party server in order to access the message content.
|
||||
|
||||
6. Response Codes
|
||||
|
||||
This section includes example response codes to the BURL command.
|
||||
Other text may be used with the same response codes. This list is
|
||||
not exhaustive, and BURL clients MUST tolerate any valid SMTP
|
||||
response code. Most of these examples include the appropriate
|
||||
enhanced status code [RFC3463].
|
||||
|
||||
554 5.5.0 No recipients have been specified
|
||||
|
||||
This response code occurs when BURL is used (for example, with
|
||||
PIPELINING) and all RCPT TOs failed.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 7]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
503 5.5.0 Valid RCPT TO required before BURL
|
||||
|
||||
This response code is an alternative to the previous one when BURL
|
||||
is used (for example, with PIPELINING) and all RCPT TOs failed.
|
||||
|
||||
554 5.6.3 Conversion required but not supported
|
||||
|
||||
This response code occurs when the URL points to binary data and
|
||||
the implementation does not support down conversion to base64.
|
||||
This can also be used if the URL points to message data with 8-bit
|
||||
content in headers and the server does not down convert such
|
||||
content.
|
||||
|
||||
554 5.3.4 Message too big for system
|
||||
|
||||
The message (subsequent to URL resolution) is larger than the
|
||||
per-message size limit for this server.
|
||||
|
||||
554 5.7.8 URL resolution requires trust relationship
|
||||
|
||||
The submit server does not have a trust relationship with the IMAP
|
||||
server specified in the URL argument to BURL.
|
||||
|
||||
552 5.2.2 Mailbox full
|
||||
|
||||
The recipient is local, the submit server supports direct
|
||||
delivery, and the recipient has exceeded his quota and any grace
|
||||
period for delivery attempts.
|
||||
|
||||
554 5.6.6 IMAP URL resolution failed
|
||||
|
||||
The IMAP URLFETCH command returned an error or no data.
|
||||
|
||||
250 2.5.0 Waiting for additional BURL or BDAT commands
|
||||
|
||||
A BURL command without the "LAST" modifier was sent. The URL for
|
||||
this BURL command was successfully resolved, but the content will
|
||||
not necessarily be committed to persistent storage until the rest
|
||||
of the message content is collected. For example, a Unix server
|
||||
may have written the content to a queue file buffer, but may not
|
||||
yet have performed an fsync() operation. If the server loses
|
||||
power, the content can still be lost.
|
||||
|
||||
451 4.4.1 IMAP server unavailable
|
||||
|
||||
The connection to the IMAP server to resolve the URL failed.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 8]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
250 2.5.0 Ok.
|
||||
|
||||
The URL was successfully resolved, and the complete message data
|
||||
has been committed to persistent storage.
|
||||
|
||||
250 2.6.4 MIME header conversion with loss performed
|
||||
|
||||
The URL pointed to message data that included mail or MIME headers
|
||||
with 8-bit data. This data was converted to MIME header encoding
|
||||
[RFC2047], but the submit server may not have correctly guessed
|
||||
the unlabeled character set.
|
||||
|
||||
7. IANA Considerations
|
||||
|
||||
The "BURL" SMTP extension as described in Section 3 has been
|
||||
registered. This registration has been marked for use by message
|
||||
submission [RFC4409] only in the registry.
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
Modern SMTP submission servers often include content-based security
|
||||
and denial-of-service defense mechanisms such as virus filtering,
|
||||
size limits, server-generated signatures, spam filtering, etc.
|
||||
Implementations of BURL should fetch the URL content prior to
|
||||
application of such content-based mechanisms in order to preserve
|
||||
their function.
|
||||
|
||||
Clients that generate unsolicited bulk email or email with viruses
|
||||
could use this mechanism to compensate for a slow link between the
|
||||
client and submit server. In particular, this mechanism would make
|
||||
it feasible for a programmable cell phone or other device on a slow
|
||||
link to become a significant source of unsolicited bulk email and/or
|
||||
viruses. This makes it more important for submit server vendors
|
||||
implementing BURL to have auditing and/or defenses against such
|
||||
denial-of-service attacks including mandatory authentication, logging
|
||||
that associates unique client identifiers with mail transactions,
|
||||
limits on reuse of the same IMAP URL, rate limits, recipient count
|
||||
limits, and content filters.
|
||||
|
||||
Transfer of the URLAUTH [RFC4467] form of IMAP URLs in the clear can
|
||||
expose the authorization token to network eavesdroppers.
|
||||
Implementations that support such URLs can address this issue by
|
||||
using a strong confidentiality protection mechanism. For example,
|
||||
the SMTP STARTTLS [RFC3207] and the IMAP STARTTLS [RFC3501]
|
||||
extensions, in combination with a configuration setting that requires
|
||||
their use with such IMAP URLs, would address this concern.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 9]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
Use of a prearranged trust relationship between a submit server and a
|
||||
specific IMAP server introduces security considerations. A
|
||||
compromise of the submit server should not automatically compromise
|
||||
all accounts on the IMAP server, so trust relationships involving
|
||||
super-user proxy credentials are strongly discouraged. A system that
|
||||
requires the submit server to authenticate to the IMAP server with
|
||||
submit credentials and subsequently requires a URLAUTH URL to fetch
|
||||
any content addresses this concern. A trusted third party model for
|
||||
proxy credentials (such as that provided by Kerberos 5 [RFC4120])
|
||||
would also suffice.
|
||||
|
||||
When a client uses SMTP STARTTLS to send a BURL command that
|
||||
references non-public information, there is a user expectation that
|
||||
the entire message content will be treated confidentially. To
|
||||
address this expectation, the message submission server SHOULD use
|
||||
STARTTLS or a mechanism providing equivalent data confidentiality
|
||||
when fetching the content referenced by that URL.
|
||||
|
||||
A legitimate user of a submit server may try to compromise other
|
||||
accounts on the server by providing an IMAP URLAUTH URL that points
|
||||
to a server under that user's control that is designed to undermine
|
||||
the security of the submit server. For this reason, the IMAP client
|
||||
code that the submit server uses must be robust with respect to
|
||||
arbitrary input sizes (including large IMAP literals) and arbitrary
|
||||
delays from the IMAP server. Requiring a prearranged trust
|
||||
relationship between a submit server and the IMAP server also
|
||||
addresses this concern.
|
||||
|
||||
An authorized user of the submit server could set up a fraudulent
|
||||
IMAP server and pass a URL for that server to the submit server. The
|
||||
submit server might then contact the fraudulent IMAP server to
|
||||
authenticate with submit credentials and fetch content. There are
|
||||
several ways to mitigate this potential attack. A submit server that
|
||||
only uses submit credentials with a fixed set of trusted IMAP servers
|
||||
will not be vulnerable to exposure of those credentials. A submit
|
||||
server can treat the IMAP server as untrusted and include defenses
|
||||
for buffer overflows, denial-of-service slowdowns, and other
|
||||
potential attacks. Finally, because authentication is required to
|
||||
use BURL, it is possible to keep a secure audit trail and use that to
|
||||
detect and punish the offending party.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 10]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
9. References
|
||||
|
||||
9.1. Normative References
|
||||
|
||||
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
|
||||
Crocker, "SMTP Service Extension for
|
||||
8bit-MIMEtransport", RFC 1652, July 1994.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192,
|
||||
September 1997.
|
||||
|
||||
[RFC2554] Myers, J., "SMTP Service Extension for Authentication",
|
||||
RFC 2554, March 1999.
|
||||
|
||||
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
|
||||
April 2001.
|
||||
|
||||
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP
|
||||
over Transport Layer Security", RFC 3207,
|
||||
February 2002.
|
||||
|
||||
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
|
||||
VERSION 4rev1", RFC 3501, March 2003.
|
||||
|
||||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
|
||||
"Uniform Resource Identifier (URI): Generic Syntax",
|
||||
STD 66, RFC 3986, January 2005.
|
||||
|
||||
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for
|
||||
Mail", RFC 4409, April 2006.
|
||||
|
||||
[RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) -
|
||||
URLAUTH Extension", RFC 4467, May 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 11]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
9.2. Informative References
|
||||
|
||||
[RFC2034] Freed, N., "SMTP Service Extension for Returning
|
||||
Enhanced Error Codes", RFC 2034, October 1996.
|
||||
|
||||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
|
||||
Mail Extensions (MIME) Part One: Format of Internet
|
||||
Message Bodies", RFC 2045, November 1996.
|
||||
|
||||
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
|
||||
Extensions) Part Three: Message Header Extensions for
|
||||
Non-ASCII Text", RFC 2047, November 1996.
|
||||
|
||||
[RFC2920] Freed, N., "SMTP Service Extension for Command
|
||||
Pipelining", STD 60, RFC 2920, September 2000.
|
||||
|
||||
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for
|
||||
Transmission of Large and Binary MIME Messages",
|
||||
RFC 3030, December 2000.
|
||||
|
||||
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
|
||||
RFC 3463, January 2003.
|
||||
|
||||
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
|
||||
Kerberos Network Authentication Service (V5)", RFC
|
||||
4120, July 2005.
|
||||
|
||||
[SASL-PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in
|
||||
Progress, March 2005.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 12]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
Appendix A. Acknowledgements
|
||||
|
||||
This document is a product of the lemonade WG. Many thanks are due
|
||||
to all the participants of that working group for their input. Mark
|
||||
Crispin was instrumental in the conception of this mechanism. Thanks
|
||||
to Randall Gellens, Alexey Melnikov, Sam Hartman, Ned Freed, Dave
|
||||
Cridland, Peter Coates, and Mark Crispin for review comments on the
|
||||
document. Thanks to the RFC Editor for correcting the author's
|
||||
grammar mistakes. Thanks to Ted Hardie, Randall Gellens, Mark
|
||||
Crispin, Pete Resnick, and Greg Vaudreuil for extremely interesting
|
||||
debates comparing this proposal and alternatives. Thanks to the
|
||||
lemonade WG chairs Eric Burger and Glenn Parsons for concluding the
|
||||
debate at the correct time and making sure this document got
|
||||
completed.
|
||||
|
||||
Author's Address
|
||||
|
||||
Chris Newman
|
||||
Sun Microsystems
|
||||
3401 Centrelake Dr., Suite 410
|
||||
Ontario, CA 91761
|
||||
US
|
||||
|
||||
EMail: chris.newman@sun.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 13]
|
||||
|
||||
RFC 4468 Message Submission BURL Extension May 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Newman Standards Track [Page 14]
|
||||
|
||||
731
docs/rfc/rfc4469.txt
Normal file
731
docs/rfc/rfc4469.txt
Normal file
@ -0,0 +1,731 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group P. Resnick
|
||||
Request for Comments: 4469 QUALCOMM Incorporated
|
||||
Updates: 3501, 3502 April 2006
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Internet Message Access Protocol (IMAP) CATENATE Extension
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
The CATENATE extension to the Internet Message Access Protocol (IMAP)
|
||||
extends the APPEND command to allow clients to create messages on the
|
||||
IMAP server that may contain a combination of new data along with
|
||||
parts of (or entire) messages already on the server. Using this
|
||||
extension, the client can catenate parts of an already existing
|
||||
message onto a new message without having to first download the data
|
||||
and then upload it back to the server.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 1]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The CATENATE extension to the Internet Message Access Protocol (IMAP)
|
||||
[1] allows the client to create a message on the server that can
|
||||
include the text of messages (or parts of messages) that already
|
||||
exist on the server without having to FETCH them and APPEND them back
|
||||
to the server. The CATENATE extension extends the APPEND command so
|
||||
that, instead of a single message literal, the command can take as
|
||||
arguments any combination of message literals (as described in IMAP
|
||||
[1]) and message URLs (as described in the IMAP URL Scheme [2]
|
||||
specification). The server takes all the pieces and catenates them
|
||||
into the output message. The CATENATE extension can also coexist
|
||||
with the MULTIAPPEND extension [3] to APPEND multiple messages in a
|
||||
single command.
|
||||
|
||||
There are some obvious uses for the CATENATE extension. The
|
||||
motivating use case was to provide a way for a resource-constrained
|
||||
client to compose a message for subsequent submission that contains
|
||||
data that already exists in that client's IMAP store. Because the
|
||||
client does not have to download and re-upload potentially large
|
||||
message parts, bandwidth and processing limitations do not have as
|
||||
much impact. In addition, since the client can create a message in
|
||||
its own IMAP store, the command also addresses the desire of the
|
||||
client to archive a copy of a sent message without having to upload
|
||||
the message twice. (Mechanisms for sending the message are outside
|
||||
the scope of this document.)
|
||||
|
||||
The extended APPEND command can also be used to copy parts of a
|
||||
message to another mailbox for archival purposes while getting rid of
|
||||
undesired parts. In environments where server storage is limited, a
|
||||
client could get rid of large message parts by copying over only the
|
||||
necessary parts and then deleting the original message. The
|
||||
mechanism could also be used to add data to a message (such as
|
||||
prepending message header fields) or to include other data by making
|
||||
a copy of the original and catenating the new data.
|
||||
|
||||
2. The CATENATE Capability
|
||||
|
||||
A server that supports this extension returns "CATENATE" as one of
|
||||
the responses to the CAPABILITY command.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 2]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
3. The APPEND Command
|
||||
|
||||
Arguments: mailbox name
|
||||
(The following can be repeated in the presence of the
|
||||
MULTIAPPEND extension [3])
|
||||
OPTIONAL flag parenthesized list
|
||||
OPTIONAL date/time string
|
||||
a single message literal or one or more message parts to
|
||||
catenate, specified as:
|
||||
message literal
|
||||
or
|
||||
message (or message part) URL
|
||||
|
||||
Responses: OPTIONAL NO responses: BADURL, TOOBIG
|
||||
|
||||
Result: OK - append completed
|
||||
NO - append error: can't append to that mailbox, error
|
||||
in flags or date/time or message text, or can't
|
||||
fetch that data
|
||||
BAD - command unknown or arguments invalid
|
||||
|
||||
The APPEND command concatenates all the message parts and appends
|
||||
them as a new message to the end of the specified mailbox. The
|
||||
parenthesized flag list and date/time string set the flags and the
|
||||
internal date, respectively, as described in IMAP [1]. The
|
||||
subsequent command parameters specify the message parts that are
|
||||
appended sequentially to the output message.
|
||||
|
||||
If the original form of APPEND is used, a message literal follows the
|
||||
optional flag list and date/time string, which is appended as
|
||||
described in IMAP [1]. If the extended form is used, "CATENATE" and
|
||||
a parenthesized list of message literals and message URLs follows,
|
||||
each of which is appended to the new message. If a message literal
|
||||
is specified (indicated by "TEXT"), the octets following the count
|
||||
are appended. If a message URL is specified (indicated by "URL"),
|
||||
the octets of the body part pointed to by that URL are appended, as
|
||||
if the literal returned in a FETCH BODY response were put in place of
|
||||
the message part specifier. The APPEND command does not cause the
|
||||
\Seen flag to be set for any catenated body part. The APPEND command
|
||||
does not change the selected mailbox.
|
||||
|
||||
In the extended APPEND command, the string following "URL" is an IMAP
|
||||
URL [2] and is interpreted according to the rules of [2]. The
|
||||
present document only describes the behavior of the command using
|
||||
IMAP URLs that refer to specific messages or message parts on the
|
||||
current IMAP server from the current authenticated IMAP session.
|
||||
Because of that, only relative IMAP message or message part URLs
|
||||
(i.e., those having no scheme or <iserver>) are used. The base URL
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 3]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
for evaluating the relative URL is considered "imap://user@server/",
|
||||
where "user" is the user name of the currently authenticated user and
|
||||
"server" is the domain name of the current server. When in the
|
||||
selected state, the base URL is considered
|
||||
"imap://user@server/mailbox", where "mailbox" is the encoded name of
|
||||
the currently selected mailbox. Additionally, since the APPEND
|
||||
command is valid in the authenticated state of an IMAP session, no
|
||||
further LOGIN or AUTHENTICATE command is performed for URLs specified
|
||||
in the extended APPEND command.
|
||||
|
||||
Note: Use of an absolute IMAP URL or any URL that refers to
|
||||
anything other than a message or message part from the current
|
||||
authenticated IMAP session is outside the scope of this document
|
||||
and would require an extension to this specification, and a server
|
||||
implementing only this specification would return NO to such a
|
||||
request.
|
||||
|
||||
The client is responsible for making sure that the catenated message
|
||||
is in the format of an Internet Message Format (RFC 2822) [4] or
|
||||
Multipurpose Internet Mail Extension (MIME) [5] message. In
|
||||
particular, when a URL is catenated, the server copies octets,
|
||||
unchanged, from the indicated message or message part to the
|
||||
catenated message. It does no data conversion (e.g., MIME transfer
|
||||
encodings) nor any verification that the data is appropriate for the
|
||||
MIME part of the message into which it is inserted. The client is
|
||||
also responsible for inserting appropriate MIME boundaries between
|
||||
body parts, and writing MIME Content-Type and Content-Transfer-
|
||||
Encoding lines as needed in the appropriate places.
|
||||
|
||||
Responses behave just as the original APPEND command described in
|
||||
IMAP [1]. If the server implements the IMAP UIDPLUS extension [6],
|
||||
it will also return an APPENDUID response code in the tagged OK
|
||||
response. Two response codes are provided in Section 4 that can be
|
||||
used in the tagged NO response if the APPEND command fails.
|
||||
|
||||
4. Response Codes
|
||||
|
||||
When a APPEND command fails, it may return a response code that
|
||||
describes a reason for the failure.
|
||||
|
||||
4.1. BADURL Response
|
||||
|
||||
The BADURL response code is returned if the APPEND fails to process
|
||||
one of the specified URLs. Possible reasons for this are bad URL
|
||||
syntax, unrecognized URL schema, invalid message UID, or invalid body
|
||||
part. The BADURL response code contains the first URL specified as a
|
||||
parameter to the APPEND command that has caused the operation to
|
||||
fail.
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 4]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
4.2. TOOBIG Response
|
||||
|
||||
The TOOBIG response code is returned if the resulting message will
|
||||
exceed the 4-GB IMAP message limit. This might happen, for example,
|
||||
if the client specifies 3 URLs for 2-GB messages. Note that even if
|
||||
the server doesn't return TOOBIG, it still has to be defensive
|
||||
against misbehaving or malicious clients that try to construct a
|
||||
message over the 4-GB limit. The server may also wish to return the
|
||||
TOOBIG response code if the resulting message exceeds a server-
|
||||
specific message size limit.
|
||||
|
||||
5. Formal Syntax
|
||||
|
||||
The following syntax specification uses the Augmented Backus-Naur
|
||||
Form (ABNF) [7] notation. Elements not defined here can be found in
|
||||
the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
|
||||
[8] specifications. Note that capability and resp-text-code are
|
||||
extended from the IMAP [1] specification and append-data is extended
|
||||
from the IMAP ABNF extensions [8] specification.
|
||||
|
||||
append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"
|
||||
|
||||
cat-part = text-literal / url
|
||||
|
||||
text-literal = "TEXT" SP literal
|
||||
|
||||
url = "URL" SP astring
|
||||
|
||||
resp-text-code =/ toobig-response-code / badurl-response-code
|
||||
|
||||
toobig-response-code = "TOOBIG"
|
||||
|
||||
badurl-response-code = "BADURL" SP url-resp-text
|
||||
|
||||
url-resp-text = 1*(%x01-09 /
|
||||
%x0B-0C /
|
||||
%x0E-5B /
|
||||
%x5D-FE) ; Any TEXT-CHAR except "]"
|
||||
|
||||
capability =/ "CATENATE"
|
||||
|
||||
The astring in the definition of url and the url-resp-text in the
|
||||
definition of badurl-response-code each contain an imapurl as defined
|
||||
by [2].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 5]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
6. Acknowledgements
|
||||
|
||||
Thanks to the members of the LEMONADE working group for their input.
|
||||
Special thanks to Alexey Melnikov for the examples.
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
The CATENATE extension does not raise any security considerations
|
||||
that are not present for the base protocol or in the use of IMAP
|
||||
URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2]
|
||||
documents.
|
||||
|
||||
8. IANA Considerations
|
||||
|
||||
IMAP4 capabilities are registered by publishing a standards track or
|
||||
IESG approved experimental RFC. The registry is currently located at
|
||||
<http://www.iana.org/assignments/imap4-capabilities>. This document
|
||||
defines the CATENATE IMAP capability. The IANA has added this
|
||||
capability to the registry.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 6]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
Appendix A. Examples
|
||||
|
||||
Lines not starting with "C: " or "S: " are continuations of the
|
||||
previous lines.
|
||||
|
||||
The original message in examples 1 and 2 below (UID = 20) has the
|
||||
following structure:
|
||||
|
||||
|
||||
multipart/mixed MIME message with two body parts:
|
||||
|
||||
1. text/plain
|
||||
|
||||
2. application/x-zip-compressed
|
||||
|
||||
Example 1: The following example demonstrates how a CATENATE client
|
||||
can replace an attachment in a draft message, without the need to
|
||||
download it to the client and upload it back.
|
||||
|
||||
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
|
||||
(URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=HEADER"
|
||||
TEXT {42}
|
||||
S: + Ready for literal data
|
||||
C:
|
||||
C: --------------030308070208000400050907
|
||||
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1.MIME"
|
||||
URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1" TEXT {42}
|
||||
S: + Ready for literal data
|
||||
C:
|
||||
C: --------------030308070208000400050907
|
||||
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44}
|
||||
S: + Ready for literal data
|
||||
C:
|
||||
C: --------------030308070208000400050907--
|
||||
C: )
|
||||
S: A003 OK catenate append completed
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 7]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
Example 2: The following example demonstrates how the CATENATE
|
||||
extension can be used to replace edited text in a draft message, as
|
||||
well as header fields for the top level message part (e.g., Subject
|
||||
has changed). The previous version of the draft is marked as
|
||||
\Deleted. Note that the server also supports the UIDPLUS extension,
|
||||
so the APPENDUID response code is returned in the successful OK
|
||||
response to the APPEND command.
|
||||
|
||||
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738}
|
||||
S: + Ready for literal data
|
||||
C: Return-Path: <bar@example.org>
|
||||
C: Received: from [127.0.0.2]
|
||||
C: by rufus.example.org via TCP (internal) with ESMTPA;
|
||||
C: Thu, 11 Nov 2004 16:57:07 +0000
|
||||
C: Message-ID: <419399E1.6000505@example.org>
|
||||
C: Date: Thu, 12 Nov 2004 16:57:05 +0000
|
||||
C: From: Bob Ar <bar@example.org>
|
||||
C: X-Accept-Language: en-us, en
|
||||
C: MIME-Version: 1.0
|
||||
C: To: foo@example.net
|
||||
C: Subject: About our holiday trip
|
||||
C: Content-Type: multipart/mixed;
|
||||
C: boundary="------------030308070208000400050907"
|
||||
C:
|
||||
C: --------------030308070208000400050907
|
||||
C: Content-Type: text/plain; charset=us-ascii; format=flowed
|
||||
C: Content-Transfer-Encoding: 7bit
|
||||
C:
|
||||
C: Our travel agent has sent the updated schedule.
|
||||
C:
|
||||
C: Cheers,
|
||||
C: Bob
|
||||
C: --------------030308070208000400050907
|
||||
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2.MIME"
|
||||
URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2" TEXT {44}
|
||||
S: + Ready for literal data
|
||||
C:
|
||||
C: --------------030308070208000400050907--
|
||||
C: )
|
||||
S: A003 OK [APPENDUID 385759045 45] append Completed
|
||||
C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted)
|
||||
S: A004 OK STORE completed
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 8]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
Example 3: The following example demonstrates how the CATENATE
|
||||
extension can be used to strip attachments. Below, a PowerPoint
|
||||
attachment was replaced by a small text part explaining that the
|
||||
attachment was stripped.
|
||||
|
||||
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
|
||||
(URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=HEADER"
|
||||
TEXT {42}
|
||||
S: + Ready for literal data
|
||||
C:
|
||||
C: --------------030308070208000400050903
|
||||
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1.MIME"
|
||||
URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1" TEXT {255}
|
||||
S: + Ready for literal data
|
||||
C:
|
||||
C: --------------030308070208000400050903
|
||||
C: Content-type: text/plain; charset="us-ascii"
|
||||
C: Content-transfer-encoding: 7bit
|
||||
C:
|
||||
C: This body part contained a Power Point presentation that was
|
||||
C: deleted upon your request.
|
||||
C: --------------030308070208000400050903--
|
||||
C: )
|
||||
S: A003 OK append Completed
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 9]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
Example 4: The following example demonstrates a failed APPEND
|
||||
command. The server returns the BADURL response code to indicate
|
||||
that one of the provided URLs is invalid. This example also
|
||||
demonstrates how the CATENATE extension can be used to construct a
|
||||
digest of several messages.
|
||||
|
||||
C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541}
|
||||
S: + Ready for literal data
|
||||
C: Return-Path: <foo@example.org>
|
||||
C: Received: from [127.0.0.2]
|
||||
C: by rufus.example.org via TCP (internal) with ESMTPA;
|
||||
C: Thu, 11 Nov 2004 16:57:07 +0000
|
||||
C: Message-ID: <419399E1.6000505@example.org>
|
||||
C: Date: Thu, 21 Nov 2004 16:57:05 +0000
|
||||
C: From: Farren Oo <foo@example.org>
|
||||
C: X-Accept-Language: en-us, en
|
||||
C: MIME-Version: 1.0
|
||||
C: To: bar@example.org
|
||||
C: Subject: Digest of the mailing list for today
|
||||
C: Content-Type: multipart/digest;
|
||||
C: boundary="------------030308070208000400050904"
|
||||
C:
|
||||
C: --------------030308070208000400050904
|
||||
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42}
|
||||
S: + Ready for literal data
|
||||
C:
|
||||
C: --------------030308070208000400050904
|
||||
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=113330/;section=1.5.9"
|
||||
TEXT {42}
|
||||
S: + Ready for literal data
|
||||
C:
|
||||
C: --------------030308070208000400050904
|
||||
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {44}
|
||||
S: + Ready for literal data
|
||||
C:
|
||||
C: --------------030308070208000400050904--
|
||||
C: )
|
||||
S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330;
|
||||
section=1.5.9"] CATENATE append has failed, one message expunged
|
||||
|
||||
Note that the server could have validated the URLs as they were
|
||||
received and therefore could have returned the tagged NO response
|
||||
with BADURL response-code in place of any continuation request after
|
||||
the URL was received.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 10]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
9. Normative References
|
||||
|
||||
[1] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
|
||||
RFC 3501, March 2003.
|
||||
|
||||
[2] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
|
||||
|
||||
[3] Crispin, M., "Internet Message Access Protocol (IMAP) -
|
||||
MULTIAPPEND Extension", RFC 3502, March 2003.
|
||||
|
||||
[4] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
|
||||
|
||||
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
||||
Extensions (MIME) Part One: Format of Internet Message Bodies",
|
||||
RFC 2045, November 1996.
|
||||
|
||||
[6] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS
|
||||
extension", RFC 4315, December 2005.
|
||||
|
||||
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[8] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF",
|
||||
RFC 4466, April 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 11]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Peter W. Resnick
|
||||
QUALCOMM Incorporated
|
||||
5775 Morehouse Drive
|
||||
San Diego, CA 92121-1714
|
||||
US
|
||||
|
||||
Phone: +1 858 651 4478
|
||||
EMail: presnick@qualcomm.com
|
||||
URI: http://www.qualcomm.com/~presnick/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 12]
|
||||
|
||||
RFC 4469 IMAP CATENATE Extension April 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Resnick Standards Track [Page 13]
|
||||
|
||||
507
docs/rfc/rfc4505.txt
Normal file
507
docs/rfc/rfc4505.txt
Normal file
@ -0,0 +1,507 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga, Ed.
|
||||
Request for Comments: 4505 OpenLDAP Foundation
|
||||
Obsoletes: 2245 June 2006
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Anonymous Simple Authentication and Security Layer (SASL) Mechanism
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
On the Internet, it is common practice to permit anonymous access to
|
||||
various services. Traditionally, this has been done with a plain-
|
||||
text password mechanism using "anonymous" as the user name and using
|
||||
optional trace information, such as an email address, as the
|
||||
password. As plain-text login commands are not permitted in new IETF
|
||||
protocols, a new way to provide anonymous login is needed within the
|
||||
context of the Simple Authentication and Security Layer (SASL)
|
||||
framework.
|
||||
|
||||
1. Introduction
|
||||
|
||||
This document defines an anonymous mechanism for the Simple
|
||||
Authentication and Security Layer ([SASL]) framework. The name
|
||||
associated with this mechanism is "ANONYMOUS".
|
||||
|
||||
Unlike many other SASL mechanisms, whose purpose is to authenticate
|
||||
and identify the user to a server, the purpose of this SASL mechanism
|
||||
is to allow the user to gain access to services or resources without
|
||||
requiring the user to establish or otherwise disclose their identity
|
||||
to the server. That is, this mechanism provides an anonymous login
|
||||
method.
|
||||
|
||||
This mechanism does not provide a security layer.
|
||||
|
||||
This document replaces RFC 2245. Changes since RFC 2245 are detailed
|
||||
in Appendix A.
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 1]
|
||||
|
||||
RFC 4505 Anonymous SASL Mechanism June 2006
|
||||
|
||||
|
||||
2. The Anonymous Mechanism
|
||||
|
||||
The mechanism consists of a single message from the client to the
|
||||
server. The client may include in this message trace information in
|
||||
the form of a string of [UTF-8]-encoded [Unicode] characters prepared
|
||||
in accordance with [StringPrep] and the "trace" stringprep profile
|
||||
defined in Section 3 of this document. The trace information, which
|
||||
has no semantical value, should take one of two forms: an Internet
|
||||
email address, or an opaque string that does not contain the '@'
|
||||
(U+0040) character and that can be interpreted by the system
|
||||
administrator of the client's domain. For privacy reasons, an
|
||||
Internet email address or other information identifying the user
|
||||
should only be used with permission from the user.
|
||||
|
||||
A server that permits anonymous access will announce support for the
|
||||
ANONYMOUS mechanism and allow anyone to log in using that mechanism,
|
||||
usually with restricted access.
|
||||
|
||||
A formal grammar for the client message using Augmented BNF [ABNF] is
|
||||
provided below as a tool for understanding this technical
|
||||
specification.
|
||||
|
||||
message = [ email / token ]
|
||||
;; to be prepared in accordance with Section 3
|
||||
|
||||
UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040)
|
||||
UTF2 = %xC2-DF UTF0
|
||||
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
|
||||
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
|
||||
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
|
||||
%xF4 %x80-8F 2(UTF0)
|
||||
UTF0 = %x80-BF
|
||||
|
||||
TCHAR = UTF1 / UTF2 / UTF3 / UTF4
|
||||
;; any UTF-8 encoded Unicode character
|
||||
;; except '@' (U+0040)
|
||||
|
||||
email = addr-spec
|
||||
;; as defined in [IMAIL]
|
||||
|
||||
token = 1*255TCHAR
|
||||
|
||||
Note to implementors:
|
||||
The <token> production is restricted to 255 UTF-8-encoded Unicode
|
||||
characters. As the encoding of a characters uses a sequence of 1
|
||||
to 4 octets, a token may be as long as 1020 octets.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 2]
|
||||
|
||||
RFC 4505 Anonymous SASL Mechanism June 2006
|
||||
|
||||
|
||||
3. The "trace" Profile of "Stringprep"
|
||||
|
||||
This section defines the "trace" profile of [StringPrep]. This
|
||||
profile is designed for use with the SASL ANONYMOUS Mechanism.
|
||||
Specifically, the client is to prepare the <message> production in
|
||||
accordance with this profile.
|
||||
|
||||
The character repertoire of this profile is Unicode 3.2 [Unicode].
|
||||
|
||||
No mapping is required by this profile.
|
||||
|
||||
No Unicode normalization is required by this profile.
|
||||
|
||||
The list of unassigned code points for this profile is that provided
|
||||
in Appendix A of [StringPrep]. Unassigned code points are not
|
||||
prohibited.
|
||||
|
||||
Characters from the following tables of [StringPrep] are prohibited:
|
||||
|
||||
- C.2.1 (ASCII control characters)
|
||||
- C.2.2 (Non-ASCII control characters)
|
||||
- C.3 (Private use characters)
|
||||
- C.4 (Non-character code points)
|
||||
- C.5 (Surrogate codes)
|
||||
- C.6 (Inappropriate for plain text)
|
||||
- C.8 (Change display properties are deprecated)
|
||||
- C.9 (Tagging characters)
|
||||
|
||||
No additional characters are prohibited.
|
||||
|
||||
This profile requires bidirectional character checking per Section 6
|
||||
of [StringPrep].
|
||||
|
||||
4. Example
|
||||
|
||||
Here is a sample ANONYMOUS login between an IMAP client and server.
|
||||
In this example, "C:" and "S:" indicate lines sent by the client and
|
||||
server, respectively. If such lines are wrapped without a new "C:"
|
||||
or "S:" label, then the wrapping is for editorial clarity and is not
|
||||
part of the command.
|
||||
|
||||
Note that this example uses the IMAP profile [IMAP4] of SASL. The
|
||||
base64 encoding of challenges and responses as well as the "+ "
|
||||
preceding the responses are part of the IMAP4 profile, not part of
|
||||
SASL itself. Additionally, protocols with SASL profiles permitting
|
||||
an initial client response will be able to avoid the extra round trip
|
||||
below (the server response with an empty "+ ").
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 3]
|
||||
|
||||
RFC 4505 Anonymous SASL Mechanism June 2006
|
||||
|
||||
|
||||
In this example, the trace information is "sirhc".
|
||||
|
||||
S: * OK IMAP4 server ready
|
||||
C: A001 CAPABILITY
|
||||
S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS
|
||||
S: A001 OK done
|
||||
C: A002 AUTHENTICATE ANONYMOUS
|
||||
S: +
|
||||
C: c2lyaGM=
|
||||
S: A003 OK Welcome, trace information has been logged.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
The ANONYMOUS mechanism grants access to services and/or resources by
|
||||
anyone. For this reason, it should be disabled by default so that
|
||||
the administrator can make an explicit decision to enable it.
|
||||
|
||||
If the anonymous user has any write privileges, a denial-of-service
|
||||
attack is possible by filling up all available space. This can be
|
||||
prevented by disabling all write access by anonymous users.
|
||||
|
||||
If anonymous users have read and write access to the same area, the
|
||||
server can be used as a communication mechanism to exchange
|
||||
information anonymously. Servers that accept anonymous submissions
|
||||
should implement the common "drop box" model, which forbids anonymous
|
||||
read access to the area where anonymous submissions are accepted.
|
||||
|
||||
If the anonymous user can run many expensive operations (e.g., an
|
||||
IMAP SEARCH BODY command), this could enable a denial-of-service
|
||||
attack. Servers are encouraged to reduce the priority of anonymous
|
||||
users or limit their resource usage.
|
||||
|
||||
While servers may impose a limit on the number of anonymous users,
|
||||
note that such limits enable denial-of-service attacks and should be
|
||||
used with caution.
|
||||
|
||||
The trace information is not authenticated, so it can be falsified.
|
||||
This can be used as an attempt to get someone else in trouble for
|
||||
access to questionable information. Administrators investigating
|
||||
abuse need to realize that this trace information may be falsified.
|
||||
|
||||
A client that uses the user's correct email address as trace
|
||||
information without explicit permission may violate that user's
|
||||
privacy. Anyone who accesses an anonymous archive on a sensitive
|
||||
subject (e.g., sexual abuse) likely has strong privacy needs.
|
||||
Clients should not send the email address without the explicit
|
||||
permission of the user and should offer the option of supplying no
|
||||
trace information, thus only exposing the source IP address and time.
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 4]
|
||||
|
||||
RFC 4505 Anonymous SASL Mechanism June 2006
|
||||
|
||||
|
||||
Anonymous proxy servers could enhance this privacy but would have to
|
||||
consider the resulting potential denial-of-service attacks.
|
||||
|
||||
Anonymous connections are susceptible to man-in-the-middle attacks
|
||||
that view or alter the data transferred. Clients and servers are
|
||||
encouraged to support external data security services.
|
||||
|
||||
Protocols that fail to require an explicit anonymous login are more
|
||||
susceptible to break-ins given certain common implementation
|
||||
techniques. Specifically, Unix servers that offer user login may
|
||||
initially start up as root and switch to the appropriate user id
|
||||
after an explicit login command. Normally, such servers refuse all
|
||||
data access commands prior to explicit login and may enter a
|
||||
restricted security environment (e.g., the Unix chroot(2) function)
|
||||
for anonymous users. If anonymous access is not explicitly
|
||||
requested, the entire data access machinery is exposed to external
|
||||
security attacks without the chance for explicit protective measures.
|
||||
Protocols that offer restricted data access should not allow
|
||||
anonymous data access without an explicit login step.
|
||||
|
||||
General [SASL] security considerations apply to this mechanism.
|
||||
|
||||
[StringPrep] security considerations and [Unicode] security
|
||||
considerations discussed in [StringPrep] apply to this mechanism.
|
||||
[UTF-8] security considerations also apply.
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
The SASL Mechanism registry [IANA-SASL] entry for the ANONYMOUS
|
||||
mechanism has been updated by the IANA to reflect that this document
|
||||
now provides its technical specification.
|
||||
|
||||
To: iana@iana.org
|
||||
Subject: Updated Registration of SASL mechanism ANONYMOUS
|
||||
|
||||
SASL mechanism name: ANONYMOUS
|
||||
Security considerations: See RFC 4505.
|
||||
Published specification (optional, recommended): RFC 4505
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <Kurt@OpenLDAP.org>
|
||||
Chris Newman <Chris.Newman@sun.com>
|
||||
Intended usage: COMMON
|
||||
Author/Change controller: IESG <iesg@ietf.org>
|
||||
Note: Updates existing entry for ANONYMOUS
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 5]
|
||||
|
||||
RFC 4505 Anonymous SASL Mechanism June 2006
|
||||
|
||||
|
||||
The [StringPrep] profile "trace", first defined in this RFC, has been
|
||||
registered:
|
||||
|
||||
To: iana@iana.org
|
||||
Subject: Initial Registration of Stringprep "trace" profile
|
||||
|
||||
Stringprep profile: trace
|
||||
Published specification: RFC 4505
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@openldap.org>
|
||||
|
||||
7. Acknowledgement
|
||||
|
||||
This document is a revision of RFC 2245 by Chris Newman. Portions of
|
||||
the grammar defined in Section 1 were borrowed from RFC 3629 by
|
||||
Francois Yergeau.
|
||||
|
||||
This document is a product of the IETF SASL WG.
|
||||
|
||||
8. Normative References
|
||||
|
||||
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April
|
||||
2001.
|
||||
|
||||
[SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
|
||||
Authentication and Security Layer (SASL)", RFC 4422,
|
||||
June 2006.
|
||||
|
||||
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
|
||||
Internationalized Strings ('stringprep')", RFC 3454,
|
||||
December 2002.
|
||||
|
||||
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
|
||||
3.2.0" is defined by "The Unicode Standard, Version 3.0"
|
||||
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
|
||||
as amended by the "Unicode Standard Annex #27: Unicode
|
||||
3.1" (http://www.unicode.org/reports/tr27/) and by the
|
||||
"Unicode Standard Annex #28: Unicode 3.2"
|
||||
(http://www.unicode.org/reports/tr28/).
|
||||
|
||||
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
|
||||
10646", RFC 3629 (also STD 63), November 2003.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 6]
|
||||
|
||||
RFC 4505 Anonymous SASL Mechanism June 2006
|
||||
|
||||
|
||||
9. Informative References
|
||||
|
||||
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
||||
4rev1", RFC 3501, March 2003.
|
||||
|
||||
[IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
|
||||
MECHANISMS", <http://www.iana.org/assignments/sasl-
|
||||
mechanisms>.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 7]
|
||||
|
||||
RFC 4505 Anonymous SASL Mechanism June 2006
|
||||
|
||||
|
||||
Appendix A. Changes since RFC 2245
|
||||
|
||||
This appendix is non-normative.
|
||||
|
||||
RFC 2245 allows the client to include optional trace information in
|
||||
the form of a human readable string. RFC 2245 restricted this string
|
||||
to US-ASCII. As the Internet is international, this document uses a
|
||||
string restricted to UTF-8 encoded Unicode characters. A
|
||||
"stringprep" profile is defined to precisely define which Unicode
|
||||
characters are allowed in this string. While the string remains
|
||||
restricted to 255 characters, the encoded length of each character
|
||||
may now range from 1 to 4 octets.
|
||||
|
||||
Additionally, a number of editorial changes were made.
|
||||
|
||||
Editor's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 8]
|
||||
|
||||
RFC 4505 Anonymous SASL Mechanism June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 9]
|
||||
|
||||
1963
docs/rfc/rfc4549.txt
Normal file
1963
docs/rfc/rfc4549.txt
Normal file
File diff suppressed because it is too large
Load Diff
1403
docs/rfc/rfc4551.txt
Normal file
1403
docs/rfc/rfc4551.txt
Normal file
File diff suppressed because it is too large
Load Diff
619
docs/rfc/rfc4616.txt
Normal file
619
docs/rfc/rfc4616.txt
Normal file
@ -0,0 +1,619 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga, Ed.
|
||||
Request for Comments: 4616 OpenLDAP Foundation
|
||||
Updates: 2595 August 2006
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document defines a simple clear-text user/password Simple
|
||||
Authentication and Security Layer (SASL) mechanism called the PLAIN
|
||||
mechanism. The PLAIN mechanism is intended to be used, in
|
||||
combination with data confidentiality services provided by a lower
|
||||
layer, in protocols that lack a simple password authentication
|
||||
command.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 1]
|
||||
|
||||
RFC 4616 The PLAIN SASL Mechanism August 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Clear-text, multiple-use passwords are simple, interoperate with
|
||||
almost all existing operating system authentication databases, and
|
||||
are useful for a smooth transition to a more secure password-based
|
||||
authentication mechanism. The drawback is that they are unacceptable
|
||||
for use over network connections where data confidentiality is not
|
||||
ensured.
|
||||
|
||||
This document defines the PLAIN Simple Authentication and Security
|
||||
Layer ([SASL]) mechanism for use in protocols with no clear-text
|
||||
login command (e.g., [ACAP] or [SMTP-AUTH]). This document updates
|
||||
RFC 2595, replacing Section 6. Changes since RFC 2595 are detailed
|
||||
in Appendix A.
|
||||
|
||||
The name associated with this mechanism is "PLAIN".
|
||||
|
||||
The PLAIN SASL mechanism does not provide a security layer.
|
||||
|
||||
The PLAIN mechanism should not be used without adequate data security
|
||||
protection as this mechanism affords no integrity or confidentiality
|
||||
protections itself. The mechanism is intended to be used with data
|
||||
security protections provided by application-layer protocol,
|
||||
generally through its use of Transport Layer Security ([TLS])
|
||||
services.
|
||||
|
||||
By default, implementations SHOULD advertise and make use of the
|
||||
PLAIN mechanism only when adequate data security services are in
|
||||
place. Specifications for IETF protocols that indicate that this
|
||||
mechanism is an applicable authentication mechanism MUST mandate that
|
||||
implementations support an strong data security service, such as TLS.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [Keywords].
|
||||
|
||||
2. PLAIN SASL Mechanism
|
||||
|
||||
The mechanism consists of a single message, a string of [UTF-8]
|
||||
encoded [Unicode] characters, from the client to the server. The
|
||||
client presents the authorization identity (identity to act as),
|
||||
followed by a NUL (U+0000) character, followed by the authentication
|
||||
identity (identity whose password will be used), followed by a NUL
|
||||
(U+0000) character, followed by the clear-text password. As with
|
||||
other SASL mechanisms, the client does not provide an authorization
|
||||
identity when it wishes the server to derive an identity from the
|
||||
credentials and use that as the authorization identity.
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 2]
|
||||
|
||||
RFC 4616 The PLAIN SASL Mechanism August 2006
|
||||
|
||||
|
||||
The formal grammar for the client message using Augmented BNF [ABNF]
|
||||
follows.
|
||||
|
||||
message = [authzid] UTF8NUL authcid UTF8NUL passwd
|
||||
authcid = 1*SAFE ; MUST accept up to 255 octets
|
||||
authzid = 1*SAFE ; MUST accept up to 255 octets
|
||||
passwd = 1*SAFE ; MUST accept up to 255 octets
|
||||
UTF8NUL = %x00 ; UTF-8 encoded NUL character
|
||||
|
||||
SAFE = UTF1 / UTF2 / UTF3 / UTF4
|
||||
;; any UTF-8 encoded Unicode character except NUL
|
||||
|
||||
UTF1 = %x01-7F ;; except NUL
|
||||
UTF2 = %xC2-DF UTF0
|
||||
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
|
||||
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
|
||||
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
|
||||
%xF4 %x80-8F 2(UTF0)
|
||||
UTF0 = %x80-BF
|
||||
|
||||
The authorization identity (authzid), authentication identity
|
||||
(authcid), password (passwd), and NUL character deliminators SHALL be
|
||||
transferred as [UTF-8] encoded strings of [Unicode] characters. As
|
||||
the NUL (U+0000) character is used as a deliminator, the NUL (U+0000)
|
||||
character MUST NOT appear in authzid, authcid, or passwd productions.
|
||||
|
||||
The form of the authzid production is specific to the application-
|
||||
level protocol's SASL profile [SASL]. The authcid and passwd
|
||||
productions are form-free. Use of non-visible characters or
|
||||
characters that a user may be unable to enter on some keyboards is
|
||||
discouraged.
|
||||
|
||||
Servers MUST be capable of accepting authzid, authcid, and passwd
|
||||
productions up to and including 255 octets. It is noted that the
|
||||
UTF-8 encoding of a Unicode character may be as long as 4 octets.
|
||||
|
||||
Upon receipt of the message, the server will verify the presented (in
|
||||
the message) authentication identity (authcid) and password (passwd)
|
||||
with the system authentication database, and it will verify that the
|
||||
authentication credentials permit the client to act as the (presented
|
||||
or derived) authorization identity (authzid). If both steps succeed,
|
||||
the user is authenticated.
|
||||
|
||||
The presented authentication identity and password strings, as well
|
||||
as the database authentication identity and password strings, are to
|
||||
be prepared before being used in the verification process. The
|
||||
[SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED
|
||||
preparation algorithm. The SASLprep preparation algorithm is
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 3]
|
||||
|
||||
RFC 4616 The PLAIN SASL Mechanism August 2006
|
||||
|
||||
|
||||
recommended to improve the likelihood that comparisons behave in an
|
||||
expected manner. The SASLprep preparation algorithm is not mandatory
|
||||
so as to allow the server to employ other preparation algorithms
|
||||
(including none) when appropriate. For instance, use of a different
|
||||
preparation algorithm may be necessary for the server to interoperate
|
||||
with an external system.
|
||||
|
||||
When preparing the presented strings using [SASLPrep], the presented
|
||||
strings are to be treated as "query" strings (Section 7 of
|
||||
[StringPrep]) and hence unassigned code points are allowed to appear
|
||||
in their prepared output. When preparing the database strings using
|
||||
[SASLPrep], the database strings are to be treated as "stored"
|
||||
strings (Section 7 of [StringPrep]) and hence unassigned code points
|
||||
are prohibited from appearing in their prepared output.
|
||||
|
||||
Regardless of the preparation algorithm used, if the output of a
|
||||
non-invertible function (e.g., hash) of the expected string is
|
||||
stored, the string MUST be prepared before input to that function.
|
||||
|
||||
Regardless of the preparation algorithm used, if preparation fails or
|
||||
results in an empty string, verification SHALL fail.
|
||||
|
||||
When no authorization identity is provided, the server derives an
|
||||
authorization identity from the prepared representation of the
|
||||
provided authentication identity string. This ensures that the
|
||||
derivation of different representations of the authentication
|
||||
identity produces the same authorization identity.
|
||||
|
||||
The server MAY use the credentials to initialize any new
|
||||
authentication database, such as one suitable for [CRAM-MD5] or
|
||||
[DIGEST-MD5].
|
||||
|
||||
3. Pseudo-Code
|
||||
|
||||
This section provides pseudo-code illustrating the verification
|
||||
process (using hashed passwords and the SASLprep preparation
|
||||
function) discussed above. This section is not definitive.
|
||||
|
||||
boolean Verify(string authzid, string authcid, string passwd) {
|
||||
string pAuthcid = SASLprep(authcid, true); # prepare authcid
|
||||
string pPasswd = SASLprep(passwd, true); # prepare passwd
|
||||
if (pAuthcid == NULL || pPasswd == NULL) {
|
||||
return false; # preparation failed
|
||||
}
|
||||
if (pAuthcid == "" || pPasswd == "") {
|
||||
return false; # empty prepared string
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 4]
|
||||
|
||||
RFC 4616 The PLAIN SASL Mechanism August 2006
|
||||
|
||||
|
||||
storedHash = FetchPasswordHash(pAuthcid);
|
||||
if (storedHash == NULL || storedHash == "") {
|
||||
return false; # error or unknown authcid
|
||||
}
|
||||
|
||||
if (!Compare(storedHash, Hash(pPasswd))) {
|
||||
return false; # incorrect password
|
||||
}
|
||||
|
||||
if (authzid == NULL ) {
|
||||
authzid = DeriveAuthzid(pAuthcid);
|
||||
if (authzid == NULL || authzid == "") {
|
||||
return false; # could not derive authzid
|
||||
}
|
||||
}
|
||||
|
||||
if (!Authorize(pAuthcid, authzid)) {
|
||||
return false; # not authorized
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
|
||||
The second parameter of the SASLprep function, when true, indicates
|
||||
that unassigned code points are allowed in the input. When the
|
||||
SASLprep function is called to prepare the password prior to
|
||||
computing the stored hash, the second parameter would be false.
|
||||
|
||||
The second parameter provided to the Authorize function is not
|
||||
prepared by this code. The application-level SASL profile should be
|
||||
consulted to determine what, if any, preparation is necessary.
|
||||
|
||||
Note that the DeriveAuthzid and Authorize functions (whether
|
||||
implemented as one function or two, whether designed in a manner in
|
||||
which these functions or whether the mechanism implementation can be
|
||||
reused elsewhere) require knowledge and understanding of mechanism
|
||||
and the application-level protocol specification and/or
|
||||
implementation details to implement.
|
||||
|
||||
Note that the Authorize function outcome is clearly dependent on
|
||||
details of the local authorization model and policy. Both functions
|
||||
may be dependent on other factors as well.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 5]
|
||||
|
||||
RFC 4616 The PLAIN SASL Mechanism August 2006
|
||||
|
||||
|
||||
4. Examples
|
||||
|
||||
This section provides examples of PLAIN authentication exchanges.
|
||||
The examples are intended to help the readers understand the above
|
||||
text. The examples are not definitive.
|
||||
|
||||
"C:" and "S:" indicate lines sent by the client and server,
|
||||
respectively. "<NUL>" represents a single NUL (U+0000) character.
|
||||
The Application Configuration Access Protocol ([ACAP]) is used in the
|
||||
examples.
|
||||
|
||||
The first example shows how the PLAIN mechanism might be used for
|
||||
user authentication.
|
||||
|
||||
S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
|
||||
C: a001 STARTTLS
|
||||
S: a001 OK "Begin TLS negotiation now"
|
||||
<TLS negotiation, further commands are under TLS layer>
|
||||
S: * ACAP (SASL "CRAM-MD5" "PLAIN")
|
||||
C: a002 AUTHENTICATE "PLAIN"
|
||||
S: + ""
|
||||
C: {21}
|
||||
C: <NUL>tim<NUL>tanstaaftanstaaf
|
||||
S: a002 OK "Authenticated"
|
||||
|
||||
The second example shows how the PLAIN mechanism might be used to
|
||||
attempt to assume the identity of another user. In this example, the
|
||||
server rejects the request. Also, this example makes use of the
|
||||
protocol optional initial response capability to eliminate a round-
|
||||
trip.
|
||||
|
||||
S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
|
||||
C: a001 STARTTLS
|
||||
S: a001 OK "Begin TLS negotiation now"
|
||||
<TLS negotiation, further commands are under TLS layer>
|
||||
S: * ACAP (SASL "CRAM-MD5" "PLAIN")
|
||||
C: a002 AUTHENTICATE "PLAIN" {20+}
|
||||
C: Ursel<NUL>Kurt<NUL>xipj3plmq
|
||||
S: a002 NO "Not authorized to requested authorization identity"
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
As the PLAIN mechanism itself provided no integrity or
|
||||
confidentiality protections, it should not be used without adequate
|
||||
external data security protection, such as TLS services provided by
|
||||
many application-layer protocols. By default, implementations SHOULD
|
||||
NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless
|
||||
adequate data security services are in place.
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 6]
|
||||
|
||||
RFC 4616 The PLAIN SASL Mechanism August 2006
|
||||
|
||||
|
||||
When the PLAIN mechanism is used, the server gains the ability to
|
||||
impersonate the user to all services with the same password
|
||||
regardless of any encryption provided by TLS or other confidentiality
|
||||
protection mechanisms. Whereas many other authentication mechanisms
|
||||
have similar weaknesses, stronger SASL mechanisms address this issue.
|
||||
Clients are encouraged to have an operational mode where all
|
||||
mechanisms that are likely to reveal the user's password to the
|
||||
server are disabled.
|
||||
|
||||
General [SASL] security considerations apply to this mechanism.
|
||||
|
||||
Unicode, [UTF-8], and [StringPrep] security considerations also
|
||||
apply.
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
The SASL Mechanism registry [IANA-SASL] entry for the PLAIN mechanism
|
||||
has been updated by the IANA to reflect that this document now
|
||||
provides its technical specification.
|
||||
|
||||
To: iana@iana.org
|
||||
Subject: Updated Registration of SASL mechanism PLAIN
|
||||
|
||||
SASL mechanism name: PLAIN
|
||||
Security considerations: See RFC 4616.
|
||||
Published specification (optional, recommended): RFC 4616
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@openldap.org>
|
||||
IETF SASL WG <ietf-sasl@imc.org>
|
||||
Intended usage: COMMON
|
||||
Author/Change controller: IESG <iesg@ietf.org>
|
||||
Note: Updates existing entry for PLAIN
|
||||
|
||||
7. Acknowledgements
|
||||
|
||||
This document is a revision of RFC 2595 by Chris Newman. Portions of
|
||||
the grammar defined in Section 2 were borrowed from [UTF-8] by
|
||||
Francois Yergeau.
|
||||
|
||||
This document is a product of the IETF Simple Authentication and
|
||||
Security Layer (SASL) Working Group.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 7]
|
||||
|
||||
RFC 4616 The PLAIN SASL Mechanism August 2006
|
||||
|
||||
|
||||
8. Normative References
|
||||
|
||||
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
|
||||
Syntax Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[Keywords] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[SASL] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
|
||||
Authentication and Security Layer (SASL)", RFC 4422,
|
||||
June 2006.
|
||||
|
||||
[SASLPrep] Zeilenga, K., "SASLprep: Stringprep Profile for User
|
||||
Names and Passwords", RFC 4013, February 2005.
|
||||
|
||||
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
|
||||
Internationalized Strings ("stringprep")", RFC 3454,
|
||||
December 2002.
|
||||
|
||||
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
|
||||
3.2.0" is defined by "The Unicode Standard, Version
|
||||
3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
|
||||
61633-5), as amended by the "Unicode Standard Annex
|
||||
#27: Unicode 3.1"
|
||||
(http://www.unicode.org/reports/tr27/) and by the
|
||||
"Unicode Standard Annex #28: Unicode 3.2"
|
||||
(http://www.unicode.org/reports/tr28/).
|
||||
|
||||
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
|
||||
10646", STD 63, RFC 3629, November 2003.
|
||||
|
||||
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer
|
||||
Security (TLS) Protocol Version 1.1", RFC 4346, April
|
||||
2006.
|
||||
|
||||
9. Informative References
|
||||
|
||||
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
|
||||
Configuration Access Protocol", RFC 2244, November
|
||||
1997.
|
||||
|
||||
[CRAM-MD5] Nerenberg, L., Ed., "The CRAM-MD5 SASL Mechanism", Work
|
||||
in Progress, June 2006.
|
||||
|
||||
[DIGEST-MD5] Melnikov, A., Ed., "Using Digest Authentication as a
|
||||
SASL Mechanism", Work in Progress, June 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 8]
|
||||
|
||||
RFC 4616 The PLAIN SASL Mechanism August 2006
|
||||
|
||||
|
||||
[IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
|
||||
MECHANISMS",
|
||||
<http://www.iana.org/assignments/sasl-mechanisms>.
|
||||
|
||||
[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
|
||||
RFC 2554, March 1999.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 9]
|
||||
|
||||
RFC 4616 The PLAIN SASL Mechanism August 2006
|
||||
|
||||
|
||||
Appendix A. Changes since RFC 2595
|
||||
|
||||
This appendix is non-normative.
|
||||
|
||||
This document replaces Section 6 of RFC 2595.
|
||||
|
||||
The specification details how the server is to compare client-
|
||||
provided character strings with stored character strings.
|
||||
|
||||
The ABNF grammar was updated. In particular, the grammar now allows
|
||||
LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the
|
||||
authzid, authcid, passwd productions. However, whether these control
|
||||
characters may be used depends on the string preparation rules
|
||||
applicable to the production. For passwd and authcid productions,
|
||||
control characters are prohibited. For authzid, one must consult the
|
||||
application-level SASL profile. This change allows PLAIN to carry
|
||||
all possible authorization identity strings allowed in SASL.
|
||||
|
||||
Pseudo-code was added.
|
||||
|
||||
The example section was expanded to illustrate more features of the
|
||||
PLAIN mechanism.
|
||||
|
||||
Editor's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 10]
|
||||
|
||||
RFC 4616 The PLAIN SASL Mechanism August 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 11]
|
||||
|
||||
451
docs/rfc/rfc4731.txt
Normal file
451
docs/rfc/rfc4731.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group A. Melnikov
|
||||
Request for Comments: 4731 Isode Ltd
|
||||
Category: Standards Track D. Cridland
|
||||
Inventure Systems Ltd
|
||||
November 2006
|
||||
|
||||
|
||||
IMAP4 Extension to SEARCH Command for Controlling
|
||||
What Kind of Information Is Returned
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The IETF Trust (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands
|
||||
with several result options, which can control what kind of
|
||||
information is returned. The following result options are defined:
|
||||
minimal value, maximal value, all found messages, and number of found
|
||||
messages.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. Conventions Used in This Document ...............................2
|
||||
3. IMAP Protocol Changes ...........................................2
|
||||
3.1. New SEARCH/UID SEARCH Result Options .......................2
|
||||
3.2. Interaction with CONDSTORE extension .......................4
|
||||
4. Formal Syntax ...................................................5
|
||||
5. Security Considerations .........................................6
|
||||
6. IANA Considerations .............................................6
|
||||
7. Normative References ............................................6
|
||||
8. Acknowledgments .................................................6
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Cridland Standards Track [Page 1]
|
||||
|
||||
RFC 4731 IMAP4 Extension to SEARCH November 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
[IMAPABNF] extended SEARCH and UID SEARCH commands with result
|
||||
specifiers (also known as result options), which can control what
|
||||
kind of information is returned.
|
||||
|
||||
A server advertising the ESEARCH capability supports the following
|
||||
result options: minimal value, maximal value, all found messages,
|
||||
and number of found messages. These result options allow clients to
|
||||
get SEARCH results in more convenient forms, while also saving
|
||||
bandwidth required to transport the results, for example, by finding
|
||||
the first unseen message or returning the number of unseen or deleted
|
||||
messages. Also, when a single MIN or a single MAX result option is
|
||||
specified, servers can optimize execution of SEARCHes.
|
||||
|
||||
2. Conventions Used in This Document
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server, respectively.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in RFC 2119 [KEYWORDS].
|
||||
|
||||
3. IMAP Protocol Changes
|
||||
|
||||
3.1. New SEARCH/UID SEARCH Result Options
|
||||
|
||||
The SEARCH/UID SEARCH commands are extended to allow for the
|
||||
following result options:
|
||||
|
||||
MIN
|
||||
Return the lowest message number/UID that satisfies the SEARCH
|
||||
criteria.
|
||||
|
||||
If the SEARCH results in no matches, the server MUST NOT
|
||||
include the MIN result option in the ESEARCH response; however,
|
||||
it still MUST send the ESEARCH response.
|
||||
|
||||
MAX
|
||||
Return the highest message number/UID that satisfies the SEARCH
|
||||
criteria.
|
||||
|
||||
If the SEARCH results in no matches, the server MUST NOT
|
||||
include the MAX result option in the ESEARCH response; however,
|
||||
it still MUST send the ESEARCH response.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Cridland Standards Track [Page 2]
|
||||
|
||||
RFC 4731 IMAP4 Extension to SEARCH November 2006
|
||||
|
||||
|
||||
ALL
|
||||
Return all message numbers/UIDs that satisfy the SEARCH
|
||||
criteria. Unlike regular (unextended) SEARCH, the messages are
|
||||
always returned using the sequence-set syntax. A sequence-set
|
||||
representation may be more compact and can be used as is in a
|
||||
subsequent command that accepts sequence-set. Note, the client
|
||||
MUST NOT assume that messages/UIDs will be listed in any
|
||||
particular order.
|
||||
|
||||
If the SEARCH results in no matches, the server MUST NOT
|
||||
include the ALL result option in the ESEARCH response; however,
|
||||
it still MUST send the ESEARCH response.
|
||||
|
||||
COUNT
|
||||
Return number of the messages that satisfy the SEARCH criteria.
|
||||
This result option MUST always be included in the ESEARCH
|
||||
response.
|
||||
|
||||
If one or more result options described above are specified, the
|
||||
extended SEARCH command MUST return a single ESEARCH response
|
||||
[IMAPABNF], instead of the SEARCH response.
|
||||
|
||||
An extended UID SEARCH command MUST cause an ESEARCH response with
|
||||
the UID indicator present.
|
||||
|
||||
Note that future extensions to this document can allow servers to
|
||||
return multiple ESEARCH responses for a single extended SEARCH
|
||||
command. These extensions will have to describe how results from
|
||||
multiple ESEARCH responses are to be amalgamated.
|
||||
|
||||
If the list of result options is empty, that requests the server to
|
||||
return an ESEARCH response instead of the SEARCH response. This is
|
||||
equivalent to "(ALL)".
|
||||
|
||||
Example: C: A282 SEARCH RETURN (MIN COUNT) FLAGGED
|
||||
SINCE 1-Feb-1994 NOT FROM "Smith"
|
||||
S: * ESEARCH (TAG "A282") MIN 2 COUNT 3
|
||||
S: A282 OK SEARCH completed
|
||||
|
||||
Example: C: A283 SEARCH RETURN () FLAGGED
|
||||
SINCE 1-Feb-1994 NOT FROM "Smith"
|
||||
S: * ESEARCH (TAG "A283") ALL 2,10:11
|
||||
S: A283 OK SEARCH completed
|
||||
|
||||
The following example demonstrates finding the first unseen message
|
||||
as returned in the UNSEEN response code on a successful SELECT
|
||||
command:
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Cridland Standards Track [Page 3]
|
||||
|
||||
RFC 4731 IMAP4 Extension to SEARCH November 2006
|
||||
|
||||
|
||||
Example: C: A284 SEARCH RETURN (MIN) UNSEEN
|
||||
S: * ESEARCH (TAG "A284") MIN 4
|
||||
S: A284 OK SEARCH completed
|
||||
|
||||
The following example demonstrates that if the ESEARCH UID indicator
|
||||
is present, all data in the ESEARCH response is referring to UIDs;
|
||||
for example, the MIN result specifier will be followed by a UID.
|
||||
|
||||
Example: C: A285 UID SEARCH RETURN (MIN MAX) 1:5000
|
||||
S: * ESEARCH (TAG "A285") UID MIN 7 MAX 3800
|
||||
S: A285 OK SEARCH completed
|
||||
|
||||
The following example demonstrates returning the number of deleted
|
||||
messages:
|
||||
|
||||
Example: C: A286 SEARCH RETURN (COUNT) DELETED
|
||||
S: * ESEARCH (TAG "A286") COUNT 15
|
||||
S: A286 OK SEARCH completed
|
||||
|
||||
3.2. Interaction with CONDSTORE extension
|
||||
|
||||
When the server supports both the ESEARCH and the CONDSTORE
|
||||
[CONDSTORE] extension, and the client requests one or more result
|
||||
option described in section 3.1 together with the MODSEQ search
|
||||
criterion in the same SEARCH/UID SEARCH command, then the server MUST
|
||||
return the ESEARCH response containing the MODSEQ result option
|
||||
(described in the following paragraph) instead of the extended SEARCH
|
||||
response described in section 3.5 of [CONDSTORE].
|
||||
|
||||
If the SEARCH/UID SEARCH command contained a single MIN or MAX result
|
||||
option, the MODSEQ result option contains the mod-sequence for the
|
||||
found message. If the SEARCH/UID SEARCH command contained both MIN
|
||||
and MAX result options and no ALL/COUNT option, the MODSEQ result
|
||||
option contains the highest mod-sequence for the two returned
|
||||
messages. Otherwise the MODSEQ result option contains the highest
|
||||
mod-sequence for all messages being returned.
|
||||
|
||||
Example: The following example demonstrates how Example 15 from
|
||||
[CONDSTORE] would look in the presence of one or more result option:
|
||||
|
||||
C: a1 SEARCH RETURN (MIN) MODSEQ "/flags/\\draft"
|
||||
all 620162338
|
||||
S: * ESEARCH (TAG "a1") MIN 2 MODSEQ 917162488
|
||||
S: a1 OK Search complete
|
||||
|
||||
C: a2 SEARCH RETURN (MAX) MODSEQ "/flags/\\draft"
|
||||
all 620162338
|
||||
S: * ESEARCH (TAG "a2") MAX 23 MODSEQ 907162321
|
||||
|
||||
|
||||
|
||||
Melnikov & Cridland Standards Track [Page 4]
|
||||
|
||||
RFC 4731 IMAP4 Extension to SEARCH November 2006
|
||||
|
||||
|
||||
S: a2 OK Search complete
|
||||
|
||||
C: a3 SEARCH RETURN (MIN MAX) MODSEQ "/flags/\\draft"
|
||||
all 620162338
|
||||
S: * ESEARCH (TAG "a3") MIN 2 MAX 23 MODSEQ 917162488
|
||||
S: a3 OK Search complete
|
||||
|
||||
C: a4 SEARCH RETURN (MIN COUNT) MODSEQ "/flags/\\draft"
|
||||
all 620162338
|
||||
S: * ESEARCH (TAG "a4") MIN 2 COUNT 10 MODSEQ 917162500
|
||||
S: a4 OK Search complete
|
||||
|
||||
4. Formal Syntax
|
||||
|
||||
The following syntax specification uses the Augmented Backus-Naur
|
||||
Form (ABNF) notation as specified in [ABNF].
|
||||
|
||||
Non-terminals referenced but not defined below are as defined by
|
||||
[IMAP4], [CONDSTORE], or [IMAPABNF].
|
||||
|
||||
Except as noted otherwise, all alphabetic characters are case-
|
||||
insensitive. The use of upper or lowercase characters to define
|
||||
token strings is for editorial clarity only. Implementations MUST
|
||||
accept these strings in a case-insensitive fashion.
|
||||
|
||||
capability =/ "ESEARCH"
|
||||
|
||||
search-return-data = "MIN" SP nz-number /
|
||||
"MAX" SP nz-number /
|
||||
"ALL" SP sequence-set /
|
||||
"COUNT" SP number
|
||||
;; conforms to the generic
|
||||
;; search-return-data syntax defined
|
||||
;; in [IMAPABNF]
|
||||
|
||||
search-return-opt = "MIN" / "MAX" / "ALL" / "COUNT"
|
||||
;; conforms to generic search-return-opt
|
||||
;; syntax defined in [IMAPABNF]
|
||||
|
||||
When the CONDSTORE [CONDSTORE] IMAP extension is also supported,
|
||||
the ABNF is updated as follows:
|
||||
|
||||
search-return-data =/ "MODSEQ" SP mod-sequence-value
|
||||
;; mod-sequence-value is defined
|
||||
;; in [CONDSTORE]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Cridland Standards Track [Page 5]
|
||||
|
||||
RFC 4731 IMAP4 Extension to SEARCH November 2006
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
In the general case, the IMAP SEARCH/UID SEARCH commands can be CPU
|
||||
and/or IO intensive, and are seen by some as a potential attack point
|
||||
for denial of service attacks, so some sites/implementations even
|
||||
disable them entirely. This is quite unfortunate, as SEARCH command
|
||||
is one of the best examples demonstrating IMAP advantage over POP3.
|
||||
|
||||
The ALL and COUNT return options don't change how SEARCH is working
|
||||
internally; they only change how information about found messages is
|
||||
returned. MIN and MAX SEARCH result options described in this
|
||||
document can lighten the load on IMAP servers that choose to optimize
|
||||
SEARCHes containing only one or both of them.
|
||||
|
||||
It is believed that this extension doesn't raise any additional
|
||||
security concerns not already discussed in [IMAP4].
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
IMAP4 capabilities are registered by publishing a standards track RFC
|
||||
or an IESG-approved experimental RFC. The registry is currently
|
||||
located at <http://www.iana.org/assignments/imap4-capabilities>.
|
||||
|
||||
This document defines the ESEARCH IMAP capability, which IANA added
|
||||
to the registry.
|
||||
|
||||
7. Normative References
|
||||
|
||||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
||||
4rev1", RFC 3501, March 2003.
|
||||
|
||||
[ABNF] Crocker, D. (Ed.) and P. Overell , "Augmented BNF for
|
||||
Syntax Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
|
||||
ABNF", RFC 4466, April 2006..
|
||||
|
||||
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
|
||||
STORE", RFC 4551, June 2006.
|
||||
|
||||
8. Acknowledgments
|
||||
|
||||
Thanks to Michael Wener, Arnt Gulbrandsen, Cyrus Daboo, Mark Crispin,
|
||||
and Pete Maclean for comments and corrections.
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Cridland Standards Track [Page 6]
|
||||
|
||||
RFC 4731 IMAP4 Extension to SEARCH November 2006
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Alexey Melnikov
|
||||
Isode Limited
|
||||
5 Castle Business Village
|
||||
36 Station Road
|
||||
Hampton, Middlesex, TW12 2BX
|
||||
UK
|
||||
|
||||
EMail: Alexey.Melnikov@isode.com
|
||||
|
||||
|
||||
Dave A. Cridland
|
||||
Inventure Systems Limited
|
||||
|
||||
EMail: dave.cridland@inventuresystems.co.uk
|
||||
URL: http://invsys.co.uk/dave/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Cridland Standards Track [Page 7]
|
||||
|
||||
RFC 4731 IMAP4 Extension to SEARCH November 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The IETF Trust (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
|
||||
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
|
||||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
|
||||
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
|
||||
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
|
||||
PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Cridland Standards Track [Page 8]
|
||||
|
||||
563
docs/rfc/rfc4752.txt
Normal file
563
docs/rfc/rfc4752.txt
Normal file
@ -0,0 +1,563 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group A. Melnikov, Ed.
|
||||
Request for Comments: 4752 Isode
|
||||
Obsoletes: 2222 November 2006
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
The Kerberos V5 ("GSSAPI")
|
||||
Simple Authentication and Security Layer (SASL) Mechanism
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The IETF Trust (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
The Simple Authentication and Security Layer (SASL) is a framework
|
||||
for adding authentication support to connection-based protocols.
|
||||
This document describes the method for using the Generic Security
|
||||
Service Application Program Interface (GSS-API) Kerberos V5 in the
|
||||
SASL.
|
||||
|
||||
This document replaces Section 7.2 of RFC 2222, the definition of the
|
||||
"GSSAPI" SASL mechanism. This document, together with RFC 4422,
|
||||
obsoletes RFC 2222.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 1]
|
||||
|
||||
RFC 4752 SASL GSSAPI Mechanism November 2006
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
1.1. Relationship to Other Documents ............................2
|
||||
2. Conventions Used in This Document ...............................2
|
||||
3. Kerberos V5 GSS-API Mechanism ...................................2
|
||||
3.1. Client Side of Authentication Protocol Exchange ............3
|
||||
3.2. Server Side of Authentication Protocol Exchange ............4
|
||||
3.3. Security Layer .............................................6
|
||||
4. IANA Considerations .............................................7
|
||||
5. Security Considerations .........................................7
|
||||
6. Acknowledgements ................................................8
|
||||
7. Changes since RFC 2222 ..........................................8
|
||||
8. References ......................................................8
|
||||
8.1. Normative References .......................................8
|
||||
8.2. Informative References .....................................9
|
||||
|
||||
1. Introduction
|
||||
|
||||
This specification documents currently deployed Simple Authentication
|
||||
and Security Layer (SASL [SASL]) mechanism supporting the Kerberos V5
|
||||
[KERBEROS] Generic Security Service Application Program Interface
|
||||
([GSS-API]) mechanism [RFC4121]. The authentication sequence is
|
||||
described in Section 3. Note that the described authentication
|
||||
sequence has known limitations, in particular, it lacks channel
|
||||
bindings and the number of round-trips required to complete
|
||||
authentication exchange is not minimal. SASL WG is working on a
|
||||
separate document that should address these limitations.
|
||||
|
||||
1.1. Relationship to Other Documents
|
||||
|
||||
This document, together with RFC 4422, obsoletes RFC 2222 in its
|
||||
entirety. This document replaces Section 7.2 of RFC 2222. The
|
||||
remainder is obsoleted as detailed in Section 1.2 of RFC 4422.
|
||||
|
||||
2. Conventions Used in This Document
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
|
||||
in this document are to be interpreted as defined in "Key words for
|
||||
use in RFCs to Indicate Requirement Levels" [KEYWORDS].
|
||||
|
||||
3. Kerberos V5 GSS-API Mechanism
|
||||
|
||||
The SASL mechanism name for the Kerberos V5 GSS-API mechanism
|
||||
[RFC4121] is "GSSAPI". Though known as the SASL GSSAPI mechanism,
|
||||
the mechanism is specifically tied to Kerberos V5 and GSS-API's
|
||||
Kerberos V5 mechanism.
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 2]
|
||||
|
||||
RFC 4752 SASL GSSAPI Mechanism November 2006
|
||||
|
||||
|
||||
The GSSAPI SASL mechanism is a "client goes first" SASL mechanism;
|
||||
i.e., it starts with the client sending a "response" created as
|
||||
described in the following section.
|
||||
|
||||
The implementation MAY set any GSS-API flags or arguments not
|
||||
mentioned in this specification as is necessary for the
|
||||
implementation to enforce its security policy.
|
||||
|
||||
Note that major status codes returned by GSS_Init_sec_context() or
|
||||
GSS_Accept_sec_context() other than GSS_S_COMPLETE or
|
||||
GSS_S_CONTINUE_NEEDED cause authentication failure. Major status
|
||||
codes returned by GSS_Unwrap() other than GSS_S_COMPLETE (without any
|
||||
additional supplementary status codes) cause authentication and/or
|
||||
security layer failure.
|
||||
|
||||
3.1. Client Side of Authentication Protocol Exchange
|
||||
|
||||
The client calls GSS_Init_sec_context, passing in
|
||||
input_context_handle of 0 (initially), mech_type of the Kerberos V5
|
||||
GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name
|
||||
equal to output_name from GSS_Import_Name called with input_name_type
|
||||
of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
|
||||
"service@hostname" where "service" is the service name specified in
|
||||
the protocol's profile, and "hostname" is the fully qualified host
|
||||
name of the server. When calling the GSS_Init_sec_context, the
|
||||
client MUST pass the integ_req_flag of TRUE (**). If the client will
|
||||
be requesting a security layer, it MUST also supply to the
|
||||
GSS_Init_sec_context a mutual_req_flag of TRUE, and a
|
||||
sequence_req_flag of TRUE. If the client will be requesting a
|
||||
security layer providing confidentiality protection, it MUST also
|
||||
supply to the GSS_Init_sec_context a conf_req_flag of TRUE. The
|
||||
client then responds with the resulting output_token. If
|
||||
GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
|
||||
should expect the server to issue a token in a subsequent challenge.
|
||||
The client must pass the token to another call to
|
||||
GSS_Init_sec_context, repeating the actions in this paragraph.
|
||||
|
||||
(*) Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE
|
||||
to import servers' acceptor names, but only when they have a priori
|
||||
knowledge that the servers support alternate name types. Otherwise
|
||||
clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor
|
||||
names.
|
||||
|
||||
(**) Note that RFC 2222 [RFC2222] implementations will not work with
|
||||
GSS-API implementations that require integ_req_flag to be true. No
|
||||
implementations of RFC 1964 [KRB5GSS] or RFC 4121 [RFC4121] that
|
||||
require integ_req_flag to be true are believed to exist and it is
|
||||
expected that any future update to [RFC4121] will require that
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 3]
|
||||
|
||||
RFC 4752 SASL GSSAPI Mechanism November 2006
|
||||
|
||||
|
||||
integrity be available even in not explicitly requested by the
|
||||
application.
|
||||
|
||||
When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines
|
||||
the context to ensure that it provides a level of protection
|
||||
permitted by the client's security policy. In particular, if the
|
||||
integ_avail flag is not set in the context, then no security layer
|
||||
can be offered or accepted.
|
||||
|
||||
If the conf_avail flag is not set in the context, then no security
|
||||
layer with confidentiality can be offered or accepted. If the
|
||||
context is acceptable, the client takes the following actions: If the
|
||||
last call to GSS_Init_sec_context returned an output_token, then the
|
||||
client responds with the output_token, otherwise the client responds
|
||||
with no data. The client should then expect the server to issue a
|
||||
token in a subsequent challenge. The client passes this token to
|
||||
GSS_Unwrap and interprets the first octet of resulting cleartext as a
|
||||
bit-mask specifying the security layers supported by the server and
|
||||
the second through fourth octets as the maximum size output_message
|
||||
the server is able to receive (in network byte order). If the
|
||||
resulting cleartext is not 4 octets long, the client fails the
|
||||
negotiation. The client verifies that the server maximum buffer is 0
|
||||
if the server does not advertise support for any security layer.
|
||||
|
||||
The client then constructs data, with the first octet containing the
|
||||
bit-mask specifying the selected security layer, the second through
|
||||
fourth octets containing in network byte order the maximum size
|
||||
output_message the client is able to receive (which MUST be 0 if the
|
||||
client does not support any security layer), and the remaining octets
|
||||
containing the UTF-8 [UTF8] encoded authorization identity.
|
||||
(Implementation note: The authorization identity is not terminated
|
||||
with the zero-valued (%x00) octet (e.g., the UTF-8 encoding of the
|
||||
NUL (U+0000) character)). The client passes the data to GSS_Wrap
|
||||
with conf_flag set to FALSE and responds with the generated
|
||||
output_message. The client can then consider the server
|
||||
authenticated.
|
||||
|
||||
3.2. Server Side of Authentication Protocol Exchange
|
||||
|
||||
A server MUST NOT advertise support for the "GSSAPI" SASL mechanism
|
||||
described in this document unless it has acceptor credential for the
|
||||
Kerberos V GSS-API mechanism [KRB5GSS].
|
||||
|
||||
The server passes the initial client response to
|
||||
GSS_Accept_sec_context as input_token, setting input_context_handle
|
||||
to 0 (initially), chan_binding of NULL, and a suitable
|
||||
acceptor_cred_handle (see below). If GSS_Accept_sec_context returns
|
||||
GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 4]
|
||||
|
||||
RFC 4752 SASL GSSAPI Mechanism November 2006
|
||||
|
||||
|
||||
to the client in challenge and passes the resulting response to
|
||||
another call to GSS_Accept_sec_context, repeating the actions in this
|
||||
paragraph.
|
||||
|
||||
Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
|
||||
or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the Object
|
||||
Identifier (OID) of the Kerberos V5 GSS-API mechanism [KRB5GSS](*).
|
||||
Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle.
|
||||
Servers MAY use a credential obtained by calling GSS_Acquire_cred or
|
||||
GSS_Add_cred for the server's principal name(s) (**) and the Kerberos
|
||||
V5 GSS-API mechanism [KRB5GSS].
|
||||
|
||||
(*) Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of GSS-
|
||||
API mechanism as an input parameter. The OID set can be created by
|
||||
using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can be
|
||||
freed by calling the GSS_Release_oid_set.
|
||||
|
||||
|
||||
(**) Use of server's principal names having
|
||||
GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
|
||||
where "service" is the service name specified in the protocol's
|
||||
profile, and "hostname" is the fully qualified host name of the
|
||||
server, is RECOMMENDED. The server name is generated by calling
|
||||
GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE
|
||||
and input_name_string of "service@hostname".
|
||||
|
||||
Upon successful establishment of the security context (i.e.,
|
||||
GSS_Accept_sec_context returns GSS_S_COMPLETE), the server SHOULD
|
||||
verify that the negotiated GSS-API mechanism is indeed Kerberos V5
|
||||
[KRB5GSS]. This is done by examining the value of the mech_type
|
||||
parameter returned from the GSS_Accept_sec_context call. If the
|
||||
value differs, SASL authentication MUST be aborted.
|
||||
|
||||
Upon successful establishment of the security context and if the
|
||||
server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
|
||||
credential handle, the server SHOULD also check using the
|
||||
GSS_Inquire_context that the target_name used by the client matches
|
||||
either
|
||||
|
||||
- the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
|
||||
where "service" is the service name specified in the application
|
||||
protocol's profile,
|
||||
|
||||
or
|
||||
|
||||
- the GSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS] name syntax for a two-
|
||||
component principal where the first component matches the service
|
||||
name specified in the application protocol's profile.
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 5]
|
||||
|
||||
RFC 4752 SASL GSSAPI Mechanism November 2006
|
||||
|
||||
|
||||
When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
|
||||
examines the context to ensure that it provides a level of protection
|
||||
permitted by the server's security policy. In particular, if the
|
||||
integ_avail flag is not set in the context, then no security layer
|
||||
can be offered or accepted. If the conf_avail flag is not set in the
|
||||
context, then no security layer with confidentiality can be offered
|
||||
or accepted.
|
||||
|
||||
If the context is acceptable, the server takes the following actions:
|
||||
If the last call to GSS_Accept_sec_context returned an output_token,
|
||||
the server returns it to the client in a challenge and expects a
|
||||
reply from the client with no data. Whether or not an output_token
|
||||
was returned (and after receipt of any response from the client to
|
||||
such an output_token), the server then constructs 4 octets of data,
|
||||
with the first octet containing a bit-mask specifying the security
|
||||
layers supported by the server and the second through fourth octets
|
||||
containing in network byte order the maximum size output_token the
|
||||
server is able to receive (which MUST be 0 if the server does not
|
||||
support any security layer). The server must then pass the plaintext
|
||||
to GSS_Wrap with conf_flag set to FALSE and issue the generated
|
||||
output_message to the client in a challenge.
|
||||
|
||||
The server must then pass the resulting response to GSS_Unwrap and
|
||||
interpret the first octet of resulting cleartext as the bit-mask for
|
||||
the selected security layer, the second through fourth octets as the
|
||||
maximum size output_message the client is able to receive (in network
|
||||
byte order), and the remaining octets as the authorization identity.
|
||||
The server verifies that the client has selected a security layer
|
||||
that was offered and that the client maximum buffer is 0 if no
|
||||
security layer was chosen. The server must verify that the src_name
|
||||
is authorized to act as the authorization identity. After these
|
||||
verifications, the authentication process is complete. The server is
|
||||
not expected to return any additional data with the success
|
||||
indicator.
|
||||
|
||||
3.3. Security Layer
|
||||
|
||||
The security layers and their corresponding bit-masks are as follows:
|
||||
|
||||
1 No security layer
|
||||
2 Integrity protection.
|
||||
Sender calls GSS_Wrap with conf_flag set to FALSE
|
||||
4 Confidentiality protection.
|
||||
Sender calls GSS_Wrap with conf_flag set to TRUE
|
||||
|
||||
Other bit-masks may be defined in the future; bits that are not
|
||||
understood must be negotiated off.
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 6]
|
||||
|
||||
RFC 4752 SASL GSSAPI Mechanism November 2006
|
||||
|
||||
|
||||
When decoding any received data with GSS_Unwrap, the major_status
|
||||
other than the GSS_S_COMPLETE MUST be treated as a fatal error.
|
||||
|
||||
Note that SASL negotiates the maximum size of the output_message to
|
||||
send. Implementations can use the GSS_Wrap_size_limit call to
|
||||
determine the corresponding maximum size input_message.
|
||||
|
||||
4. IANA Considerations
|
||||
|
||||
IANA modified the existing registration for "GSSAPI" as follows:
|
||||
|
||||
Family of SASL mechanisms: NO
|
||||
|
||||
SASL mechanism name: GSSAPI
|
||||
|
||||
Security considerations: See Section 5 of RFC 4752
|
||||
|
||||
Published specification: RFC 4752
|
||||
|
||||
Person & email address to contact for further information:
|
||||
Alexey Melnikov <Alexey.Melnikov@isode.com>
|
||||
|
||||
Intended usage: COMMON
|
||||
|
||||
Owner/Change controller: iesg@ietf.org
|
||||
|
||||
Additional information: This mechanism is for the Kerberos V5
|
||||
mechanism of GSS-API.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Security issues are discussed throughout this memo.
|
||||
|
||||
When constructing the input_name_string, the client SHOULD NOT
|
||||
canonicalize the server's fully qualified domain name using an
|
||||
insecure or untrusted directory service.
|
||||
|
||||
For compatibility with deployed software, this document requires that
|
||||
the chan_binding (channel bindings) parameter to GSS_Init_sec_context
|
||||
and GSS_Accept_sec_context be NULL, hence disallowing use of GSS-API
|
||||
support for channel bindings. GSS-API channel bindings in SASL is
|
||||
expected to be supported via a new GSS-API family of SASL mechanisms
|
||||
(to be introduced in a future document).
|
||||
|
||||
Additional security considerations are in the [SASL] and [GSS-API]
|
||||
specifications. Additional security considerations for the GSS-API
|
||||
mechanism can be found in [KRB5GSS] and [KERBEROS].
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 7]
|
||||
|
||||
RFC 4752 SASL GSSAPI Mechanism November 2006
|
||||
|
||||
|
||||
6. Acknowledgements
|
||||
|
||||
This document replaces Section 7.2 of RFC 2222 [RFC2222] by John G.
|
||||
Myers. He also contributed significantly to this revision.
|
||||
|
||||
Lawrence Greenfield converted text of this document to the XML
|
||||
format.
|
||||
|
||||
Contributions of many members of the SASL mailing list are gratefully
|
||||
acknowledged, in particular comments from Chris Newman, Nicolas
|
||||
Williams, Jeffrey Hutzelman, Sam Hartman, Mark Crispin, and Martin
|
||||
Rex.
|
||||
|
||||
7. Changes since RFC 2222
|
||||
|
||||
RFC 2078 [RFC2078] specifies the version of GSS-API used by RFC 2222
|
||||
[RFC2222], which provided the original version of this specification.
|
||||
That version of GSS-API did not provide the integ_integ_avail flag as
|
||||
an input to GSS_Init_sec_context. Instead, integrity was always
|
||||
requested. RFC 4422 [SASL] requires that when possible, the security
|
||||
layer negotiation be integrity protected. To meet this requirement
|
||||
and as part of moving from RFC 2078 [RFC2078] to RFC 2743 [GSS-API],
|
||||
this specification requires that clients request integrity from
|
||||
GSS_Init_sec_context so they can use GSS_Wrap to protect the security
|
||||
layer negotiation. This specification does not require that the
|
||||
mechanism offer the integrity security layer, simply that the
|
||||
security layer negotiation be wrapped.
|
||||
|
||||
8. References
|
||||
|
||||
8.1. Normative References
|
||||
|
||||
[GSS-API] Linn, J., "Generic Security Service Application Program
|
||||
Interface Version 2, Update 1", RFC 2743, January 2000.
|
||||
|
||||
[KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
|
||||
Kerberos Network Authentication Service (V5)", RFC 4120,
|
||||
July 2005.
|
||||
|
||||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
|
||||
1964, June 1996.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 8]
|
||||
|
||||
RFC 4752 SASL GSSAPI Mechanism November 2006
|
||||
|
||||
|
||||
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
|
||||
Version 5 Generic Security Service Application Program
|
||||
Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
|
||||
2005.
|
||||
|
||||
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
|
||||
Security Layer (SASL)", RFC 4422, June 2006.
|
||||
|
||||
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
|
||||
10646", STD 63, RFC 3629, November 2003.
|
||||
|
||||
8.2. Informative References
|
||||
|
||||
[RFC2078] Linn, J., "Generic Security Service Application Program
|
||||
Interface, Version 2", RFC 2078, January 1997.
|
||||
|
||||
[RFC2222] Myers, J., "Simple Authentication and Security Layer
|
||||
(SASL)", RFC 2222, October 1997.
|
||||
|
||||
Editor's Address
|
||||
|
||||
Alexey Melnikov
|
||||
Isode Limited
|
||||
5 Castle Business Village
|
||||
36 Station Road
|
||||
Hampton, Middlesex TW12 2BX
|
||||
UK
|
||||
|
||||
EMail: Alexey.Melnikov@isode.com
|
||||
URI: http://www.melnikov.ca/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 9]
|
||||
|
||||
RFC 4752 SASL GSSAPI Mechanism November 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The IETF Trust (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
|
||||
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
|
||||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
|
||||
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
|
||||
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
|
||||
PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov Standards Track [Page 10]
|
||||
|
||||
1459
docs/rfc/rfc4790.txt
Normal file
1459
docs/rfc/rfc4790.txt
Normal file
File diff suppressed because it is too large
Load Diff
395
docs/rfc/rfc4959.txt
Normal file
395
docs/rfc/rfc4959.txt
Normal file
@ -0,0 +1,395 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group R. Siemborski
|
||||
Request for Comments: 4959 Google, Inc.
|
||||
Category: Standards Track A. Gulbrandsen
|
||||
Oryx Mail Systems GmbH
|
||||
September 2007
|
||||
|
||||
|
||||
IMAP Extension for Simple Authentication and Security Layer (SASL)
|
||||
Initial Client Response
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
To date, the Internet Message Access Protocol (IMAP) has used a
|
||||
Simple Authentication and Security Layer (SASL) profile which always
|
||||
required at least one complete round trip for an authentication, as
|
||||
it did not support an initial client response argument. This
|
||||
additional round trip at the beginning of the session is undesirable,
|
||||
especially when round-trip costs are high.
|
||||
|
||||
This document defines an extension to IMAP which allows clients and
|
||||
servers to avoid this round trip by allowing an initial client
|
||||
response argument to the IMAP AUTHENTICATE command.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Siemborski & Gulbrandsen Standards Track [Page 1]
|
||||
|
||||
RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The SASL initial client response extension is present in any IMAP
|
||||
[RFC3501] server implementation which returns "SASL-IR" as one of the
|
||||
supported capabilities in its CAPABILITY response.
|
||||
|
||||
Servers which support this extension will accept an optional initial
|
||||
client response with the AUTHENTICATE command for any SASL [RFC4422]
|
||||
mechanisms which support it.
|
||||
|
||||
2. Conventions Used in This Document
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server, respectively.
|
||||
|
||||
Formal syntax is defined by [RFC4234] as extended by [RFC3501].
|
||||
|
||||
3. IMAP Changes to the IMAP AUTHENTICATE Command
|
||||
|
||||
This extension adds an optional second argument to the AUTHENTICATE
|
||||
command that is defined in Section 6.2.2 of [RFC3501]. If this
|
||||
second argument is present, it represents the contents of the
|
||||
"initial client response" defined in Section 5.1 of [RFC4422].
|
||||
|
||||
As with any other client response, this initial client response MUST
|
||||
be encoded as defined in Section 4 of [RFC4648]. It also MUST be
|
||||
transmitted outside of a quoted string or literal. To send a zero-
|
||||
length initial response, the client MUST send a single pad character
|
||||
("="). This indicates that the response is present, but is a zero-
|
||||
length string.
|
||||
|
||||
When decoding the BASE64 [RFC4648] data in the initial client
|
||||
response, decoding errors MUST be treated as IMAP [RFC3501] would
|
||||
handle them in any normal SASL client response. In particular, the
|
||||
server should check for any characters not explicitly allowed by the
|
||||
BASE64 alphabet, as well as any sequence of BASE64 characters that
|
||||
contains the pad character ('=') anywhere other than the end of the
|
||||
string (e.g., "=AAA" and "AAA=BBB" are not allowed).
|
||||
|
||||
If the client uses an initial response with a SASL mechanism that
|
||||
does not support an initial response, the server MUST reject the
|
||||
command with a tagged BAD response.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Siemborski & Gulbrandsen Standards Track [Page 2]
|
||||
|
||||
RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
||||
|
||||
|
||||
Note: support and use of the initial client response is optional for
|
||||
both clients and servers. Servers that implement this extension MUST
|
||||
support clients that omit the initial client response, and clients
|
||||
that implement this extension MUST NOT send an initial client
|
||||
response to servers that do not advertise the SASL-IR capability. In
|
||||
such a situation, clients MUST fall back to an IMAP [RFC3501]
|
||||
compatible mode.
|
||||
|
||||
If either the client or the server do not support the SASL-IR
|
||||
capability, a mechanism which uses an initial client response is
|
||||
negotiated using the challenge/response exchange described in
|
||||
[RFC3501], with an initial zero-length server challenge.
|
||||
|
||||
4. Examples
|
||||
|
||||
The following is an example authentication using the PLAIN (see
|
||||
[RFC4616]) SASL mechanism (under a TLS protection layer, see
|
||||
[RFC4346]) and an initial client response:
|
||||
|
||||
... client connects to server and negotiates a TLS
|
||||
protection layer ...
|
||||
C: C01 CAPABILITY
|
||||
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
|
||||
S: C01 OK Completed
|
||||
C: A01 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
|
||||
S: A01 OK Success (tls protection)
|
||||
|
||||
Note that even when a server supports this extension, the following
|
||||
negotiation (which does not use the initial response) is still valid
|
||||
and MUST be supported by the server:
|
||||
|
||||
... client connects to server and negotiates a TLS
|
||||
protection layer ...
|
||||
C: C01 CAPABILITY
|
||||
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
|
||||
S: C01 OK Completed
|
||||
C: A01 AUTHENTICATE PLAIN
|
||||
(note that there is a space following the "+" in the
|
||||
following line)
|
||||
S: +
|
||||
C: dGVzdAB0ZXN0AHRlc3Q=
|
||||
S: A01 OK Success (tls protection)
|
||||
|
||||
The following is an example authentication using the SASL EXTERNAL
|
||||
mechanism (defined in [RFC4422]) under a TLS protection layer (see
|
||||
[RFC4346]) and an empty initial client response:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Siemborski & Gulbrandsen Standards Track [Page 3]
|
||||
|
||||
RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
||||
|
||||
|
||||
... client connects to server and negotiates a TLS
|
||||
protection layer ...
|
||||
C: C01 CAPABILITY
|
||||
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
|
||||
S: C01 OK Completed
|
||||
C: A01 AUTHENTICATE EXTERNAL =
|
||||
S: A01 OK Success (tls protection)
|
||||
|
||||
This is in contrast with the handling of such a situation when an
|
||||
initial response is omitted:
|
||||
|
||||
... client connects to server and negotiates a TLS protection
|
||||
layer ...
|
||||
C: C01 CAPABILITY
|
||||
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
|
||||
S: C01 OK Completed
|
||||
C: A01 AUTHENTICATE EXTERNAL
|
||||
(note that there is a space following the "+" in the
|
||||
following line)
|
||||
S: +
|
||||
C:
|
||||
S: A01 OK Success (tls protection)
|
||||
|
||||
5. IANA Considerations
|
||||
|
||||
The IANA has added SASL-IR to the IMAP4 Capabilities Registry.
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
The extension defined in this document is subject to many of the
|
||||
Security Considerations defined in [RFC3501] and [RFC4422].
|
||||
|
||||
Server implementations MUST treat the omission of an initial client
|
||||
response from the AUTHENTICATE command as defined by [RFC3501] (as if
|
||||
this extension did not exist).
|
||||
|
||||
Although [RFC3501] has no express line length limitations, some
|
||||
implementations choose to enforce them anyway. Such implementations
|
||||
MUST be aware that the addition of the initial response parameter to
|
||||
AUTHENTICATE may increase the maximum line length that IMAP parsers
|
||||
may expect to support. Server implementations MUST be able to
|
||||
receive the largest possible initial client response that their
|
||||
supported mechanisms might receive.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Siemborski & Gulbrandsen Standards Track [Page 4]
|
||||
|
||||
RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
||||
|
||||
|
||||
7. Formal Syntax
|
||||
|
||||
The following syntax specification uses the Augmented Backus-Naur
|
||||
Form [RFC4234] notation. [RFC3501] defines the non-terminals
|
||||
capability, auth-type, and base64.
|
||||
|
||||
capability =/ "SASL-IR"
|
||||
|
||||
authenticate = "AUTHENTICATE" SP auth-type [SP (base64 / "=")]
|
||||
*(CRLF base64)
|
||||
;;redefine AUTHENTICATE from [RFC3501]
|
||||
|
||||
8. Acknowledgments
|
||||
|
||||
The authors would like to acknowledge the contributions of Ken
|
||||
Murchison and Mark Crispin, along with the rest of the IMAPEXT
|
||||
Working Group for their assistance in reviewing this document.
|
||||
|
||||
Alexey Melnikov and Cyrus Daboo also had some early discussions about
|
||||
this extension.
|
||||
|
||||
9. References
|
||||
|
||||
9.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
||||
4rev1", RFC 3501, March 2003.
|
||||
|
||||
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
|
||||
Security Layer (SASL)", RFC 4422, June 2006.
|
||||
|
||||
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
|
||||
Encodings", RFC 4648, October 2006.
|
||||
|
||||
9.2. Informative References
|
||||
|
||||
[RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and
|
||||
Security Layer (SASL) Mechanism", RFC 4616, August 2006.
|
||||
|
||||
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
|
||||
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
Siemborski & Gulbrandsen Standards Track [Page 5]
|
||||
|
||||
RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Robert Siemborski
|
||||
Google, Inc.
|
||||
1600 Ampitheatre Parkway
|
||||
Mountain View, CA 94043
|
||||
|
||||
Phone: +1 650 623 6925
|
||||
EMail: robsiemb@google.com
|
||||
|
||||
|
||||
Arnt Gulbrandsen
|
||||
Oryx Mail Systems GmbH
|
||||
Schweppermannstr. 8
|
||||
D-81671 Muenchen
|
||||
Germany
|
||||
|
||||
EMail: arnt@oryx.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Siemborski & Gulbrandsen Standards Track [Page 6]
|
||||
|
||||
RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The IETF Trust (2007).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Siemborski & Gulbrandsen Standards Track [Page 7]
|
||||
|
||||
507
docs/rfc/rfc4978.txt
Normal file
507
docs/rfc/rfc4978.txt
Normal file
@ -0,0 +1,507 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group A. Gulbrandsen
|
||||
Request for Comments: 4978 Oryx Mail Systems GmbH
|
||||
Category: Standards Track August 2007
|
||||
|
||||
|
||||
The IMAP COMPRESS Extension
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
The COMPRESS extension allows an IMAP connection to be effectively
|
||||
and efficiently compressed.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction and Overview .......................................2
|
||||
2. Conventions Used in This Document ...............................2
|
||||
3. The COMPRESS Command ............................................3
|
||||
4. Compression Efficiency ..........................................4
|
||||
5. Formal Syntax ...................................................6
|
||||
6. Security Considerations .........................................6
|
||||
7. IANA Considerations .............................................6
|
||||
8. Acknowledgements ................................................7
|
||||
9. References ......................................................7
|
||||
9.1. Normative References .......................................7
|
||||
9.2. Informative References .....................................7
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen Standards Track [Page 1]
|
||||
|
||||
RFC 4978 The IMAP COMPRESS Extension August 2007
|
||||
|
||||
|
||||
1. Introduction and Overview
|
||||
|
||||
A server which supports the COMPRESS extension indicates this with
|
||||
one or more capability names consisting of "COMPRESS=" followed by a
|
||||
supported compression algorithm name as described in this document.
|
||||
|
||||
The goal of COMPRESS is to reduce the bandwidth usage of IMAP.
|
||||
|
||||
Compared to PPP compression (see [RFC1962]) and modem-based
|
||||
compression (see [MNP] and [V42BIS]), COMPRESS offers much better
|
||||
compression efficiency. COMPRESS can be used together with Transport
|
||||
Security Layer (TLS) [RFC4346], Simple Authentication and Security
|
||||
layer (SASL) encryption, Virtual Private Networks (VPNs), etc.
|
||||
Compared to TLS compression [RFC3749], COMPRESS has the following
|
||||
(dis)advantages:
|
||||
|
||||
- COMPRESS can be implemented easily both by IMAP servers and
|
||||
clients.
|
||||
|
||||
- IMAP COMPRESS benefits from an intimate knowledge of the IMAP
|
||||
protocol's state machine, allowing for dynamic and aggressive
|
||||
optimization of the underlying compression algorithm's parameters.
|
||||
|
||||
- When the TLS layer implements compression, any protocol using that
|
||||
layer can transparently benefit from that compression (e.g., SMTP
|
||||
and IMAP). COMPRESS is specific to IMAP.
|
||||
|
||||
In order to increase interoperation, it is desirable to have as few
|
||||
different compression algorithms as possible, so this document
|
||||
specifies only one. The DEFLATE algorithm (defined in [RFC1951]) is
|
||||
standard, widely available and fairly efficient, so it is the only
|
||||
algorithm defined by this document.
|
||||
|
||||
In order to increase interoperation, IMAP servers that advertise this
|
||||
extension SHOULD also advertise the TLS DEFLATE compression mechanism
|
||||
as defined in [RFC3749]. IMAP clients MAY use either COMPRESS or TLS
|
||||
compression, however, if the client and server support both, it is
|
||||
RECOMMENDED that the client choose TLS compression.
|
||||
|
||||
The extension adds one new command (COMPRESS) and no new responses.
|
||||
|
||||
2. Conventions Used in This Document
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
Formal syntax is defined by [RFC4234] as modified by [RFC3501].
|
||||
|
||||
|
||||
|
||||
Gulbrandsen Standards Track [Page 2]
|
||||
|
||||
RFC 4978 The IMAP COMPRESS Extension August 2007
|
||||
|
||||
|
||||
In the examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server respectively. "[...]" denotes elision.
|
||||
|
||||
3. The COMPRESS Command
|
||||
|
||||
Arguments: Name of compression mechanism: "DEFLATE".
|
||||
|
||||
Responses: None
|
||||
|
||||
Result: OK The server will compress its responses and expects the
|
||||
client to compress its commands.
|
||||
NO Compression is already active via another layer.
|
||||
BAD Command unknown, invalid or unknown argument, or COMPRESS
|
||||
already active.
|
||||
|
||||
The COMPRESS command instructs the server to use the named
|
||||
compression mechanism ("DEFLATE" is the only one defined) for all
|
||||
commands and/or responses after COMPRESS.
|
||||
|
||||
The client MUST NOT send any further commands until it has seen the
|
||||
result of COMPRESS. If the response was OK, the client MUST compress
|
||||
starting with the first command after COMPRESS. If the server
|
||||
response was BAD or NO, the client MUST NOT turn on compression.
|
||||
|
||||
If the server responds NO because it knows that the same mechanism is
|
||||
active already (e.g., because TLS has negotiated the same mechanism),
|
||||
it MUST send COMPRESSIONACTIVE as resp-text-code (see [RFC3501],
|
||||
Section 7.1), and the resp-text SHOULD say which layer compresses.
|
||||
|
||||
If the server issues an OK response, the server MUST compress
|
||||
starting immediately after the CRLF which ends the tagged OK
|
||||
response. (Responses issued by the server before the OK response
|
||||
will, of course, still be uncompressed.) If the server issues a BAD
|
||||
or NO response, the server MUST NOT turn on compression.
|
||||
|
||||
For DEFLATE (as for many other compression mechanisms), the
|
||||
compressor can trade speed against quality. When decompressing there
|
||||
isn't much of a tradeoff. Consequently, the client and server are
|
||||
both free to pick the best reasonable rate of compression for the
|
||||
data they send.
|
||||
|
||||
When COMPRESS is combined with TLS (see [RFC4346]) or SASL (see
|
||||
[RFC4422]) security layers, the sending order of the three extensions
|
||||
MUST be first COMPRESS, then SASL, and finally TLS. That is, before
|
||||
data is transmitted it is first compressed. Second, if a SASL
|
||||
security layer has been negotiated, the compressed data is then
|
||||
signed and/or encrypted accordingly. Third, if a TLS security layer
|
||||
has been negotiated, the data from the previous step is signed and/or
|
||||
|
||||
|
||||
|
||||
Gulbrandsen Standards Track [Page 3]
|
||||
|
||||
RFC 4978 The IMAP COMPRESS Extension August 2007
|
||||
|
||||
|
||||
encrypted accordingly. When receiving data, the processing order
|
||||
MUST be reversed. This ensures that before sending, data is
|
||||
compressed before it is encrypted, independent of the order in which
|
||||
the client issues COMPRESS, AUTHENTICATE, and STARTTLS.
|
||||
|
||||
The following example illustrates how commands and responses are
|
||||
compressed during a simple login sequence:
|
||||
|
||||
S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
|
||||
C: a starttls
|
||||
S: a OK TLS active
|
||||
|
||||
From this point on, everything is encrypted.
|
||||
|
||||
C: b login arnt tnra
|
||||
S: b OK Logged in as arnt
|
||||
C: c compress deflate
|
||||
S: d OK DEFLATE active
|
||||
|
||||
From this point on, everything is compressed before being
|
||||
encrypted.
|
||||
|
||||
The following example demonstrates how a server may refuse to
|
||||
compress twice:
|
||||
|
||||
S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
|
||||
[...]
|
||||
C: c compress deflate
|
||||
S: c NO [COMPRESSIONACTIVE] DEFLATE active via TLS
|
||||
|
||||
4. Compression Efficiency
|
||||
|
||||
This section is informative, not normative.
|
||||
|
||||
IMAP poses some unusual problems for a compression layer.
|
||||
|
||||
Upstream is fairly simple. Most IMAP clients send the same few
|
||||
commands again and again, so any compression algorithm that can
|
||||
exploit repetition works efficiently. The APPEND command is an
|
||||
exception; clients that send many APPEND commands may want to
|
||||
surround large literals with flushes in the same way as is
|
||||
recommended for servers later in this section.
|
||||
|
||||
Downstream has the unusual property that several kinds of data are
|
||||
sent, confusing all dictionary-based compression algorithms.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen Standards Track [Page 4]
|
||||
|
||||
RFC 4978 The IMAP COMPRESS Extension August 2007
|
||||
|
||||
|
||||
One type is IMAP responses. These are highly compressible; zlib
|
||||
using its least CPU-intensive setting compresses typical responses to
|
||||
25-40% of their original size.
|
||||
|
||||
Another type is email headers. These are equally compressible, and
|
||||
benefit from using the same dictionary as the IMAP responses.
|
||||
|
||||
A third type is email body text. Text is usually fairly short and
|
||||
includes much ASCII, so the same compression dictionary will do a
|
||||
good job here, too. When multiple messages in the same thread are
|
||||
read at the same time, quoted lines etc. can often be compressed
|
||||
almost to zero.
|
||||
|
||||
Finally, attachments (non-text email bodies) are transmitted, either
|
||||
in binary form or encoded with base-64.
|
||||
|
||||
When attachments are retrieved in binary form, DEFLATE may be able to
|
||||
compress them, but the format of the attachment is usually not IMAP-
|
||||
like, so the dictionary built while compressing IMAP does not help.
|
||||
The compressor has to adapt its dictionary from IMAP to the
|
||||
attachment's format, and then back. A few file formats aren't
|
||||
compressible at all using deflate, e.g., .gz, .zip, and .jpg files.
|
||||
|
||||
When attachments are retrieved in base-64 form, the same problems
|
||||
apply, but the base-64 encoding adds another problem. 8-bit
|
||||
compression algorithms such as deflate work well on 8-bit file
|
||||
formats, however base-64 turns a file into something resembling 6-bit
|
||||
bytes, hiding most of the 8-bit file format from the compressor.
|
||||
|
||||
When using the zlib library (see [RFC1951]), the functions
|
||||
deflateInit2(), deflate(), inflateInit2(), and inflate() suffice to
|
||||
implement this extension. The windowBits value must be in the range
|
||||
-8 to -15, or else deflateInit2() uses the wrong format.
|
||||
deflateParams() can be used to improve compression rate and resource
|
||||
use. The Z_FULL_FLUSH argument to deflate() can be used to clear the
|
||||
dictionary (the receiving peer does not need to do anything).
|
||||
|
||||
A client can improve downstream compression by implementing BINARY
|
||||
(defined in [RFC3516]) and using FETCH BINARY instead of FETCH BODY.
|
||||
In the author's experience, the improvement ranges from 5% to 40%
|
||||
depending on the attachment being downloaded.
|
||||
|
||||
A server can improve downstream compression if it hints to the
|
||||
compressor that the data type is about to change strongly, e.g., by
|
||||
sending a Z_FULL_FLUSH at the start and end of large non-text
|
||||
literals (before and after '*CHAR8' in the definition of literal in
|
||||
RFC 3501, page 86). Small literals are best left alone. A possible
|
||||
boundary is 5k.
|
||||
|
||||
|
||||
|
||||
Gulbrandsen Standards Track [Page 5]
|
||||
|
||||
RFC 4978 The IMAP COMPRESS Extension August 2007
|
||||
|
||||
|
||||
A server can improve the CPU efficiency both of the server and the
|
||||
client if it adjusts the compression level (e.g., using the
|
||||
deflateParams() function in zlib) at these points, to avoid trying to
|
||||
compress incompressible attachments. A very simple strategy is to
|
||||
change the level to 0 at the start of a literal provided the first
|
||||
two bytes are either 0x1F 0x8B (as in deflate-compressed files) or
|
||||
0xFF 0xD8 (JPEG), and to keep it at 1-5 the rest of the time. More
|
||||
complex strategies are possible.
|
||||
|
||||
5. Formal Syntax
|
||||
|
||||
The following syntax specification uses the Augmented Backus-Naur
|
||||
Form (ABNF) notation as specified in [RFC4234]. This syntax augments
|
||||
the grammar specified in [RFC3501]. [RFC4234] defines SP and
|
||||
[RFC3501] defines command-auth, capability, and resp-text-code.
|
||||
|
||||
Except as noted otherwise, all alphabetic characters are case-
|
||||
insensitive. The use of upper or lower case characters to define
|
||||
token strings is for editorial clarity only. Implementations MUST
|
||||
accept these strings in a case-insensitive fashion.
|
||||
|
||||
command-auth =/ compress
|
||||
|
||||
compress = "COMPRESS" SP algorithm
|
||||
|
||||
capability =/ "COMPRESS=" algorithm
|
||||
;; multiple COMPRESS capabilities allowed
|
||||
|
||||
algorithm = "DEFLATE"
|
||||
|
||||
resp-text-code =/ "COMPRESSIONACTIVE"
|
||||
|
||||
Note that due the syntax of capability names, future algorithm names
|
||||
must be atoms.
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
As for TLS compression [RFC3749].
|
||||
|
||||
7. IANA Considerations
|
||||
|
||||
The IANA has added COMPRESS=DEFLATE to the list of IMAP capabilities.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen Standards Track [Page 6]
|
||||
|
||||
RFC 4978 The IMAP COMPRESS Extension August 2007
|
||||
|
||||
|
||||
8. Acknowledgements
|
||||
|
||||
Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther,
|
||||
Randall Gellens, Tony Hansen, Cullen Jennings, Stephane Maes, Alexey
|
||||
Melnikov, Lyndon Nerenberg, and Zoltan Ordogh have all helped with
|
||||
this document.
|
||||
|
||||
The author would also like to thank various people in the rooms at
|
||||
meetings, whose help is real, but not reflected in the author's
|
||||
mailbox.
|
||||
|
||||
9. References
|
||||
|
||||
9.1. Normative References
|
||||
|
||||
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
|
||||
version 1.3", RFC 1951, May 1996.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
||||
4rev1", RFC 3501, March 2003.
|
||||
|
||||
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
9.2. Informative References
|
||||
|
||||
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)",
|
||||
RFC 1962, June 1996.
|
||||
|
||||
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
|
||||
April 2003.
|
||||
|
||||
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
|
||||
Compression Methods", RFC 3749, May 2004.
|
||||
|
||||
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
|
||||
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
|
||||
|
||||
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
|
||||
Security Layer (SASL)", RFC 4422, June 2006.
|
||||
|
||||
[V42BIS] ITU, "V.42bis: Data compression procedures for data
|
||||
circuit-terminating equipment (DCE) using error correction
|
||||
procedures", http://www.itu.int/rec/T-REC-V.42bis, January
|
||||
1990.
|
||||
|
||||
|
||||
|
||||
Gulbrandsen Standards Track [Page 7]
|
||||
|
||||
RFC 4978 The IMAP COMPRESS Extension August 2007
|
||||
|
||||
|
||||
[MNP] Gilbert Held, "The Complete Modem Reference", Second
|
||||
Edition, Wiley Professional Computing, ISBN 0-471-00852-4,
|
||||
May 1994.
|
||||
|
||||
Author's Address
|
||||
|
||||
Arnt Gulbrandsen
|
||||
Oryx Mail Systems GmbH
|
||||
Schweppermannstr. 8
|
||||
D-81671 Muenchen
|
||||
Germany
|
||||
|
||||
Fax: +49 89 4502 9758
|
||||
EMail: arnt@oryx.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen Standards Track [Page 8]
|
||||
|
||||
RFC 4978 The IMAP COMPRESS Extension August 2007
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The IETF Trust (2007).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen Standards Track [Page 9]
|
||||
|
||||
283
docs/rfc/rfc5032.txt
Normal file
283
docs/rfc/rfc5032.txt
Normal file
@ -0,0 +1,283 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group E. Burger, Ed.
|
||||
Request for Comments: 5032 BEA Systems, Inc.
|
||||
Updates: 3501 September 2007
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
WITHIN Search Extension to the IMAP Protocol
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes the WITHIN extension to IMAP SEARCH. IMAP
|
||||
SEARCH returns messages whose internal date is within or outside a
|
||||
specified interval. The mechanism described here, OLDER and YOUNGER,
|
||||
differs from BEFORE and SINCE in that the client specifies an
|
||||
interval, rather than a date. WITHIN is useful for persistent
|
||||
searches where either the device does not have the capacity to
|
||||
perform the search at regular intervals or the network is of limited
|
||||
bandwidth and thus there is a desire to reduce network traffic from
|
||||
sending repeated requests and redundant responses.
|
||||
|
||||
1. Introduction
|
||||
|
||||
This extension exposes two new search keys, OLDER and YOUNGER, each
|
||||
of which takes a non-zero integer argument corresponding to a time
|
||||
interval in seconds. The server calculates the time of interest by
|
||||
subtracting the time interval the client presents from the current
|
||||
date and time of the server. The server then either returns messages
|
||||
older or younger than the resultant time and date, depending on the
|
||||
search key used.
|
||||
|
||||
1.1. Conventions Used in This Document
|
||||
|
||||
In examples, "C:" and "S:" indicate lines sent by the client and
|
||||
server, respectively.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in RFC 2119 [RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Burger Standards Track [Page 1]
|
||||
|
||||
RFC 5032 Search Within September 2007
|
||||
|
||||
|
||||
When describing the general syntax, we omit some definitions, as RFC
|
||||
3501 [RFC3501] defines them.
|
||||
|
||||
2. Protocol Operation
|
||||
|
||||
An IMAP4 server that supports the capability described here MUST
|
||||
return "WITHIN" as one of the server supported capabilities in the
|
||||
CAPABILITY command.
|
||||
|
||||
For both the OLDER and YOUNGER search keys, the server calculates a
|
||||
target date and time by subtracting the interval, specified in
|
||||
seconds, from the current date and time of the server. The server
|
||||
then compares the target time with the INTERNALDATE of the message,
|
||||
as specified in IMAP [RFC3501]. For OLDER, messages match if the
|
||||
INTERNALDATE is less recent than or equal to the target time. For
|
||||
YOUNGER, messages match if the INTERNALDATE is more recent than or
|
||||
equal to the target time.
|
||||
|
||||
Both OLDER and YOUNGER searches always result in exact matching, to
|
||||
the resolution of a second. However, if one is doing a dynamic
|
||||
evaluation, for example, in a context [CONTEXT], one needs to be
|
||||
aware that the server might perform the evaluation periodically.
|
||||
Thus, the server may delay the updates. Clients MUST be aware that
|
||||
dynamic search results may not reflect the current state of the
|
||||
mailbox. If the client needs a search result that reflects the
|
||||
current state of the mailbox, we RECOMMEND that the client issue a
|
||||
new search.
|
||||
|
||||
3. Formal Syntax
|
||||
|
||||
The following syntax specification uses the Augmented Backus-Naur
|
||||
Form (ABNF) notation. Elements not defined here can be found in the
|
||||
formal syntax of ABNF [RFC4234] and IMAP [RFC3501].
|
||||
|
||||
This document extends RFC 3501 [RFC3501] with two new search keys:
|
||||
OLDER <interval> and YOUNGER <interval>.
|
||||
|
||||
search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number
|
||||
; search-key defined in RFC 3501
|
||||
|
||||
4. Example
|
||||
|
||||
C: a1 SEARCH UNSEEN YOUNGER 259200
|
||||
S: a1 * SEARCH 4 8 15 16 23 42
|
||||
|
||||
Search for all unseen messages within the past 3 days, or 259200
|
||||
seconds, according to the server's current time.
|
||||
|
||||
|
||||
|
||||
|
||||
Burger Standards Track [Page 2]
|
||||
|
||||
RFC 5032 Search Within September 2007
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
The WITHIN extension does not raise any security considerations that
|
||||
are not present in the base protocol. Considerations are the same as
|
||||
for IMAP [RFC3501].
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
Per the IMAP RFC [RFC3501], registration of a new IMAP capability in
|
||||
the IMAP Capability registry requires the publication of a standards-
|
||||
track RFC or an IESG approved experimental RFC. The registry is
|
||||
currently located at
|
||||
<http://www.iana.org/assignments/imap4-capabilities>. This
|
||||
standards-track document defines the WITHIN IMAP capability. IANA
|
||||
has added this extension to the IANA IMAP Capability registry.
|
||||
|
||||
7. References
|
||||
|
||||
7.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", RFC 2119, BCP 14, March 1997.
|
||||
|
||||
[RFC3501] Crispin, M., "Internet Message Access Protocol - Version
|
||||
4rev1", RFC 3501, March 2003.
|
||||
|
||||
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
7.2. Informative References
|
||||
|
||||
[CONTEXT] Melnikov, D. and C. King, "Contexts for IMAP4", Work
|
||||
in Progress, May 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Burger Standards Track [Page 3]
|
||||
|
||||
RFC 5032 Search Within September 2007
|
||||
|
||||
|
||||
Appendix A. Contributors
|
||||
|
||||
Stephane Maes and Ray Cromwell wrote the original version of this
|
||||
document as part of P-IMAP, as well as the first versions for the
|
||||
IETF. From an attribution perspective, they are clearly authors.
|
||||
|
||||
Appendix B. Acknowledgements
|
||||
|
||||
The authors want to thank all who have contributed key insight and
|
||||
who have extensively reviewed and discussed the concepts of LPSEARCH.
|
||||
They also thank the authors of its early introduction in P-IMAP.
|
||||
|
||||
We also want to give a special thanks to Arnt Gilbrandsen, Ken
|
||||
Murchison, Zoltan Ordogh, and most especially Dave Cridland for their
|
||||
review and suggestions. A special thank you goes to Alexey Melnikov
|
||||
for his choice submission of text.
|
||||
|
||||
Author's Address
|
||||
|
||||
Eric W. Burger (editor)
|
||||
BEA Systems, Inc.
|
||||
USA
|
||||
|
||||
EMail: eric.burger@bea.com
|
||||
URI: http://www.standardstrack.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Burger Standards Track [Page 4]
|
||||
|
||||
RFC 5032 Search Within September 2007
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The IETF Trust (2007).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Burger Standards Track [Page 5]
|
||||
|
||||
395
docs/rfc/rfc5051.txt
Normal file
395
docs/rfc/rfc5051.txt
Normal file
@ -0,0 +1,395 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Crispin
|
||||
Request for Comments: 5051 University of Washington
|
||||
Category: Standards Track October 2007
|
||||
|
||||
|
||||
i;unicode-casemap - Simple Unicode Collation Algorithm
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes "i;unicode-casemap", a simple case-
|
||||
insensitive collation for Unicode strings. It provides equality,
|
||||
substring, and ordering operations.
|
||||
|
||||
1. Introduction
|
||||
|
||||
The "i;ascii-casemap" collation described in [COMPARATOR] is quite
|
||||
simple to implement and provides case-independent comparisons for the
|
||||
26 Latin alphabetics. It is specified as the default and/or baseline
|
||||
comparator in some application protocols, e.g., [IMAP-SORT].
|
||||
|
||||
However, the "i;ascii-casemap" collation does not produce
|
||||
satisfactory results with non-ASCII characters. It is possible, with
|
||||
a modest extension, to provide a more sophisticated collation with
|
||||
greater multilingual applicability than "i;ascii-casemap". This
|
||||
extension provides case-independent comparisons for a much greater
|
||||
number of characters. It also collates characters with diacriticals
|
||||
with the non-diacritical character forms.
|
||||
|
||||
This collation, "i;unicode-casemap", is intended to be an alternative
|
||||
to, and preferred over, "i;ascii-casemap". It does not replace the
|
||||
"i;basic" collation described in [BASIC].
|
||||
|
||||
2. Unicode Casemap Collation Description
|
||||
|
||||
The "i;unicode-casemap" collation is a simple collation which is
|
||||
case-insensitive in its treatment of characters. It provides
|
||||
equality, substring, and ordering operations. The validity test
|
||||
operation returns "valid" for any input.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 1]
|
||||
|
||||
RFC 5051 i;unicode-casemap October 2007
|
||||
|
||||
|
||||
This collation allows strings in arbitrary (and mixed) character
|
||||
sets, as long as the character set for each string is identified and
|
||||
it is possible to convert the string to Unicode. Strings which have
|
||||
an unidentified character set and/or cannot be converted to Unicode
|
||||
are not rejected, but are treated as binary.
|
||||
|
||||
Each input string is prepared by converting it to a "titlecased
|
||||
canonicalized UTF-8" string according to the following steps, using
|
||||
UnicodeData.txt ([UNICODE-DATA]):
|
||||
|
||||
(1) A Unicode codepoint is obtained from the input string.
|
||||
|
||||
(a) If the input string is in a known charset that can be
|
||||
converted to Unicode, a sequence in the string's charset
|
||||
is read and checked for validity according to the rules of
|
||||
that charset. If the sequence is valid, it is converted
|
||||
to a Unicode codepoint. Note that for input strings in
|
||||
UTF-8, the UTF-8 sequence must be valid according to the
|
||||
rules of [UTF-8]; e.g., overlong UTF-8 sequences are
|
||||
invalid.
|
||||
|
||||
(b) If the input string is in an unknown charset, or an
|
||||
invalid sequence occurs in step (1)(a), conversion ceases.
|
||||
No further preparation is performed, and any partial
|
||||
preparation results are discarded. The original string is
|
||||
used unchanged with the i;octet comparator.
|
||||
|
||||
(2) The following steps, using UnicodeData.txt ([UNICODE-DATA]),
|
||||
are performed on the resulting codepoint from step (1)(a).
|
||||
|
||||
(a) If the codepoint has a titlecase property in
|
||||
UnicodeData.txt (this is normally the same as the
|
||||
uppercase property), the codepoint is converted to the
|
||||
codepoints in the titlecase property.
|
||||
|
||||
(b) If the resulting codepoint from (2)(a) has a decomposition
|
||||
property of any type in UnicodeData.txt, the codepoint is
|
||||
converted to the codepoints in the decomposition property.
|
||||
This step is recursively applied to each of the resulting
|
||||
codepoints until no more decomposition is possible
|
||||
(effectively Normalization Form KD).
|
||||
|
||||
Example: codepoint U+01C4 (LATIN CAPITAL LETTER DZ WITH CARON)
|
||||
has a titlecase property of U+01C5 (LATIN CAPITAL LETTER D
|
||||
WITH SMALL LETTER Z WITH CARON). Codepoint U+01C5 has a
|
||||
decomposition property of U+0044 (LATIN CAPITAL LETTER D)
|
||||
U+017E (LATIN SMALL LETTER Z WITH CARON). U+017E has a
|
||||
decomposition property of U+007A (LATIN SMALL LETTER Z) U+030c
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 2]
|
||||
|
||||
RFC 5051 i;unicode-casemap October 2007
|
||||
|
||||
|
||||
(COMBINING CARON). Neither U+0044, U+007A, nor U+030C have
|
||||
any decomposition properties. Therefore, U+01C4 is converted
|
||||
to U+0044 U+007A U+030C by this step.
|
||||
|
||||
(3) The resulting codepoint(s) from step (2) is/are appended, in
|
||||
UTF-8 format, to the "titlecased canonicalized UTF-8" string.
|
||||
|
||||
(4) Repeat from step (1) until there is no more data in the input
|
||||
string.
|
||||
|
||||
Following the above preparation process on each string, the equality,
|
||||
ordering, and substring operations are as for i;octet.
|
||||
|
||||
It is permitted to use an alternative implementation of the above
|
||||
preparation process if it produces the same results. For example, it
|
||||
may be more convenient for an implementation to convert all input
|
||||
strings to a sequence of UTF-16 or UTF-32 values prior to performing
|
||||
any of the step (2) actions. Similarly, if all input strings are (or
|
||||
are convertible to) Unicode, it may be possible to use UTF-32 as an
|
||||
alternative to UTF-8 in step (3).
|
||||
|
||||
Note: UTF-16 is unsuitable as an alternative to UTF-8 in step (3),
|
||||
because UTF-16 surrogates will cause i;octet to collate codepoints
|
||||
U+E0000 through U+FFFF after non-BMP codepoints.
|
||||
|
||||
This collation is not locale sensitive. Consequently, care should be
|
||||
taken when using OS-supplied functions to implement this collation.
|
||||
Functions such as strcasecmp and toupper are sometimes locale
|
||||
sensitive and may inconsistently casemap letters.
|
||||
|
||||
The i;unicode-casemap collation is well suited to use with many
|
||||
Internet protocols and computer languages. Use with natural language
|
||||
is often inappropriate; even though the collation apparently supports
|
||||
languages such as Swahili and English, in real-world use it tends to
|
||||
mis-sort a number of types of string:
|
||||
|
||||
o people and place names containing scripts that are not collated
|
||||
according to "alphabetical order".
|
||||
o words with characters that have diacriticals. However,
|
||||
i;unicode-casemap generally does a better job than i;ascii-casemap
|
||||
for most (but not all) languages. For example, German umlaut
|
||||
letters will sort correctly, but some Scandinavian letters will
|
||||
not.
|
||||
o names such as "Lloyd" (which in Welsh sorts after "Lyon", unlike
|
||||
in English),
|
||||
o strings containing other non-letter symbols; e.g., euro and pound
|
||||
sterling symbols, quotation marks other than '"', dashes/hyphens,
|
||||
etc.
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 3]
|
||||
|
||||
RFC 5051 i;unicode-casemap October 2007
|
||||
|
||||
|
||||
3. Unicode Casemap Collation Registration
|
||||
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE collation SYSTEM 'collationreg.dtd'>
|
||||
<collation rfc="5051" scope="global" intendedUse="common">
|
||||
<identifier>i;unicode-casemap</identifier>
|
||||
<title>Unicode Casemap</title>
|
||||
<operations>equality order substring</operations>
|
||||
<specification>RFC 5051</specification>
|
||||
<owner>IETF</owner>
|
||||
<submitter>mrc@cac.washington.edu</submitter>
|
||||
</collation>
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
The security considerations for [UTF-8], [STRINGPREP], and [UNICODE-
|
||||
SECURITY] apply and are normative to this specification.
|
||||
|
||||
The results from this comparator will vary depending upon the
|
||||
implementation for several reasons. Implementations MUST consider
|
||||
whether these possibilities are a problem for their use case:
|
||||
|
||||
1) New characters added in Unicode may have decomposition or
|
||||
titlecase properties that will not be known to an implementation
|
||||
based upon an older revision of Unicode. This impacts step (2).
|
||||
|
||||
2) Step (2)(b) defines a subset of Normalization Form KD (NFKD) that
|
||||
does not require normalization of out-of-order diacriticals.
|
||||
However, an implementation MAY use an NFKD library routine that
|
||||
does such normalization. This impacts step (2)(b) and possibly
|
||||
also step (1)(a), and is an issue only with ill-formed UTF-8
|
||||
input.
|
||||
|
||||
3) The set of charsets handled in step (1)(a) is open-ended. UTF-8
|
||||
(and, by extension, US-ASCII) are the only mandatory-to-implement
|
||||
charsets. This impacts step (1)(a).
|
||||
|
||||
Implementations SHOULD, as far as feasible, support all the
|
||||
charsets they are likely to encounter in the input data, in order
|
||||
to avoid poor collation caused by the fall through to the (1)(b)
|
||||
rule.
|
||||
|
||||
4) Other charsets may have revisions which add new characters that
|
||||
are not known to an implementation based upon an older revision.
|
||||
This impacts step (1)(a) and possibly also step (1)(b).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 4]
|
||||
|
||||
RFC 5051 i;unicode-casemap October 2007
|
||||
|
||||
|
||||
An attacker may create input that is ill-formed or in an unknown
|
||||
charset, with the intention of impacting the results of this
|
||||
comparator or exploiting other parts of the system which process this
|
||||
input in different ways. Note, however, that even well-formed data
|
||||
in a known charset can impact the result of this comparator in
|
||||
unexpected ways. For example, an attacker can substitute U+0041
|
||||
(LATIN CAPITAL LETTER A) with U+0391 (GREEK CAPITAL LETTER ALPHA) or
|
||||
U+0410 (CYRILLIC CAPITAL LETTER A) in the intention of causing a
|
||||
non-match of strings which visually appear the same and/or causing
|
||||
the string to appear elsewhere in a sort.
|
||||
|
||||
5. IANA Considerations
|
||||
|
||||
The i;unicode-casemap collation defined in section 2 has been added
|
||||
to the registry of collations defined in [COMPARATOR].
|
||||
|
||||
6. Normative References
|
||||
|
||||
[COMPARATOR] Newman, C., Duerst, M., and A. Gulbrandsen,
|
||||
"Internet Application Protocol Collation
|
||||
Registry", RFC 4790, February 2007.
|
||||
|
||||
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
|
||||
Internationalized Strings ("stringprep")", RFC
|
||||
3454, December 2002.
|
||||
|
||||
[UTF-8] Yergeau, F., "UTF-8, a transformation format of
|
||||
ISO 10646", STD 63, RFC 3629, November 2003.
|
||||
|
||||
[UNICODE-DATA] <http://www.unicode.org/Public/UNIDATA/
|
||||
UnicodeData.txt>
|
||||
|
||||
Although the UnicodeData.txt file referenced
|
||||
here is part of the Unicode standard, it is
|
||||
subject to change as new characters are added
|
||||
to Unicode and errors are corrected in Unicode
|
||||
revisions. As a result, it may be less stable
|
||||
than might otherwise be implied by the
|
||||
standards status of this specification.
|
||||
|
||||
[UNICODE-SECURITY] Davis, M. and M. Suignard, "Unicode Security
|
||||
Considerations", February 2006,
|
||||
<http://www.unicode.org/reports/tr36/>.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 5]
|
||||
|
||||
RFC 5051 i;unicode-casemap October 2007
|
||||
|
||||
|
||||
7. Informative References
|
||||
|
||||
[BASIC] Newman, C., Duerst, M., and A. Gulbrandsen,
|
||||
"i;basic - the Unicode Collation Algorithm",
|
||||
Work in Progress, March 2007.
|
||||
|
||||
[IMAP-SORT] Crispin, M. and K. Murchison, "Internet Message
|
||||
Access Protocol - SORT and THREAD Extensions",
|
||||
Work in Progress, September 2007.
|
||||
|
||||
Author's Address
|
||||
|
||||
Mark R. Crispin
|
||||
Networks and Distributed Computing
|
||||
University of Washington
|
||||
4545 15th Avenue NE
|
||||
Seattle, WA 98105-4527
|
||||
|
||||
Phone: +1 (206) 543-5762
|
||||
EMail: MRC@CAC.Washington.EDU
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 6]
|
||||
|
||||
RFC 5051 i;unicode-casemap October 2007
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The IETF Trust (2007).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crispin Standards Track [Page 7]
|
||||
|
||||
1795
docs/rfc/rfc5092.txt
Normal file
1795
docs/rfc/rfc5092.txt
Normal file
File diff suppressed because it is too large
Load Diff
395
docs/rfc/rfc5161.txt
Normal file
395
docs/rfc/rfc5161.txt
Normal file
@ -0,0 +1,395 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group A. Gulbrandsen, Ed.
|
||||
Request for Comments: 5161 Oryx Mail Systems GmbH
|
||||
Category: Standards Track A. Melnikov, Ed.
|
||||
Isode Limited
|
||||
March 2008
|
||||
|
||||
|
||||
The IMAP ENABLE Extension
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
Most IMAP extensions are used by the client when it wants to and the
|
||||
server supports it. However, a few extensions require the server to
|
||||
know whether a client supports that extension. The ENABLE extension
|
||||
allows an IMAP client to say which extensions it supports.
|
||||
|
||||
1. Overview
|
||||
|
||||
Several IMAP extensions allow the server to return unsolicited
|
||||
responses specific to these extensions in certain circumstances.
|
||||
However, servers cannot send those unsolicited responses until they
|
||||
know that the clients support such extensions and thus won't choke on
|
||||
the extension response data.
|
||||
|
||||
Up until now, extensions have typically stated that a server cannot
|
||||
send the unsolicited responses until after the client has used a
|
||||
command with the extension data (i.e., at that point the server knows
|
||||
the client is aware of the extension). CONDSTORE ([RFC4551]),
|
||||
ANNOTATE ([ANNOTATE]), and some extensions under consideration at the
|
||||
moment use various commands to enable server extensions. For
|
||||
example, CONDSTORE uses a SELECT or FETCH parameter, and ANNOTATE
|
||||
uses a side effect of FETCH.
|
||||
|
||||
The ENABLE extension provides an explicit indication from the client
|
||||
that it supports particular extensions. This is done using a new
|
||||
ENABLE command.
|
||||
|
||||
An IMAP server that supports ENABLE advertises this by including the
|
||||
word ENABLE in its capability list.
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen & Melnikov Standards Track [Page 1]
|
||||
|
||||
RFC 5161 The IMAP ENABLE Extension March 2008
|
||||
|
||||
|
||||
Most IMAP extensions do not require the client to enable the
|
||||
extension in any way.
|
||||
|
||||
2. Conventions Used in This Document
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
Formal syntax is defined by [RFC5234] and [RFC3501].
|
||||
|
||||
Example lines prefaced by "C:" are sent by the client and ones
|
||||
prefaced by "S:" by the server. The five characters [...] means that
|
||||
something has been elided.
|
||||
|
||||
3. Protocol Changes
|
||||
|
||||
3.1. The ENABLE Command
|
||||
|
||||
Arguments: capability names
|
||||
|
||||
Result: OK: Relevant capabilities enabled
|
||||
BAD: No arguments, or syntax error in an argument
|
||||
|
||||
The ENABLE command takes a list of capability names, and requests the
|
||||
server to enable the named extensions. Once enabled using ENABLE,
|
||||
each extension remains active until the IMAP connection is closed.
|
||||
For each argument, the server does the following:
|
||||
|
||||
- If the argument is not an extension known to the server, the server
|
||||
MUST ignore the argument.
|
||||
|
||||
- If the argument is an extension known to the server, and it is not
|
||||
specifically permitted to be enabled using ENABLE, the server MUST
|
||||
ignore the argument. (Note that knowing about an extension doesn't
|
||||
necessarily imply supporting that extension.)
|
||||
|
||||
- If the argument is an extension that is supported by the server and
|
||||
that needs to be enabled, the server MUST enable the extension for
|
||||
the duration of the connection. At present, this applies only to
|
||||
CONDSTORE ([RFC4551]). Note that once an extension is enabled,
|
||||
there is no way to disable it.
|
||||
|
||||
If the ENABLE command is successful, the server MUST send an untagged
|
||||
ENABLED response (see Section 3.2).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen & Melnikov Standards Track [Page 2]
|
||||
|
||||
RFC 5161 The IMAP ENABLE Extension March 2008
|
||||
|
||||
|
||||
Clients SHOULD only include extensions that need to be enabled by the
|
||||
server. At the time of publication, CONDSTORE is the only such
|
||||
extension (i.e., ENABLE CONDSTORE is an additional "CONDSTORE
|
||||
enabling command" as defined in [RFC4551]). Future RFCs may add to
|
||||
this list.
|
||||
|
||||
The ENABLE command is only valid in the authenticated state (see
|
||||
[RFC3501]), before any mailbox is selected. Clients MUST NOT issue
|
||||
ENABLE once they SELECT/EXAMINE a mailbox; however, server
|
||||
implementations don't have to check that no mailbox is selected or
|
||||
was previously selected during the duration of a connection.
|
||||
|
||||
The ENABLE command can be issued multiple times in a session. It is
|
||||
additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a
|
||||
single command "ENABLE a b c". When multiple ENABLE commands are
|
||||
issued, each corresponding ENABLED response SHOULD only contain
|
||||
extensions enabled by the corresponding ENABLE command.
|
||||
|
||||
There are no limitations on pipelining ENABLE. For example, it is
|
||||
possible to send ENABLE and then immediately SELECT, or a LOGIN
|
||||
immediately followed by ENABLE.
|
||||
|
||||
The server MUST NOT change the CAPABILITY list as a result of
|
||||
executing ENABLE; i.e., a CAPABILITY command issued right after an
|
||||
ENABLE command MUST list the same capabilities as a CAPABILITY
|
||||
command issued before the ENABLE command. This is demonstrated in
|
||||
the following example:
|
||||
|
||||
C: t1 CAPABILITY
|
||||
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
|
||||
S: t1 OK foo
|
||||
C: t2 ENABLE CONDSTORE X-GOOD-IDEA
|
||||
S: * ENABLED X-GOOD-IDEA
|
||||
S: t2 OK foo
|
||||
C: t3 CAPABILITY
|
||||
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
|
||||
S: t3 OK foo again
|
||||
|
||||
In the following example, the client enables CONDSTORE:
|
||||
|
||||
C: a1 ENABLE CONDSTORE
|
||||
S: * ENABLED CONDSTORE
|
||||
S: a1 OK Conditional Store enabled
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen & Melnikov Standards Track [Page 3]
|
||||
|
||||
RFC 5161 The IMAP ENABLE Extension March 2008
|
||||
|
||||
|
||||
3.2. The ENABLED Response
|
||||
|
||||
Contents: capability listing
|
||||
|
||||
The ENABLED response occurs as a result of an ENABLE command. The
|
||||
capability listing contains a space-separated listing of capability
|
||||
names that the server supports and that were successfully enabled.
|
||||
The ENABLED response may contain no capabilities, which means that no
|
||||
extensions listed by the client were successfully enabled.
|
||||
|
||||
3.3. Note to Designers of Extensions That May Use the ENABLE Command
|
||||
|
||||
Designers of IMAP extensions are discouraged from creating extensions
|
||||
that require ENABLE unless there is no good alternative design.
|
||||
Specifically, extensions that cause potentially incompatible behavior
|
||||
changes to deployed server responses (and thus benefit from ENABLE)
|
||||
have a higher complexity cost than extensions that do not.
|
||||
|
||||
4. Formal Syntax
|
||||
|
||||
The following syntax specification uses the Augmented Backus-Naur
|
||||
Form (ABNF) notation as specified in [RFC5234] including the core
|
||||
rules in Appendix B.1. [RFC3501] defines the non-terminals
|
||||
"capability" and "command-any".
|
||||
|
||||
Except as noted otherwise, all alphabetic characters are
|
||||
case-insensitive. The use of upper or lower case characters to
|
||||
define token strings is for editorial clarity only. Implementations
|
||||
MUST accept these strings in a case-insensitive fashion.
|
||||
|
||||
capability =/ "ENABLE"
|
||||
|
||||
command-any =/ "ENABLE" 1*(SP capability)
|
||||
|
||||
response-data =/ "*" SP enable-data CRLF
|
||||
|
||||
enable-data = "ENABLED" *(SP capability)
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
It is believed that this extension doesn't add any security
|
||||
considerations that are not already present in the base IMAP protocol
|
||||
[RFC3501].
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
The IANA has added ENABLE to the IMAP4 Capabilities Registry.
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen & Melnikov Standards Track [Page 4]
|
||||
|
||||
RFC 5161 The IMAP ENABLE Extension March 2008
|
||||
|
||||
|
||||
7. Acknowledgments
|
||||
|
||||
The editors would like to thank Randy Gellens, Chris Newman, Peter
|
||||
Coates, Dave Cridland, Mark Crispin, Ned Freed, Dan Karp, Cyrus
|
||||
Daboo, Ken Murchison, and Eric Burger for comments and corrections.
|
||||
However, this doesn't necessarily mean that they endorse this
|
||||
extension, agree with all details, or are responsible for errors
|
||||
introduced by the editors.
|
||||
|
||||
8. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
||||
4rev1", RFC 3501, March 2003.
|
||||
|
||||
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
|
||||
Syntax Specifications: ABNF", STD 68, RFC 5234, January
|
||||
2008.
|
||||
|
||||
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
|
||||
STORE Operation or Quick Flag Changes Resynchronization",
|
||||
RFC 4551, June 2006.
|
||||
|
||||
9. Informative References
|
||||
|
||||
[ANNOTATE] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work
|
||||
in Progress, August 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen & Melnikov Standards Track [Page 5]
|
||||
|
||||
RFC 5161 The IMAP ENABLE Extension March 2008
|
||||
|
||||
|
||||
Editors' Addresses
|
||||
|
||||
Arnt Gulbrandsen
|
||||
Oryx Mail Systems GmbH
|
||||
Schweppermannstr. 8
|
||||
D-81671 Muenchen
|
||||
Germany
|
||||
|
||||
Fax: +49 89 4502 9758
|
||||
EMail: arnt@oryx.com
|
||||
|
||||
|
||||
Alexey Melnikov
|
||||
Isode Ltd
|
||||
5 Castle Business Village
|
||||
36 Station Road
|
||||
Hampton, Middlesex TW12 2BX
|
||||
UK
|
||||
|
||||
EMail: Alexey.Melnikov@isode.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen & Melnikov Standards Track [Page 6]
|
||||
|
||||
RFC 5161 The IMAP ENABLE Extension March 2008
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The IETF Trust (2008).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gulbrandsen & Melnikov Standards Track [Page 7]
|
||||
|
||||
1291
docs/rfc/rfc5162.txt
Normal file
1291
docs/rfc/rfc5162.txt
Normal file
File diff suppressed because it is too large
Load Diff
899
docs/rfc/rfc5234.txt
Normal file
899
docs/rfc/rfc5234.txt
Normal file
@ -0,0 +1,899 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group D. Crocker, Ed.
|
||||
Request for Comments: 5234 Brandenburg InternetWorking
|
||||
STD: 68 P. Overell
|
||||
Obsoletes: 4234 THUS plc.
|
||||
Category: Standards Track January 2008
|
||||
|
||||
|
||||
Augmented BNF for Syntax Specifications: ABNF
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
Internet technical specifications often need to define a formal
|
||||
syntax. Over the years, a modified version of Backus-Naur Form
|
||||
(BNF), called Augmented BNF (ABNF), has been popular among many
|
||||
Internet specifications. The current specification documents ABNF.
|
||||
It balances compactness and simplicity with reasonable
|
||||
representational power. The differences between standard BNF and
|
||||
ABNF involve naming rules, repetition, alternatives, order-
|
||||
independence, and value ranges. This specification also supplies
|
||||
additional rule definitions and encoding for a core lexical analyzer
|
||||
of the type common to several Internet specifications.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 1]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
2. Rule Definition . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
2.1. Rule Naming . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
2.2. Rule Form . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
2.3. Terminal Values . . . . . . . . . . . . . . . . . . . . . 4
|
||||
2.4. External Encodings . . . . . . . . . . . . . . . . . . . . 6
|
||||
3. Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
3.1. Concatenation: Rule1 Rule2 . . . . . . . . . . . . . . . 6
|
||||
3.2. Alternatives: Rule1 / Rule2 . . . . . . . . . . . . . . . 7
|
||||
3.3. Incremental Alternatives: Rule1 =/ Rule2 . . . . . . . . . 7
|
||||
3.4. Value Range Alternatives: %c##-## . . . . . . . . . . . . 8
|
||||
3.5. Sequence Group: (Rule1 Rule2) . . . . . . . . . . . . . . 8
|
||||
3.6. Variable Repetition: *Rule . . . . . . . . . . . . . . . 9
|
||||
3.7. Specific Repetition: nRule . . . . . . . . . . . . . . . 9
|
||||
3.8. Optional Sequence: [RULE] . . . . . . . . . . . . . . . . 9
|
||||
3.9. Comment: ; Comment . . . . . . . . . . . . . . . . . . . 9
|
||||
3.10. Operator Precedence . . . . . . . . . . . . . . . . . . . 10
|
||||
4. ABNF Definition of ABNF . . . . . . . . . . . . . . . . . . . 10
|
||||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
|
||||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
|
||||
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
|
||||
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
|
||||
Appendix B. Core ABNF of ABNF . . . . . . . . . . . . . . . . . . 13
|
||||
B.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
B.2. Common Encoding . . . . . . . . . . . . . . . . . . . . . 15
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 2]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Internet technical specifications often need to define a formal
|
||||
syntax and are free to employ whatever notation their authors deem
|
||||
useful. Over the years, a modified version of Backus-Naur Form
|
||||
(BNF), called Augmented BNF (ABNF), has been popular among many
|
||||
Internet specifications. It balances compactness and simplicity with
|
||||
reasonable representational power. In the early days of the Arpanet,
|
||||
each specification contained its own definition of ABNF. This
|
||||
included the email specifications, [RFC733] and then [RFC822], which
|
||||
came to be the common citations for defining ABNF. The current
|
||||
document separates those definitions to permit selective reference.
|
||||
Predictably, it also provides some modifications and enhancements.
|
||||
|
||||
The differences between standard BNF and ABNF involve naming rules,
|
||||
repetition, alternatives, order-independence, and value ranges.
|
||||
Appendix B supplies rule definitions and encoding for a core lexical
|
||||
analyzer of the type common to several Internet specifications. It
|
||||
is provided as a convenience and is otherwise separate from the meta
|
||||
language defined in the body of this document, and separate from its
|
||||
formal status.
|
||||
|
||||
2. Rule Definition
|
||||
|
||||
2.1. Rule Naming
|
||||
|
||||
The name of a rule is simply the name itself, that is, a sequence of
|
||||
characters, beginning with an alphabetic character, and followed by a
|
||||
combination of alphabetics, digits, and hyphens (dashes).
|
||||
|
||||
NOTE:
|
||||
|
||||
Rule names are case insensitive.
|
||||
|
||||
The names <rulename>, <Rulename>, <RULENAME>, and <rUlENamE> all
|
||||
refer to the same rule.
|
||||
|
||||
Unlike original BNF, angle brackets ("<", ">") are not required.
|
||||
However, angle brackets may be used around a rule name whenever their
|
||||
presence facilitates in discerning the use of a rule name. This is
|
||||
typically restricted to rule name references in free-form prose, or
|
||||
to distinguish partial rules that combine into a string not separated
|
||||
by white space, such as shown in the discussion about repetition,
|
||||
below.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 3]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
2.2. Rule Form
|
||||
|
||||
A rule is defined by the following sequence:
|
||||
|
||||
name = elements crlf
|
||||
|
||||
where <name> is the name of the rule, <elements> is one or more rule
|
||||
names or terminal specifications, and <crlf> is the end-of-line
|
||||
indicator (carriage return followed by line feed). The equal sign
|
||||
separates the name from the definition of the rule. The elements
|
||||
form a sequence of one or more rule names and/or value definitions,
|
||||
combined according to the various operators defined in this document,
|
||||
such as alternative and repetition.
|
||||
|
||||
For visual ease, rule definitions are left aligned. When a rule
|
||||
requires multiple lines, the continuation lines are indented. The
|
||||
left alignment and indentation are relative to the first lines of the
|
||||
ABNF rules and need not match the left margin of the document.
|
||||
|
||||
2.3. Terminal Values
|
||||
|
||||
Rules resolve into a string of terminal values, sometimes called
|
||||
characters. In ABNF, a character is merely a non-negative integer.
|
||||
In certain contexts, a specific mapping (encoding) of values into a
|
||||
character set (such as ASCII) will be specified.
|
||||
|
||||
Terminals are specified by one or more numeric characters, with the
|
||||
base interpretation of those characters indicated explicitly. The
|
||||
following bases are currently defined:
|
||||
|
||||
b = binary
|
||||
|
||||
d = decimal
|
||||
|
||||
x = hexadecimal
|
||||
|
||||
Hence:
|
||||
|
||||
CR = %d13
|
||||
|
||||
CR = %x0D
|
||||
|
||||
respectively specify the decimal and hexadecimal representation of
|
||||
[US-ASCII] for carriage return.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 4]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
A concatenated string of such values is specified compactly, using a
|
||||
period (".") to indicate a separation of characters within that
|
||||
value. Hence:
|
||||
|
||||
CRLF = %d13.10
|
||||
|
||||
ABNF permits the specification of literal text strings directly,
|
||||
enclosed in quotation marks. Hence:
|
||||
|
||||
command = "command string"
|
||||
|
||||
Literal text strings are interpreted as a concatenated set of
|
||||
printable characters.
|
||||
|
||||
NOTE:
|
||||
|
||||
ABNF strings are case insensitive and the character set for these
|
||||
strings is US-ASCII.
|
||||
|
||||
Hence:
|
||||
|
||||
rulename = "abc"
|
||||
|
||||
and:
|
||||
|
||||
rulename = "aBc"
|
||||
|
||||
will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
|
||||
"ABC".
|
||||
|
||||
To specify a rule that is case sensitive, specify the characters
|
||||
individually.
|
||||
|
||||
For example:
|
||||
|
||||
rulename = %d97 %d98 %d99
|
||||
|
||||
or
|
||||
|
||||
rulename = %d97.98.99
|
||||
|
||||
will match only the string that comprises only the lowercase
|
||||
characters, abc.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 5]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
2.4. External Encodings
|
||||
|
||||
External representations of terminal value characters will vary
|
||||
according to constraints in the storage or transmission environment.
|
||||
Hence, the same ABNF-based grammar may have multiple external
|
||||
encodings, such as one for a 7-bit US-ASCII environment, another for
|
||||
a binary octet environment, and still a different one when 16-bit
|
||||
Unicode is used. Encoding details are beyond the scope of ABNF,
|
||||
although Appendix B provides definitions for a 7-bit US-ASCII
|
||||
environment as has been common to much of the Internet.
|
||||
|
||||
By separating external encoding from the syntax, it is intended that
|
||||
alternate encoding environments can be used for the same syntax.
|
||||
|
||||
3. Operators
|
||||
|
||||
3.1. Concatenation: Rule1 Rule2
|
||||
|
||||
A rule can define a simple, ordered string of values (i.e., a
|
||||
concatenation of contiguous characters) by listing a sequence of rule
|
||||
names. For example:
|
||||
|
||||
foo = %x61 ; a
|
||||
|
||||
bar = %x62 ; b
|
||||
|
||||
mumble = foo bar foo
|
||||
|
||||
So that the rule <mumble> matches the lowercase string "aba".
|
||||
|
||||
Linear white space: Concatenation is at the core of the ABNF parsing
|
||||
model. A string of contiguous characters (values) is parsed
|
||||
according to the rules defined in ABNF. For Internet specifications,
|
||||
there is some history of permitting linear white space (space and
|
||||
horizontal tab) to be freely and implicitly interspersed around major
|
||||
constructs, such as delimiting special characters or atomic strings.
|
||||
|
||||
NOTE:
|
||||
|
||||
This specification for ABNF does not provide for implicit
|
||||
specification of linear white space.
|
||||
|
||||
Any grammar that wishes to permit linear white space around
|
||||
delimiters or string segments must specify it explicitly. It is
|
||||
often useful to provide for such white space in "core" rules that are
|
||||
then used variously among higher-level rules. The "core" rules might
|
||||
be formed into a lexical analyzer or simply be part of the main
|
||||
ruleset.
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 6]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
3.2. Alternatives: Rule1 / Rule2
|
||||
|
||||
Elements separated by a forward slash ("/") are alternatives.
|
||||
Therefore,
|
||||
|
||||
foo / bar
|
||||
|
||||
will accept <foo> or <bar>.
|
||||
|
||||
NOTE:
|
||||
|
||||
A quoted string containing alphabetic characters is a special form
|
||||
for specifying alternative characters and is interpreted as a non-
|
||||
terminal representing the set of combinatorial strings with the
|
||||
contained characters, in the specified order but with any mixture
|
||||
of upper- and lowercase.
|
||||
|
||||
3.3. Incremental Alternatives: Rule1 =/ Rule2
|
||||
|
||||
It is sometimes convenient to specify a list of alternatives in
|
||||
fragments. That is, an initial rule may match one or more
|
||||
alternatives, with later rule definitions adding to the set of
|
||||
alternatives. This is particularly useful for otherwise independent
|
||||
specifications that derive from the same parent ruleset, such as
|
||||
often occurs with parameter lists. ABNF permits this incremental
|
||||
definition through the construct:
|
||||
|
||||
oldrule =/ additional-alternatives
|
||||
|
||||
So that the ruleset
|
||||
|
||||
ruleset = alt1 / alt2
|
||||
|
||||
ruleset =/ alt3
|
||||
|
||||
ruleset =/ alt4 / alt5
|
||||
|
||||
is the same as specifying
|
||||
|
||||
ruleset = alt1 / alt2 / alt3 / alt4 / alt5
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 7]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
3.4. Value Range Alternatives: %c##-##
|
||||
|
||||
A range of alternative numeric values can be specified compactly,
|
||||
using a dash ("-") to indicate the range of alternative values.
|
||||
Hence:
|
||||
|
||||
DIGIT = %x30-39
|
||||
|
||||
is equivalent to:
|
||||
|
||||
DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
|
||||
|
||||
"7" / "8" / "9"
|
||||
|
||||
Concatenated numeric values and numeric value ranges cannot be
|
||||
specified in the same string. A numeric value may use the dotted
|
||||
notation for concatenation or it may use the dash notation to specify
|
||||
one value range. Hence, to specify one printable character between
|
||||
end-of-line sequences, the specification could be:
|
||||
|
||||
char-line = %x0D.0A %x20-7E %x0D.0A
|
||||
|
||||
3.5. Sequence Group: (Rule1 Rule2)
|
||||
|
||||
Elements enclosed in parentheses are treated as a single element,
|
||||
whose contents are strictly ordered. Thus,
|
||||
|
||||
elem (foo / bar) blat
|
||||
|
||||
matches (elem foo blat) or (elem bar blat), and
|
||||
|
||||
elem foo / bar blat
|
||||
|
||||
matches (elem foo) or (bar blat).
|
||||
|
||||
NOTE:
|
||||
|
||||
It is strongly advised that grouping notation be used, rather than
|
||||
relying on the proper reading of "bare" alternations, when
|
||||
alternatives consist of multiple rule names or literals.
|
||||
|
||||
Hence, it is recommended that the following form be used:
|
||||
|
||||
(elem foo) / (bar blat)
|
||||
|
||||
It will avoid misinterpretation by casual readers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 8]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
The sequence group notation is also used within free text to set off
|
||||
an element sequence from the prose.
|
||||
|
||||
3.6. Variable Repetition: *Rule
|
||||
|
||||
The operator "*" preceding an element indicates repetition. The full
|
||||
form is:
|
||||
|
||||
<a>*<b>element
|
||||
|
||||
where <a> and <b> are optional decimal values, indicating at least
|
||||
<a> and at most <b> occurrences of the element.
|
||||
|
||||
Default values are 0 and infinity so that *<element> allows any
|
||||
number, including zero; 1*<element> requires at least one;
|
||||
3*3<element> allows exactly 3; and 1*2<element> allows one or two.
|
||||
|
||||
3.7. Specific Repetition: nRule
|
||||
|
||||
A rule of the form:
|
||||
|
||||
<n>element
|
||||
|
||||
is equivalent to
|
||||
|
||||
<n>*<n>element
|
||||
|
||||
That is, exactly <n> occurrences of <element>. Thus, 2DIGIT is a
|
||||
2-digit number, and 3ALPHA is a string of three alphabetic
|
||||
characters.
|
||||
|
||||
3.8. Optional Sequence: [RULE]
|
||||
|
||||
Square brackets enclose an optional element sequence:
|
||||
|
||||
[foo bar]
|
||||
|
||||
is equivalent to
|
||||
|
||||
*1(foo bar).
|
||||
|
||||
3.9. Comment: ; Comment
|
||||
|
||||
A semicolon starts a comment that continues to the end of line. This
|
||||
is a simple way of including useful notes in parallel with the
|
||||
specifications.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 9]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
3.10. Operator Precedence
|
||||
|
||||
The various mechanisms described above have the following precedence,
|
||||
from highest (binding tightest) at the top, to lowest (loosest) at
|
||||
the bottom:
|
||||
|
||||
Rule name, prose-val, Terminal value
|
||||
|
||||
Comment
|
||||
|
||||
Value range
|
||||
|
||||
Repetition
|
||||
|
||||
Grouping, Optional
|
||||
|
||||
Concatenation
|
||||
|
||||
Alternative
|
||||
|
||||
Use of the alternative operator, freely mixed with concatenations,
|
||||
can be confusing.
|
||||
|
||||
Again, it is recommended that the grouping operator be used to
|
||||
make explicit concatenation groups.
|
||||
|
||||
4. ABNF Definition of ABNF
|
||||
|
||||
NOTES:
|
||||
|
||||
1. This syntax requires a formatting of rules that is relatively
|
||||
strict. Hence, the version of a ruleset included in a
|
||||
specification might need preprocessing to ensure that it can
|
||||
be interpreted by an ABNF parser.
|
||||
|
||||
2. This syntax uses the rules provided in Appendix B.
|
||||
|
||||
|
||||
rulelist = 1*( rule / (*c-wsp c-nl) )
|
||||
|
||||
rule = rulename defined-as elements c-nl
|
||||
; continues if next line starts
|
||||
; with white space
|
||||
|
||||
rulename = ALPHA *(ALPHA / DIGIT / "-")
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 10]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
defined-as = *c-wsp ("=" / "=/") *c-wsp
|
||||
; basic rules definition and
|
||||
; incremental alternatives
|
||||
|
||||
elements = alternation *c-wsp
|
||||
|
||||
c-wsp = WSP / (c-nl WSP)
|
||||
|
||||
c-nl = comment / CRLF
|
||||
; comment or newline
|
||||
|
||||
comment = ";" *(WSP / VCHAR) CRLF
|
||||
|
||||
alternation = concatenation
|
||||
*(*c-wsp "/" *c-wsp concatenation)
|
||||
|
||||
concatenation = repetition *(1*c-wsp repetition)
|
||||
|
||||
repetition = [repeat] element
|
||||
|
||||
repeat = 1*DIGIT / (*DIGIT "*" *DIGIT)
|
||||
|
||||
element = rulename / group / option /
|
||||
char-val / num-val / prose-val
|
||||
|
||||
group = "(" *c-wsp alternation *c-wsp ")"
|
||||
|
||||
option = "[" *c-wsp alternation *c-wsp "]"
|
||||
|
||||
char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE
|
||||
; quoted string of SP and VCHAR
|
||||
; without DQUOTE
|
||||
|
||||
num-val = "%" (bin-val / dec-val / hex-val)
|
||||
|
||||
bin-val = "b" 1*BIT
|
||||
[ 1*("." 1*BIT) / ("-" 1*BIT) ]
|
||||
; series of concatenated bit values
|
||||
; or single ONEOF range
|
||||
|
||||
dec-val = "d" 1*DIGIT
|
||||
[ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
|
||||
|
||||
hex-val = "x" 1*HEXDIG
|
||||
[ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 11]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
prose-val = "<" *(%x20-3D / %x3F-7E) ">"
|
||||
; bracketed string of SP and VCHAR
|
||||
; without angles
|
||||
; prose description, to be used as
|
||||
; last resort
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Security is truly believed to be irrelevant to this document.
|
||||
|
||||
6. References
|
||||
|
||||
6.1. Normative References
|
||||
|
||||
[US-ASCII] American National Standards Institute, "Coded Character
|
||||
Set -- 7-bit American Standard Code for Information
|
||||
Interchange", ANSI X3.4, 1986.
|
||||
|
||||
6.2. Informative References
|
||||
|
||||
[RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
|
||||
"Standard for the format of ARPA network text messages",
|
||||
RFC 733, November 1977.
|
||||
|
||||
[RFC822] Crocker, D., "Standard for the format of ARPA Internet
|
||||
text messages", STD 11, RFC 822, August 1982.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 12]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
Appendix A. Acknowledgements
|
||||
|
||||
The syntax for ABNF was originally specified in RFC 733. Ken L.
|
||||
Harrenstien, of SRI International, was responsible for re-coding the
|
||||
BNF into an Augmented BNF that makes the representation smaller and
|
||||
easier to understand.
|
||||
|
||||
This recent project began as a simple effort to cull out the portion
|
||||
of RFC 822 that has been repeatedly cited by non-email specification
|
||||
writers, namely the description of Augmented BNF. Rather than simply
|
||||
and blindly converting the existing text into a separate document,
|
||||
the working group chose to give careful consideration to the
|
||||
deficiencies, as well as benefits, of the existing specification and
|
||||
related specifications made available over the last 15 years, and
|
||||
therefore to pursue enhancement. This turned the project into
|
||||
something rather more ambitious than was first intended.
|
||||
Interestingly, the result is not massively different from that
|
||||
original, although decisions, such as removing the list notation,
|
||||
came as a surprise.
|
||||
|
||||
This "separated" version of the specification was part of the DRUMS
|
||||
working group, with significant contributions from Jerome Abela,
|
||||
Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom
|
||||
Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete
|
||||
Resnick, and Henning Schulzrinne.
|
||||
|
||||
Julian Reschke warrants a special thanks for converting the Draft
|
||||
Standard version to XML source form.
|
||||
|
||||
Appendix B. Core ABNF of ABNF
|
||||
|
||||
This appendix contains some basic rules that are in common use.
|
||||
Basic rules are in uppercase. Note that these rules are only valid
|
||||
for ABNF encoded in 7-bit ASCII or in characters sets that are a
|
||||
superset of 7-bit ASCII.
|
||||
|
||||
B.1. Core Rules
|
||||
|
||||
Certain basic rules are in uppercase, such as SP, HTAB, CRLF, DIGIT,
|
||||
ALPHA, etc.
|
||||
|
||||
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
|
||||
|
||||
BIT = "0" / "1"
|
||||
|
||||
CHAR = %x01-7F
|
||||
; any 7-bit US-ASCII character,
|
||||
; excluding NUL
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 13]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
CR = %x0D
|
||||
; carriage return
|
||||
|
||||
CRLF = CR LF
|
||||
; Internet standard newline
|
||||
|
||||
CTL = %x00-1F / %x7F
|
||||
; controls
|
||||
|
||||
DIGIT = %x30-39
|
||||
; 0-9
|
||||
|
||||
DQUOTE = %x22
|
||||
; " (Double Quote)
|
||||
|
||||
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
|
||||
|
||||
HTAB = %x09
|
||||
; horizontal tab
|
||||
|
||||
LF = %x0A
|
||||
; linefeed
|
||||
|
||||
LWSP = *(WSP / CRLF WSP)
|
||||
; Use of this linear-white-space rule
|
||||
; permits lines containing only white
|
||||
; space that are no longer legal in
|
||||
; mail headers and have caused
|
||||
; interoperability problems in other
|
||||
; contexts.
|
||||
; Do not use when defining mail
|
||||
; headers and use with caution in
|
||||
; other contexts.
|
||||
|
||||
OCTET = %x00-FF
|
||||
; 8 bits of data
|
||||
|
||||
SP = %x20
|
||||
|
||||
VCHAR = %x21-7E
|
||||
; visible (printing) characters
|
||||
|
||||
WSP = SP / HTAB
|
||||
; white space
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 14]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
B.2. Common Encoding
|
||||
|
||||
Externally, data are represented as "network virtual ASCII" (namely,
|
||||
7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to
|
||||
zero. A string of values is in "network byte order", in which the
|
||||
higher-valued bytes are represented on the left-hand side and are
|
||||
sent over the network first.
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Dave Crocker (editor)
|
||||
Brandenburg InternetWorking
|
||||
675 Spruce Dr.
|
||||
Sunnyvale, CA 94086
|
||||
US
|
||||
|
||||
Phone: +1.408.246.8253
|
||||
EMail: dcrocker@bbiw.net
|
||||
|
||||
|
||||
Paul Overell
|
||||
THUS plc.
|
||||
1/2 Berkeley Square,
|
||||
99 Berkeley Street
|
||||
Glasgow G3 7HR
|
||||
UK
|
||||
|
||||
EMail: paul.overell@thus.net
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 15]
|
||||
|
||||
RFC 5234 ABNF January 2008
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The IETF Trust (2008).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Crocker & Overell Standards Track [Page 16]
|
||||
|
||||
Reference in New Issue
Block a user