Skip to content

John McEleney / mailutils

Go to a project
Toggle navigation
Toggle navigation pinning
Commit 34e0ea26 34e0ea264af7c44463eef1c06fff8b1d428b34de by Sergey Poznyakoff
Options

Remove uncompatibly-copyrighted material. 

* configure.ac: Remove doc/rfc/Makefile.am
* doc/Makefile.am (SUBDIRS): Remove rfc.
(EXTRA_DIST): Add rfc/README.
* doc/rfc/README: New file.
* doc/rfc/CMC_V1.PS.gz: Remove.
* doc/rfc/Makefile.am: Remove.
* doc/rfc/rfc1413.txt: Remove.
* doc/rfc/rfc1521.txt: Remove.
* doc/rfc/rfc1731.txt: Remove.
* doc/rfc/rfc1734.txt: Remove.
* doc/rfc/rfc1738.txt: Remove.
* doc/rfc/rfc1870.txt: Remove.
* doc/rfc/rfc1891.txt: Remove.
* doc/rfc/rfc1892.txt: Remove.
* doc/rfc/rfc1893.txt: Remove.
* doc/rfc/rfc1894.txt: Remove.
* doc/rfc/rfc1939.txt: Remove.
* doc/rfc/rfc1957.txt: Remove.
* doc/rfc/rfc2045.txt: Remove.
* doc/rfc/rfc2046.txt: Remove.
* doc/rfc/rfc2047.txt: Remove.
* doc/rfc/rfc2049.txt: Remove.
* doc/rfc/rfc2060-errata
* doc/rfc/rfc2060.txt: Remove.
* doc/rfc/rfc2087.txt: Remove.
* doc/rfc/rfc2088.txt: Remove.
* doc/rfc/rfc2111.txt: Remove.
* doc/rfc/rfc2177.txt: Remove.
* doc/rfc/rfc2180.txt: Remove.
* doc/rfc/rfc2192.txt: Remove.
* doc/rfc/rfc2193.txt: Remove.
* doc/rfc/rfc2195.txt: Remove.
* doc/rfc/rfc2221.txt: Remove.
* doc/rfc/rfc2222.txt: Remove.
* doc/rfc/rfc2231.txt: Remove.
* doc/rfc/rfc2245.txt: Remove.
* doc/rfc/rfc2298.txt: Remove.
* doc/rfc/rfc2342.txt: Remove.
* doc/rfc/rfc2368.txt: Remove.
* doc/rfc/rfc2384.txt: Remove.
* doc/rfc/rfc2444.txt: Remove.
* doc/rfc/rfc2449.txt: Remove.
* doc/rfc/rfc2595.txt: Remove.
* doc/rfc/rfc2683.txt: Remove.
* doc/rfc/rfc2808.txt: Remove.
* doc/rfc/rfc2821.txt: Remove.
* doc/rfc/rfc2822.txt: Remove.
* doc/rfc/rfc2831.txt: Remove.
* doc/rfc/rfc3028.txt: Remove.
* doc/rfc/rfc3206.txt: Remove.
* doc/rfc/rfc3348.txt: Remove.
* doc/rfc/rfc3431.txt: Remove.
* doc/rfc/rfc3501.txt: Remove.
* doc/rfc/rfc3691.txt: Remove.
* doc/rfc/rfc4314.txt: Remove.
* doc/rfc/rfc821.txt: Remove.
* doc/rfc/rfc822.txt: Remove.
* doc/rfc/rfc934.txt: Remove.
* doc/rfc/sasl-mechanisms: Remove.
1 parent bd8c3722
Expand all
Inline Side-by-side
Showing 58 changed files with 57 additions and 2885 deletions
......@@ -1327,7 +1327,6 @@ AC_CONFIG_FILES([
config/Makefile
doc/Makefile
doc/man/Makefile
doc/rfc/Makefile
doc/texinfo/Makefile
dotlock/Makefile
examples/Makefile
......
......@@ -18,5 +18,5 @@
## Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA
## 02110-1301 USA
SUBDIRS = texinfo rfc man
EXTRA_DIST = ChangeLog.CVS
SUBDIRS = texinfo man
EXTRA_DIST = ChangeLog.CVS rfc/README
......
No preview for this file type
## Process this file with GNU Automake to create Makefile.in
## Copyright (C) 2001, 2002, 2003, 2007, 2008, 2010 Free Software
## Foundation, Inc.
##
## GNU Mailutils is free software; you can redistribute it and/or
## modify it under the terms of the GNU General Public License as
## published by the Free Software Foundation; either version 3, or (at
## your option) any later version.
##
## GNU Mailutils is distributed in the hope that it will be useful, but
## WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
## General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with GNU Mailutils; if not, write to the Free Software
## Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA
## 02110-1301 USA
EXTRA_DIST = \
rfc821.txt\
rfc822.txt\
rfc934.txt\
rfc1413.txt\
rfc1521.txt\
rfc1731.txt\
rfc1734.txt\
rfc1738.txt\
rfc1870.txt\
rfc1939.txt\
rfc1957.txt\
rfc2045.txt\
rfc2046.txt\
rfc2047.txt\
rfc2049.txt\
rfc2060.txt\
rfc2060-errata\
rfc2087.txt\
rfc2088.txt\
rfc2111.txt\
rfc2177.txt\
rfc2180.txt\
rfc2192.txt\
rfc2193.txt\
rfc2221.txt\
rfc2245.txt\
rfc2298.txt\
rfc2231.txt\
rfc2342.txt\
rfc2368.txt\
rfc2384.txt\
rfc2449.txt\
rfc2595.txt\
rfc2683.txt\
rfc2821.txt\
rfc2822.txt\
rfc3028.txt\
rfc3206.txt\
rfc3431.txt\
rfc3501.txt\
rfc3691.txt\
rfc3348.txt\
rfc4314.txt
This is a list of RFCs used when designing GNU Mailutils. To read any
of them, visit http://tools.ietf.org/html/rfcNNNN, replacing NNNN with
the actual RFC number.
821 SIMPLE MAIL TRANSFER PROTOCOL
822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
934 Proposed Standard for Message Encapsulation
1413 Identification Protocol
1521 MIME Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
1731 IMAP4 Authentication Mechanisms
1734 POP3 AUTHentication command
1738 Uniform Resource Locators (URL)
1870 SMTP Service Extension for Message Size Declaration
1891 SMTP Service Extension for Delivery Status Notifications
1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
1893 Enhanced Mail System Status Codes
1894 An Extensible Message Format for Delivery Status Notifications
1939 Post Office Protocol - Version 3
1957 Some Observations on Implementations of the Post Office Protocol (POP3)
2045 MIME Part One: Format of Internet Message Bodies
2046 MIME Part Two: Media Types
2047 MIME Part Three: Message Header Extensions for Non-ASCII Text
2049 MIME Part Five: Conformance Criteria and Examples
2060 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (+ rfc2060-errata)
2087 IMAP4 QUOTA extension
2088 IMAP4 non-synchronizing literals
2111 Content-ID and Message-ID Uniform Resource Locators
2177 IMAP4 IDLE command
2180 IMAP4 Multi-Accessed Mailbox Practice
2192 IMAP URL Scheme
2193 IMAP4 Mailbox Referrals
2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response
2221 IMAP4 Login Referrals
2222 Simple Authentication and Security Layer (SASL)
2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
2245 Anonymous SASL Mechanism
2298 An Extensible Message Format for Message Disposition Notifications
2342 IMAP4 Namespace
2368 The mailto URL scheme
2384 POP URL Scheme
2444 The One-Time-Password SASL Mechanism
2449 POP3 Extension Mechanism
2595 Using TLS with IMAP, POP3 and ACAP
2683 IMAP4 Implementation Recommendations
2808 The SecurID(r) SASL Mechanism
2821 Simple Mail Transfer Protocol
2822 Internet Message Format
2831 Using Digest Authentication as a SASL Mechanism
3028 Sieve: A Mail Filtering Language
3206 The SYS and AUTH POP Response Codes
3348 The Internet Message Action Protocol (IMAP4) Child Mailbox Extension
3431 Sieve Extension: Relational Tests
3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
3691 Internet Message Access Protocol (IMAP) UNSELECT command
4314 IMAP4 Access Control List (ACL) Extension
This diff could not be displayed because it is too large.
Network Working Group J. Myers
Request for Comments: 1734 Carnegie Mellon
Category: Standards Track December 1994
POP3 AUTHentication 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. Introduction
This document describes the optional AUTH command, for indicating an
authentication mechanism to the server, performing an authentication
protocol exchange, and optionally negotiating a protection mechanism
for subsequent protocol interactions. The authentication and
protection mechanisms used by the POP3 AUTH command are those used by
IMAP4.
2. The AUTH command
AUTH mechanism
Arguments:
a string identifying an IMAP4 authentication mechanism,
such as defined by [IMAP4-AUTH]. Any use of the string
"imap" used in a server authentication identity in the
definition of an authentication mechanism is replaced with
the string "pop".
Restrictions:
may only be given in the AUTHORIZATION state
Discussion:
The AUTH command indicates an authentication mechanism to
the server. If the server supports the requested
authentication mechanism, it performs an authentication
protocol exchange to authenticate and identify the user.
Optionally, it also negotiates a protection mechanism for
subsequent protocol interactions. If the requested
authentication mechanism is not supported, the server
Myers [Page 1]
RFC 1734 POP3 AUTH December 1994
should reject the AUTH command by sending a negative
response.
The authentication protocol exchange consists of a series
of server challenges and client answers that are specific
to the authentication mechanism. A server challenge,
otherwise known as a ready response, is a line consisting
of a "+" character followed by a single space and a BASE64
encoded string. The client answer consists of a line
containing a BASE64 encoded string. If the client wishes
to cancel an authentication exchange, it should issue a
line with a single "*". If the server receives such an
answer, it must reject the AUTH command by sending a
negative response.
A protection mechanism provides integrity and privacy
protection to the protocol session. If a protection
mechanism is negotiated, it is applied to all subsequent
data sent over the connection. The protection mechanism
takes effect immediately following the CRLF that concludes
the authentication exchange for the client, and the CRLF of
the positive response for the server. Once the protection
mechanism is in effect, the stream of command and response
octets is processed into buffers of ciphertext. Each
buffer is transferred over the connection as a stream of
octets prepended with a four octet field in network byte
order that represents the length of the following data.
The maximum ciphertext buffer length is defined by the
protection mechanism.
The server is not required to support any particular
authentication mechanism, nor are authentication mechanisms
required to support any protection mechanisms. If an AUTH
command fails with a negative response, the session remains
in the AUTHORIZATION state and client may try another
authentication mechanism by issuing another AUTH command,
or may attempt to authenticate by using the USER/PASS or
APOP commands. In other words, the client may request
authentication types in decreasing order of preference,
with the USER/PASS or APOP command as a last resort.
Should the client successfully complete the authentication
exchange, the POP3 server issues a positive response and
the POP3 session enters the TRANSACTION state.
Possible Responses:
+OK maildrop locked and ready
-ERR authentication exchange failed
Myers [Page 2]
RFC 1734 POP3 AUTH December 1994
Examples:
S: +OK POP3 server ready
C: AUTH KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: +OK Kerberos V4 authentication successful
...
C: AUTH FOOBAR
S: -ERR Unrecognized authentication type
Note: the line breaks in the first client answer are
for editorial clarity and are not in real authentica-
tors.
Myers [Page 3]
RFC 1734 POP3 AUTH December 1994
3. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in RFC 822.
Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
ATOM_CHAR ::= <any CHAR except atom_specials>
atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" /
<"> / "\"
auth ::= "AUTH" 1*(SPACE / TAB) auth_type *(CRLF base64)
CRLF
auth_type ::= 1*ATOM_CHAR
base64 ::= *(4base64_CHAR) [base64_terminal]
base64_char ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
"I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
"Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
"Y" / "Z" /
"a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
"i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
"q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
"y" / "z" /
"0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
"8" / "9" / "+" / "/"
;; Case-sensitive
base64_terminal ::= (2base64_char "==") / (3base64_char "=")
CHAR ::= <any 7-bit US-ASCII character except NUL,
0x01 - 0x7f>
continue_req ::= "+" SPACE base64 CRLF
CR ::= <ASCII CR, carriage return, 0x0C>
CRLF ::= CR LF
CTL ::= <any ASCII control character and DEL,
0x00 - 0x1f, 0x7f>
Myers [Page 4]
RFC 1734 POP3 AUTH December 1994
LF ::= <ASCII LF, line feed, 0x0A>
SPACE ::= <ASCII SP, space, 0x20>
TAB ::= <ASCII HT, tab, 0x09>
4. References
[IMAP4-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
Carnegie Mellon, December 1994.
5. Security Considerations
Security issues are discussed throughout this memo.
6. Author's Address
John G. Myers
Carnegie-Mellon University
5000 Forbes Ave
Pittsburgh, PA 15213
EMail: jgm+@cmu.edu
Myers [Page 5]
Network Working Group G. Vaudreuil
Request for Comments: 1892 Octel Network Services
Category: Standards Track January 1996
The Multipart/Report Content Type
for the Reporting of
Mail System Administrative Messages
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. The Multipart/Report MIME content-type
The Multipart/Report MIME content-type is a general "family" or
"container" type for electronic mail reports of any kind. Although
this memo defines only the use of the Multipart/Report content-type
with respect to delivery status reports, mail processing programs
will benefit if a single content-type is used to for all kinds of
reports.
The Multipart/Report content-type is defined as follows:
MIME type name: multipart
MIME subtype name: report
Required parameters: boundary, report-type
Optional parameters: none
Encoding considerations: 7bit should always be adequate
Security considerations: see section 4 of this memo.
The syntax of Multipart/Report is identical to the Multipart/Mixed
content type defined in [MIME]. When used to send a report, the
Multipart/Report content-type must be the top-level MIME content type
for any report message. The report-type parameter identifies the
type of report. The parameter is the MIME content sub-type of the
second body part of the Multipart/Report.
User agents and gateways must be able to automatically determine
that a message is a mail system report and should be processed as
such. Placing the Multipart/Report as the outermost content
provides a mechanism whereby an auto-processor may detect through
parsing the RFC 822 headers that the message is a report.
Vaudreuil Standards Track [Page 1]
RFC 1892 Multipart/Report January 1996
The Multipart/Report content-type contains either two or three sub-
parts, in the following order:
(1) [required] The first body part contains human readable message.
The purpose of this message is to provide an easily-understood
description of the condition(s) that caused the report to be
generated, for a human reader who may not have an user agent
capable of interpreting the second section of the
Multipart/Report.
The text in the first section may be in any MIME standards-track
content-type, charset, or language. Where a description of the
error is desired in several languages or several media, a
Multipart/Alternative construct may be used.
This body part may also be used to send detailed information
that cannot be easily formatted into a Message/Report body part.
(2) [required] A machine parsable body part containing an account
of the reported message handling event. The purpose of this body
part is to provide a machine-readable description of the
condition(s) which caused the report to be generated, along with
details not present in the first body part that may be useful to
human experts. An initial body part, Message/delivery-status is
defined in [DSN]
(3) [optional] A body part containing the returned message or a
portion thereof. This information may be useful to aid human
experts in diagnosing problems. (Although it may also be useful
to allow the sender to identify the message which the report was
issued, it is hoped that the envelope-id and original-recipient-
address returned in the Message/Report body part will replace
the traditional use of the returned content for this purpose.)
Return of content may be wasteful of network bandwidth and a variety
of implementation strategies can be used. Generally the sender
should choose the appropriate strategy and inform the recipient of
the required level of returned content required. In the absence of
an explicit request for level of return of content such as that
provided in [DRPT], the agent which generated the delivery service
report should return the full message content.
When data not encoded in 7 bits is to be returned, and the return
path is not guaranteed to be 8-bit capable, two options are
available. The origional message MAY be reencoded into a legal 7 bit
MIME message or the Text/RFC822-Headers content-type MAY be used to
return only the origional message headers.
Vaudreuil Standards Track [Page 2]
RFC 1892 Multipart/Report January 1996
2. The Text/RFC822-Headers MIME content-type
The Text/RFC822-Headers MIME content-type provides a mechanism to
label and return only the RFC 822 headers of a failed message. These
headers are not the complete message and should not be returned as a
Message/RFC822. The returned headers are useful for identifying the
failed message and for diagnostics based on the received: lines.
The Text/RFC822-Headers content-type is defined as follows:
MIME type name: Text
MIME subtype name: RFC822-Headers
Required parameters: None
Optional parameters: none
Encoding considerations: 7 bit is sufficient for normal RFC822
headers, however, if the headers are broken and require
encoding, they may be encoded in quoted-printable.
Security considerations: see section 4 of this memo.
The Text/RFC822-headers body part should contain all the RFC822
header lines from the message which caused the report. The RFC822
headers include all lines prior to the blank line in the message.
They include the MIME-Version and MIME Content- headers.
3. References
[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, University of
Tennessee, Octel Network Services, January 1996.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
[DRPT] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, University of Tennessee, January 1996.
4. Security Considerations
Automated use of report types without authentication presents several
security issues. Forging negative reports presents the opportunity
for denial-of-service attacks when the reports are used for automated
maintenance of directories or mailing lists. Forging positive
reports may cause the sender to incorrectly believe a message was
delivered when it was not.
Vaudreuil Standards Track [Page 3]
RFC 1892 Multipart/Report January 1996
5. Author's Address
Gregory M. Vaudreuil
Octel Network Services
17060 Dallas Parkway
Dallas, TX 75248-1905
Phone: +1-214-733-2722
EMail: Greg.Vaudreuil@Octel.com
Vaudreuil Standards Track [Page 4]
Network Working Group R. Nelson
Request for Comments: 1957 Crynwr Software
Updates: 1939 June 1996
Category: Informational
Some Observations on Implementations
of the Post Office Protocol (POP3)
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.
Observations
Sometimes an implementation is mistaken for a standard. POP3 servers
and clients are no exception. The widely-used UCB POP3 server,
popper, which has been further developed by Qualcomm, always has
additional information following the status indicator. So, the
status indicator always has a space following it. Two POP3 clients
have been observed to expect that space, and fail when it has not
been found. The RFC does not require the space, hence this memo.
These clients are the freely copyable Unix "popclient" and the
proprietary "netApp Systems Internet Series". The authors of both of
these have been contacted, and new releases will not expect the
space, but old versions should be supported.
In addition, two popular clients require optional parts of the RFC.
Netscape requires UIDL, and Eudora requires TOP.
The optional APOP authentication command has not achieved wide
penetration yet. Newer versions of the Qualcomm POP server implement
it. Known client implementations of APOP include GNU Emacs VM client
and Eudora Lite and Eudora Pro.
Security Considerations
Security issues are not discussed in this memo.
References
[1] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
Nelson Informational [Page 1]
RFC 1957 Notes on POP3 Implementations June 1996
Author's Address
Russell Nelson
Crynwr Software
521 Pleasant Valley Rd.
Potsdam, NY 13676
Phone: +1.315.268.1925
FAX: +1.315.268.9201
EMail: nelson@crynwr.com
Nelson Informational [Page 2]
This diff could not be displayed because it is too large.
Known errors in RFC 2060 as of 13 September 1998:
1) The SELECT and EXAMINE response list does not mention UIDVALIDITY.
2) In the definition of store_att_flags, #flag should be 1#flag; in other
words, at least one flag must be given. To do an empty list of flags,
you must use the parenthesized form: "()".
3) The example in 6.4.6 is missing parenthesis around the FETCH attributes.
It should read:
Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
S: * 2 FETCH (FLAGS (\Deleted \Seen))
S: * 3 FETCH (FLAGS (\Deleted))
S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
S: A003 OK STORE completed
4) Section 7.4.2 has an example of "a two part message consisting of a
text and a BASE645-encoded text attachment". "BASE645" should be
BASE64.
5) In the example in 7.4.2 discussed above, there is a spurious close
parenthesis at the end of the example.
6) Spurious obsolete response "MAILBOX" is listed in mailbox_data and
should be removed.
7) There is a spurious "<" in the mailbox_data rule that should be removed.
8) CRLF is missing from the continue_req rule.
9) The atom in resp_text_code should specifically exclude "]".
10) The example in 6.3.11 does not show the command continuation request.
11) NEWNAME is missing from resp_text_code.
12) There is a missing open parenthesis in the media_basic grammar rule.
13) Status attributes are incorrectly defined in mailbox_data rule.
14) The UID FETCH example is missing an "OK" in the response.
15) Multipart extension data incorrectly specifies that language must be
given along with disposition.
This diff could not be displayed because it is too large.
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]
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]
Network Working Group E. Levinson
Request for Comments: 2111 XIson, Inc.
Category: Standards Track March 1997
Content-ID and Message-ID Uniform Resource Locators
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 Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow
references to messages and the body parts of messages. For example,
within a single multipart message, one HTML body part might include
embedded references to other parts of the same message.
1. Introduction
The use of [MIME] within email to convey Web pages and their
associated images requires a URL scheme to permit the HTML to refer
to the images or other data included in the message. The Content-ID
Uniform Resource Locator, "cid:", serves that purpose.
Similarly Net News readers use Message-IDs to link related messages
together. The Message-ID URL provides a scheme, "mid:", to refer to
such messages as a "resource".
The "mid" (Message-ID) and "cid" (Content-ID) URL schemes provide
identifiers for messages and their body parts. The "mid" scheme uses
(a part of) the message-id of an email message to refer to a specific
message. The "cid" scheme refers to a specific body part of a
message; its use is generally limited to references to other body
parts in the same message as the referring body part. The "mid"
scheme may also refer to a specific body part within a designated
message, by including the content-ID's address.
A note on terminology. The terms "body part" and "MIME entity" are
used interchangeably. They refer to the headers and body of a MIME
message, either the message itself or one of the body parts contained
in a Multipart message.
Levinson Standards Track [Page 1]
RFC 2111 CID and MID URLs March 1997
2. The MID and CID URL Schemes
RFC1738 [URL] reserves the "mid" and "cid" schemes for Message-ID and
Content-ID respectively. This memorandum defines the syntax for
those URLs. Because they use the same syntactic elements they are
presented together.
The URLs take the form
content-id = url-addr-spec
message-id = url-addr-spec
url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
cid-url = "cid" ":" content-id
mid-url = "mid" ":" message-id [ "/" content-id ]
Note: in Internet mail messages, the addr-spec in a Content-ID
[MIME] or Message-ID [822] header are enclosed in angle brackets
(<>). Since addr-spec in a Message-ID or Content-ID might contain
characters not allowed within a URL; any such character (including
"/", which is reserved within the "mid" scheme) must be hex-
encoded using the %hh escape mechanism in [URL].
A "mid" URL with only a "message-id" refers to an entire message.
With the appended "content-id", it refers to a body part within a
message, as does a "cid" URL. The Content-ID of a MIME body part is
required to be globally unique. However, in many systems that store
messages, body parts are not indexed independently their context
(message). The "mid" URL long form was designed to supply the
context needed to support interoperability with such systems.
A implementation conforming to this specification is required to
support the "mid" URL long form (message-id/content-id). Conforming
implementations can choose to, but are not required to, take
advantage of the content-id's uniqueness and interpret a "cid" URL to
refer to any body part within the message store.
In limited circumstances (e.g., within multipart/alternate), a single
message may contain several body parts that have the same Content-ID.
That occurs, for example, when identical data can be accessed through
different methods [MIME, sect. 7.2.3]. In those cases, conforming
implementations are required to use the rules of the containing MIME
entity (e.g., multi-part/alternate) to select the body part to which
the Content-ID refers.
Levinson Standards Track [Page 2]
RFC 2111 CID and MID URLs March 1997
A "cid" URL is converted to the corresponding Content-ID message
header [MIME] by removing the "cid:" prefix, converting %hh hex-
escaped characters to their ASCII equivalents and enclosing the
remaining parts with an angle bracket pair, "<" and ">". For
example, "mid:foo4%25foo1@bar.net" corresponds to
Message-ID: <foo4%foo1@bar.net>
A "mid" URL is converted to a Message-ID or Message-ID/Content-ID
pair in a similar fashion.
Both message-id and content-id are required to be globally unique.
That is, no two different messages will ever have the same Message-ID
addr-spec; no different body parts will ever have the same Content-ID
addr-spec. A common technique used by many message systems is to use
a time and date stamp along with the local host's domain name, e.g.,
950124.162336@XIson.com.
Some Examples
The following message contains an HTML body part that refers to an
image contained in another body part. Both body parts are contained
in a Multipart/Related MIME entity. The HTML IMG tag contains a
cidurl which points to the image.
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example-1";
type=Text/HTML
--boundary-example 1
Content-Type: Text/HTML; charset=US-ASCII
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
--boundary-example-1
Content-ID: foo4*foo1@bar.net
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
Levinson Standards Track [Page 3]
RFC 2111 CID and MID URLs March 1997
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
--boundary-example-1--
The following message points to another message (hopefully still in
the recipient's message store).
From: bar@none.com
To: phooey@all.com
Subject: Here's how to do it
Content-type: text/html; charset=usascii
... The items in my
<A HREF= "mid:960830.1639@XIson.com/partA.960830.1639@XIson.com">
previous message</A>, shows how the approach you propose can be
used to accomplish ...
3. Security Considerations
The URLs defined here provide an addressing or referencing mechanism.
The values of these URLs disclose no more about the originators
environment than the corresponding Message-ID and Content-ID values.
Where concern exists about such disclosures the originator of a
message using mid and cid URLs must take precautions to insure that
confidential information is not disclosed. Those precautions should
already be in place to handle existing mail use of the Message-ID and
Content-ID.
4. References
[822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages," August 1982, University of Delaware, STD 11, RFC
822.
[MIME] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies,"
September 1993, RFC 1521.
[URL] Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform
Resource Locators (URL)," December 1994.
[MULREL] E. Levinson, "The MIME Multipart/Related Content-type,"
December 1995, RFC 1874.
Levinson Standards Track [Page 4]
RFC 2111 CID and MID URLs March 1997
5. Acknowledgments
The original concept of "mid" and "cid" URLs were part of the Tim
Berners-Lee's original vision of the World Wide Web. The ideas and
design have benefited greatly by discussions with Harald Alvestrand,
Dan Connolly, Roy Fielding, Larry Masinter, Jacob Palme, and others
in the MHTML working group.
6. Author's Address
Edward Levinson
47 Clive Street
Metuchen, NJ 08840-1060
USA
+1 908 549 3716
<XIson@cnj.digex.net>
Levinson Standards Track [Page 5]
Network Working Group
Request for Comments: 2177
Category: Standards Track
B. Leiba
IBM T.J. Watson Research Center
June 1997
Page 1
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
__________________________________________________________
Page 2
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.
__________________________________________________________
Page 3
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"
__________________________________________________________
Page 4
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
__________________________________________________________
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]
Network Working Group C. Newman
Request for Comments: 2245 Innosoft
Category: Standards Track November 1997
Anonymous 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 (1997). All Rights Reserved.
Abstract
It is common practice on the Internet 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
optional trace information, such as an email address, as the
password. As plaintext login commands are not permitted in new IETF
protocols, a new way to provide anonymous login is needed within the
context of the SASL [SASL] framework.
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 defined in "Key words for
use in RFCs to Indicate Requirement Levels" [KEYWORDS].
2. Anonymous SASL mechanism
The mechanism name associated with anonymous access is "ANONYMOUS".
The mechanism consists of a single message from the client to the
server. The client sends optional trace information in the form of a
human readable string. The trace information should take one of
three forms: an Internet email address, an opaque string which does
not contain the '@' character and can be interpreted by the system
administrator of the client's domain, or nothing. For privacy
reasons, an Internet email address should only be used with
permission from the user.
Newman Standards Track [Page 1]
RFC 2245 Anonymous SASL Mechanism November 1997
A server which permits anonymous access will announce support for the
ANONYMOUS mechanism, and allow anyone to log in using that mechanism,
usually with restricted access.
The formal grammar for the client message using Augmented BNF [ABNF]
follows.
message = [email / token]
TCHAR = %x20-3F / %x41-7E
;; any printable US-ASCII character except '@'
email = addr-spec
;; as defined in [IMAIL], except with no free
;; insertion of linear-white-space, and the
;; local-part MUST either be entirely enclosed in
;; quotes or entirely unquoted
token = 1*255TCHAR
3. 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. Newer profiles of SASL will include the client message
with the AUTHENTICATE command itself so the extra round trip below
(the server response with an empty "+ ") can be eliminated.
In this example, the user's opaque identification token is "sirhc".
S: * OK IMAP4 server ready
C: A001 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS
S: A001 OK done
C: A002 AUTHENTICATE ANONYMOUS
S: +
C: c2lyaGM=
S: A003 OK Welcome, trace information has been logged.
Newman Standards Track [Page 2]
RFC 2245 Anonymous SASL Mechanism November 1997
4. Security Considerations
The anonymous mechanism grants access to information by anyone. For
this reason it should be disabled by default so 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 anonymously
exchange information. Servers which 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 limit the number of anonymous
users and reduce their priority or limit their resource usage.
If there is no idle timeout for the anonymous user and there is a
limit on the number of anonymous users, a denial of service attack is
enabled. Servers should implement an idle timeout for anonymous
users.
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 trying to trace
abuse need to realize this information may be falsified.
A client which uses the user's correct email address as trace
information without explicit permission may violate that user's
privacy. Information about who accesses an anonymous archive on a
sensitive subject (e.g., sexual abuse) has strong privacy needs.
Clients should not send the email address without explicit permission
of the user and should offer the option of supplying no trace token
-- thus only exposing the source IP address and time. 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
which view or alter the data transferred. Clients and servers are
encouraged to support external integrity and encryption mechanisms.
Protocols which fail to require an explicit anonymous login are more
susceptible to break-ins given certain common implementation
techniques. Specifically, Unix servers which offer user login may
Newman Standards Track [Page 3]
RFC 2245 Anonymous SASL Mechanism November 1997
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 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 which offer restricted data access should not allow
anonymous data access without an explicit login step.
5. References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
Messages", STD 11, RFC 822, August 1982.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
6. Author's Address
Chris Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790 USA
Email: chris.newman@innosoft.com
Newman Standards Track [Page 4]
RFC 2245 Anonymous SASL Mechanism November 1997
7. 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 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.
Newman Standards Track [Page 5]
This diff could not be displayed because it is too large.
This diff could not be displayed because it is too large.
Network Working Group R. Gellens
Request for Comments: 3206 QUALCOMM
Category: Standards Track February 2002
The SYS and AUTH POP Response Codes
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo proposes two response codes: SYS and AUTH, which enable
clients to unambiguously determine an optimal response to an
authentication failure. In addition, a new capability (AUTH-RESP-
CODE) is defined.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . 2
3. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
4. The SYS Response Code . . . . . . . . . . . . . . . . . . . 3
5. The AUTH Response Code . . . . . . . . . . . . . . . . . . 3
6. The AUTH-RESP-CODE Capability . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 4
8. Security Considerations . . . . . . . . . . . . . . . . . . 4
9. References . . . . . . . . . . . . . . . . . . . . . . . . 5
10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 5
11. Full Copyright Statement . . . . . . . . . . . . . . . . . 6
Gellens Standards Track [Page 1]
RFC 3206 The SYS and AUTH POP Response Codes February 2002
1. Introduction
RFC 2449 [POP3-EXT] defined extended [POP3] response codes, to give
clients more information about errors so clients can respond more
appropriately. In addition to the mechanism, two initial response
codes were defined (IN-USE and LOGIN-DELAY), in an attempt to
differentiate between authentication failures related to user
credentials, and other errors.
In practice, these two response codes, while helpful, do not go far
enough. This memo proposes two additional response codes: SYS and
AUTH, which enable clients to unambiguously determine an optimal
response to an authentication failure.
In addition, a new capability (AUTH-RESP-CODE) is defined.
2. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS].
3. Background
RFC 2449 [POP3-EXT] introduced the IN-USE and LOGIN-DELAY response
codes. The intent is to allow clients to clearly determine the
underlying cause of a failure in order to respond. For example,
clients need to know if the user should be asked for new credentials,
or if the POP3 session should simply be tried again later. (Some
deployed POP3 clients attempt to parse the text of authentication
failure errors, looking for strings known to be issued by various
servers which indicate the mailbox is locked.)
IN-USE indicates that an exclusive lock could not be obtained for the
user's mailbox, probably because another POP3 session is in progress.
LOGIN-DELAY informs the client that the user has not waited long
enough before authenticating again.
However, there are other error conditions which do not require new
credentials, some of which should be brought to the user's attention.
Despite the IN-USE and LOGIN-DELAY responses, clients cannot be sure
if any other error requires new user credentials.
Gellens Standards Track [Page 2]
RFC 3206 The SYS and AUTH POP Response Codes February 2002
4. The SYS Response Code
The SYS response code announces that a failure is due to a system
error, as opposed to the user's credentials or an external condition.
It is hierarchical, with two possible second-level codes: TEMP and
PERM. (Case is not significant at any level of the hierarchy.)
SYS/TEMP indicates a problem which is likely to be temporary in
nature, and therefore there is no need to alarm the user, unless the
failure persists. Examples might include a central resource which is
currently locked or otherwise temporarily unavailable, insufficient
free disk or memory, etc.
SYS/PERM is used for problems which are unlikely to be resolved
without intervention. It is appropriate to alert the user and
suggest that the organization's support or assistance personnel be
contacted. Examples include corrupted mailboxes, system
configuration errors, etc.
The SYS response code is valid with an -ERR response to any command.
5. The AUTH Response Code
The AUTH response code informs the client that there is a problem
with the user's credentials. This might be an incorrect password, an
unknown user name, an expired account, an attempt to authenticate in
violation of policy (such as from an invalid location or during an
unauthorized time), or some other problem.
The AUTH response code is valid with an -ERR response to any
authentication command including AUTH, USER (see note), PASS, or
APOP.
Servers which include the AUTH response code with any authentication
failure SHOULD support the CAPA command [POP3-EXT] and SHOULD include
the AUTH-RESP-CODE capability in the CAPA response. AUTH-RESP-CODE
assures the client that only errors with the AUTH code are caused by
credential problems.
NOTE: Returning the AUTH response code to the USER command
reveals to the client that the specified user exists. It is
strongly RECOMMENDED that the server not issue this response code
to the USER command.
Gellens Standards Track [Page 3]
RFC 3206 The SYS and AUTH POP Response Codes February 2002
6. The AUTH-RESP-CODE Capability
CAPA tag:
AUTH-RESP-CODE
Arguments:
none
Added commands:
none
Standard commands affected:
none
Announced states / possible differences:
both / no
Commands valid in states:
n/a
Specification reference:
this document
Discussion:
The AUTH-RESP-CODE capability indicates that the server includes
the AUTH response code with any authentication error caused by a
problem with the user's credentials.
7. IANA Considerations
IANA has added the AUTH-RESP-CODE capability to the list of POP3
capabilities (established by RFC 2449 [POP3-EXT]).
IANA has also added the SYS and AUTH response codes to the list of
POP3 response codes (also established by RFC 2449 [POP3-EXT]).
8. Security Considerations
Section 5, The AUTH Response Code, discusses the security issues
related to use of the AUTH response code with the USER command.
Gellens Standards Track [Page 4]
RFC 3206 The SYS and AUTH POP Response Codes February 2002
9. References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version
3", STD 53, RFC 1939, May 1996.
[POP3-EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
Mechanism", RFC 2449, November 1998.
10. Author's Address
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121-2779
U.S.A.
Phone: +1 858 651 5115
EMail: randy@qualcomm.com
Gellens Standards Track [Page 5]
RFC 3206 The SYS and AUTH POP Response Codes February 2002
11. 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.
Gellens Standards Track [Page 6]
This diff could not be displayed because it is too large.
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]
This diff could not be displayed because it is too large.
This diff could not be displayed because it is too large.
SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS
----------------------------------------------------------
(last updated 2001 Jul 24)
The Simple Authentication and Security Layer (SASL) [RFC2222] is a
method for adding authentication support to connection-based
protocols. To use this specification, a protocol includes a command
for identifying and authenticating a user to a server and for
optionally negotiating a security layer for subsequent protocol
interactions. The command has a required argument identifying a SASL
mechanism.
SASL mechanisms are named by strings, from 1 to 20 characters in
length, consisting of upper-case letters, digits, hyphens, and/or
underscores. SASL mechanism names must be registered with the IANA.
Procedures for registering new SASL mechanisms are given in the
section "Registration procedures" of RFC2222.
MECHANISMS OWNER REFERENCE
---------- ----- ---------
KERBEROS_V4 IESG <iesg@ietf.org> [RFC2222]
GSSAPI IESG <iesg@ietf.org> [RFC2222]
SKEY (OBSOLETE) IESG <iesg@ietf.org> [RFC2444]
EXTERNAL IESG <iesg@ietf.org> [RFC2222]
CRAM-MD5 IESG <iesg@ietf.org> [RFC2195]
ANONYMOUS IESG <iesg@ietf.org> [RFC2245]
OTP IESG <iesg@ietf.org> [RFC2444]
GSS-SPNEGO Paul Leach <paulle@microsoft.com> [Leach]
PLAIN IESG <iesg@ietf.org> [RFC2595]
SECURID Magnus Nystrom <magnus@rsasecurity.com>[RFC2808]
NTLM Paul Leach <paulle@microsoft.com> [Leach]
NMAS_LOGIN Mark G. Gayman <mgayman@novell.com> [Gayman]
NMAS_AUTHEN Mark G. Gayman <mgayman@novell.com> [Gayman]
DIGEST-MD5 IESG <iesg@ietf.org> [RFC2831]
9798-U-RSA-SHA1-ENC robert.zuccherato@entrust.com [RFCZUCC]
9798-M-RSA-SHA1-ENC robert.zuccherato@entrust.com [RFCZUCC]
9798-U-DSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
9798-M-DSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
9798-U-ECDSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
9798-M-ECDSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
References
----------
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, Netscape Communications, October 1997.
[RFC2195] Klensin, J., Catoe, R., Krumviede, P. "IMAP/POP AUTHorize
Extension for Simple Challenge/Response", RFC 2195, MCI,
September 1997.
[RFC2245] Newman, C., "Anonymous SASL Mechanism", RFC 2245, Innosoft,
November 1997.
[RFC2444] Newman, C., "The One-Time-Password SASL Mechanism", RFC
2444, October 1998.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
Innosoft, June 1999.
[RFC2808] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808,
April 2000.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000.
[RFCZUCC] R. Zuccherato and M. Nystrom, "ISO/IEC 9798-3 Authentication
SASL Mechanism", RFC XXXX, Month 2001.
People
------
[Gayman] Mark G. Gayman, <mgayman@novell.com>, September 2000.
[Leach] Paul Leach, <paulle@microsoft.com>, December 1998, June 2000.
[]